Abstract We consider the problem of organizing the Internet routing tables in such a way as to enable fast routing lookup performance. We concentrate

Transcription

1 IP Routing Lookups Algorithms Evaluation Lukas Kencl Doctoral School of Communication Systems EPFL Lausanne Supervisor Patrick Droz IBM Laboratories Zurich July 9, 998

2 Abstract We consider the problem of organizing the Internet routing tables in such a way as to enable fast routing lookup performance. We concentrate on two recently proposed methods and try to evaluate their performance. We describe our implementation of the methods and results of performance measurements on existing as well as articially generated input data. We present some conclusions about the general behaviour of both methods, based on the measurements and theoretical reasoning. Finally, we comment on the results, suggesting preference among the given methods.

3 Introduction. Internet growth Recent extensive growth of the Internet has led to an enormous growth in the number of routing table entries. Further on, with the upgrade to IPv6, the step from 3 bit to 8 bit addresses will result in a dramatic increase in the size of routing tables. With the growing demand for higher bit rates and the increasing use of voice communication over the Internet (which results in appearance of many small packets), the router performance, in which the speed of a routing address lookup plays a key role, is becoming an issue of major importance in the eciency of the network. Here we examine a few techniques proposed recently for software implementation of routing address lookup. These techniques claim to be able to support the currently required Gb/s throughput. We try to evaluate their performance from the practical as well as the theoretical point of view, we especially concentrate on the memory acces characteristics and on the number of principal operations needed to perform the build and lookup functions. We also comment on their potential scalability to the IPv6 environment.. Router Design and Address Lookup Traditionally, the address lookup has been performed by a central processor, called routing engine, that served all the input ports of a router. However, nowadays, with the need for faster performance, we think of separate engines at each input port of a router, thus avoiding the round-trip of the IP packet header between the input port and the central processor. The model we consider here is of a routing engine at each input port, using a static forwarding table capable of great lookup speed, and a central processor, keeping a dynamic routing table used for updates due to changes in the address space and network topology (a potential candidate for such a dynamic scheme would be the method presented in []). The central processor periodically computes the static and more ecient version of the forwarding table and distributes it to the input port routing engines. The most important parameter of the central processor performance is the build time of the forwarding table out of the dynamic structure the processor keeps. Nowadays, at main Internet nodes, the tables change dynamically about every second at peak times, therefore the build procedure must be ecient enough to keep up with the changes in the table. The most important parametres of the static routing lookup schemes themselves are size of the structure and number of memory accesses during lookup. If we can manage to keep the size of the structure small enough that at least its major part could t in the processor cache, than such methodwould perform much better, since the memory accesses would require considerable less time. Nevertheless, the key parameter of the schemes remains to be the number of memory accesses necessary to perform lookup, since this operation is the most time consuming. Both methods presented try to deal with the previously mentioned task and contain particular schemes to perform size compression and lookup path compression.

4 Here we concentrate on the problem of organizing such a static table and on its build, size and number of memory acceses parameters. In addition, we also try to measure the number of shift operations necessary during build and lookup, since these are principal operations in a potential hardware version of a router based on a particular method. Examined techniques. General Approach The forwarding process is based on a best matching prex lookup. The forwarding table comprises of address prexes of various lengths. The task is to nd a prex of maximum length matching the given address. Convenient data structures for preserving the prexes are binary tries, where each prex is equivalent to the path to a node representing the prex, where (resp. ) is equivalent to left (resp. right) turn at a node on the path. Binary tries exploit the fact that various entries share prexes of each other, thus omitting redundancies in the data structure by storing the shared part of the prexes in the same location. The techniques we examine try to improve on the scheme of a standard binary trie (using the fact that the table remains static), in order to minimize the size of the structure and number of memory accesses during search on the structure.. Level Compressed Trie (LC-Trie) and Base Vector ([]) This scheme uses two steps of compression on the original binary trie, path compression and level compression. Path compression removes internal nodes with only one child and preserves the information about the compressed path in the form of a skip number in the following node, indicating how many bits have been skipped. Thus, the length of the path and the size of the trie can be signicantly decreased, however, information about the actual values on the compressed paths is lost. Level compression is used to compress complete levels of a binary trie by replacing the i complete levels of a binary trie with a single node of degree i. This compression leads to no loss of information. Path compression does not decrease the size of the structure, because the number of nodes remains the same. However, it does shorten the length of search path. Since the size of the trie and the length of path decrease enormously,asearch algorithm on this small structure is very fast. However, the result is only an indication of a possible hit, since there are parts of thepathlostdue to path compression. The result has to be veried in a base vector, an array comprising of all the routing table entries that are not prex to any other. Furthermore, in case of a verication failure, we continue the verication in the prex vector, a vector of entries that are prexes of other entries, until either a match is found or all the candidate prexes are exhausted.

5 .3 Binary Trie Level Partition ([3]) Here, the searched string is partitioned into parts of given length and the searches are performed for each part separately, using the fact that in a binary trie, a search of the lower level is only performed on a sub-trie fully determined by the upper level. We perform the search at the given levels of a binary trie by using a precomputed cut of the expanded binary trie (every node must have either none or two children), which enables us to obtain the result at a single access to the cut vector. A cut vector can be further compressed due to some special properties of the expanded binary trie. The cut vector is partitioned into bitmasks of length 6. It can be proved that there are only 678 possible bitmasks of length 6 in an expanded binary trie cut and therefore we can encode 6 bit bitmasks with bits only. Therefore we can actually encode the cut vector into a vector of much smaller size, using a constant maptable. Some sparse lower level cuts can be compressed even further using an entirely dierent approach - simply recording the entries in a list and perform the lookup as binary search. We did not include this optimization in our measurements, since it is inconsistent with the rest of the algorithm and thus would require more conditional branching in a potential router design. 3 Methods Testing 3. General approach We have chosen to implement the given techniques in the C language. Since the goal of the project was to measure and compare the speed of the given techniques, C seemed a natural solution, since its compiled code is still faster than most object oriented languages. For the LC-Trie Method there was some C code made available by the authors at []. However, this code contained undocumented optimizations of the LC-Trie Method, so for the interest of a fair evaluation, these optimizations were taken out of the code. There was no code available for the Method, and, furthermore, the build algorithm was not specied by the authors, therefore the build algorithm had to be designed. We have used the Visual C++ compiler and carried out the tests under the Windows NT environment. However, for large data, the time measurements were greatly aected by the virtul memory assignement policy of the NT system. The tests were performed on a Pentium processor machine. The results presented here concentrate rather on the ratio of performance between the two methods than on the exact measured values. 3. Test data The methods were tested on existing routing tables, as well as articially generated tables. 3

6 3.. Existing tables The existing tables were downloaded from the routing table snapshots provided by the IPMA Project ([5]). Since no reliable studies on the actual Internet trac were available, we used the list of routing table entries to measure the lookup speed as well. 3.. Articially generated tables The articially generated tables were generated in order to show dierences of the methods' behaviour on inputs of particular distribution and particular size. Varius combinations of dierent prex length distributions and prex value distributions were used. Input Data Size { Maximum number of entries used was 6 = entries due to system limitations. Prex Length Distribution { Constant length. { Length distribution as in existing tables. The prex length distribution in existing tables was modelled according to values found at [5]. { Random length. Prex Value Distribution { On one side of prex value spectrum - starting from, the dierence between entries (step) = (i.e. entry i+ -entry i = ). { With constant step (step = i ). Maximum value for step = 3 /(# of entries), in such case entries are regularly distributed. { With random step. For generating the random values, a random generator proposed in [7] was used. The prex length distribution was modelled using the random generator and a random-variate techinque. 3.3 Build For all the methods, we take as a source for building the lookup structures an ordered list of routing table entries. Although in the case of real implementation in a router, the tables would be built from some dynamic structure at the central processor, for each method the structure would be dierent, so as to enable the fastest possible build procedure. It remains to be seen which would be the most convenient one for each method. However, to make a fair comparison of the build time, we chose an ordered list of the entries as the input data to the build process of all methods.

7 Each of the list lines consists of a nexthop identier, length of the prex mask and the prex value. In cases where there were several nexthop possibilities in the original tables, the rst one was selected. The entries in the IPMA routing tables are presented ordered in the snapshots, an ordering criterion being:. The "value" of the entry, that is considering the entry to be 3 bit binary number. The parts of the entries sretching above their length are always assigned value.. In case two entries have the same value, then their prex masks must be of dierent length and then the one with shorter prex mask is considered smaller. However, to ensure correct ordering, we performed the pre-sort of the table, using a quicksort sorting routine taken from [6]. The same sorting procedure and ordering criteria were applied to the articially generated data. The entries were kept in an array consisting of touples of fvalue, len, nexthopg, where value is a 3 bit number, len is the length of the prex mask and nexthop is the 3 bit identier of a nexthop interface LC-Trie Method The rst step is to separate the prex entries from the base entries and to create the prex vector and the base vector. This task is easily performed since in an ordered list of entries, a prex is always directly followed by anentry that comprises the prex, so by comparison with the following entry it is easy to nd out whether an entryisaprex or a base entry. The base entries, as well as prex entries, keep a pointer to their prex, if such exists. Then, out of the base entries, the LC-trie is built, applying in a depth- rst manner step by step the level and path compression, entries inserted from smallest to largest. All leaves contain a pointer to its representative in the base vector Method In the case of the Method, the authors did not specify the build algorithm, only certain requirements for the build procedure were presented: Algorithm is linear in the number of routing entries. Algorithm is linear in the size of the resulting forwarding table. Table is built during a single pass over all routing entries. We have designed our own algorithm, which conrms to these three properties. In the rst step the algorithm inserts the entries one byoneinto a structure consisting of the cut vector and pointers to lower levels. In the second step, the algorithm encodes such a structure using a maptable into a smaller encoded cut. Then the larger cut vector is disposed from memory and only the encoded version remains to perform the lookups. 5

8 The intermediate cut vector structure may have enormous space requirements, which in some cases resulted in very large build time, which was due to allocating the memory required by the NT Virtual Paging. 3. Lookup In all cases, the lookup performance was measured using the entries of the input routing table. One by one, for each entry value a lookup was performed and the parametres recorded. 3.5 Measured Parametres Size Size of the forwarding table after being built (i.e. the static structure). Build time Time necessary to build the forwarding table from the in-memory ordered list of routing table entries. The time to read the values or to perform the sorting is not included. # of shift operations per entry during build Population mean over al entries of all the shift operations performed per entry insertion. We dene a shift operation to be one shift of a 3 bit number either to the left or to the right. # of memory accesses per lookup Population mean over all entries of a number of memory accesses per entry lookup. # of shift operations per entry during lookup Population mean over all entries of all the shift operations performed per entry lookup. 6

9 Tests Results. Tests on Existing Data The tests were performed on the following routing tables: Table Date #ofentries Mae East AADS Paccard-Bell Mae West Paix Table : Existing Routing Tables used.. Build Table shows results of measurements of the build parametres measured over existing tables. Size (B) # of shift oper. Time (s) Table #ofentries LC Trie LC Trie LC Trie maee aads pacbell maew paix Table : Build parametres on existing tables.. Lookup The results of lookup parametres measurements are in Table 3. The mean values are population means over all entries. # of memory accesses # of shift oper. Table LC Trie LC Trie maee aads pacbell maew paix Table 3: Lookup parametres on existing tables 7

10 Results on existing tables.5 x Size (B) MaeE AADS MaeW PacBell Paix Tables Figure : Number of entries in existing tables x Size (B) 5 3 MaeE AADS MaeW PacBell Paix Tables Figure : Size of built forwarding table 3.5 Time (s).5.5 MaeE AADS MaeW PacBell Paix Tables Figure 3: Time to build the forwarding table # of Memory Accesses MaeE AADS MaeW PacBell Paix Tables Figure : Average number of memory accesses 8

11 . Tests on Articially Generated Data For the demonstration of certain properties of the evaluated method we chose to show the results of tests with 5 = 3768 entries... Prex length and step value xed Here, we xed the prex length at, since that is the most frequent entry length in the current routing tables, and we try the varius value distributions, measuring for all possible step = i. The results are summarised in Table. Size (B) # of memory accesses Step #ofentries LC Trie LC Trie Table : Build and lookup parametres on xed length and step entries When the step value is low, many repetitive entries are generated (since only the high bits are taken into account), which are then discarded as duplicates, so for example with step =, out of 5 entries only 8 non duplicate entries remain. With such routing table entries we obtain much better performance of the LC-Trie Method, which is due to symmetry and regularity in the distribution of entries. 9

12 Results on tables with xed prex length and step value 3.5 x 3.5 # of Entries Step Figure 5: Number of entries x Size (B) Step Figure 6: Size of built forwarding table # of Memory Accesses Step Figure 7: Average number of memory accesses

13 .. Length distribution as in existing tables, xed size step We generate entries with random length so as the distribution of the length is equal to the distribution of prex length in major routing tables. That is, we simulate the same distribution as in Mae East of The information about the prex length distribution was obtained through IPMA ([5]). The results are displayed in Table 5. Size (B) # of memory accesses Step #ofentries LC Trie LC Trie Table 5: Build and lookup parametres for length distribution as in existing tables and xed step

14 Results on tables with prex length distribution as in existing tables and step of xed size 3.5 x 3.5 # of Entries Step Figure 8: Number of entries 8 x 5 6 Size (B) Step Figure 9: Size of built forwarding table # of Memory Accesses Step Figure : Average number of memory accesses

15 ..3 Random length of uniform distribution, xed size step In this case, entries are generated with random length of uniform distribution(length between and 3) and the step between entries remains xed. Again, with small step, we obtain many duplicates, but we can observe in Table 6 that with the rising number of valid entries, i.e. increasing step, the Cut Vector space requiremnts grow much faster than those of LC Trie, whereas LC Trie performs lookups on average with less memory accesses. Size (B) # of memory accesses Step #ofentries LC Trie LC Trie Table 6: Build and lookup parametres for uniform length distribution and xed step 3

16 Results on tables with random entry length of uniform distribution and xed size steps. x..8 # of Entries Step Figure : Number of entries x 5 8 Size (B) Step Figure : Size of built forwarding table # of Memory Accesses Step Figure 3: Average number of memory accesses

17 .. Random Entries Several tests were carried out on a set of randomly generated tables, using the random generator proposed in [7]. Both value and prex length are randomly selected. Results of measurements are to be found in Table 7 Size (B) # of memory accesses #oftest #ofentries LC Trie LC Trie Sample Mean Table 7: Build and lookup parametres for a sample of random generated tables 5

18 Results on tables with random generated entries.85 x # of Entries Experiment Figure : Number of entries x 5 Size (B) Experiment Figure 5: Size of built forwarding table # of Memory Accesses Experiment Figure 6: Average number of memory accesses 6

19 5 Results Evaluation 5. Existing Tables It is clear from the results obtained that the forwarding table, alhough takes longer to build, is better in all the other parametres than the LC- Trie method (except for the small Paix table, where just the size of the coding Maptable (35 B) is larger than the coded structure). However, the question we have to pose here is, whether the result of the methods comparison is due to the generally better performance of the Method, or whether it is due to the current routing table entries distribution. Since the current distribution is greatly aected by the past Class Address system, especially as far as the prex length distribution is concerned, we should keep in mind that the bias will slowly be turning away from this somewhat unnatural situation. In order to asess the properties of both methods correctly, we have to look at the results of the tests on the articially generated data. 5. Articially Generated Tables With the articially generated tables, the results seem to be completely overturned. The LC-Trie method exploits to much higher extent all the 'regularity' in the arising distributions and that leads to great path compression. The size of the LC-Trie forwarding table remains stable with distribution changes (its size in bytes is equal to about times the number of entries). The Cut-Vector Method forwarding table size is however greatly aected by dierences in distribution. A more spread spectrum causes the Method to build more lower level cuts, which increases the size of the structure considerably. The lookup parametres of the LC-Trie method also show better performance. However, this is largely due to very unbiased distribution of the the routing table entries in our articial examples. In such a case the path and level compression achieve good results. However, in the case of more biased input data, as in the case of existing tables, stability given by scheme prevails (by stability we mean the fact that to nd a nexthop in the forwarding table we need to search at least one level - memory accesses - and at most 3 levels - maximum of memory accesses). The values of the LC-Trie method may oscillate on a much higher scale - we can easily design a structure on which there would be a node that would require 3 memory accesses, as well as there can be nodes accessible at two memory accesses only. 5.3 Performance Inuencing Factors From the test results and from the method descriptions we can deduce some fundamental relations of proportional equivalence between performance parametres and input data properties: 7

20 LC-Trie Method Size of Forwarding Table # of Routing Table entries. # of Memory Accesses Entry value and length distribution. Method Size of Forwarding Table Entry value and length distribution. # of Memory Accesses Entry length distribution. These properties of proportional equivalence are key factors in determining, whether a given method is suitable for a particular task - rst, we need to analyze the address space and routing entries distribution in order to determine preference for a method. 5. Methods Evaluation The Method performs well on the current routing tables, since it exploits their particular characteristics - the fact that prex length concentrates around certain values (exactly the boundaries of cut levels-6and)andthat routing table entries concentrate around certain values, which enables the Cut Method to achieve good compression, since it does not have to build that many lower level chunks. The LC-Trie Method performs better as a general method of providing a forwarding scheme for unbiased data, however, in particular unfavorable cases might be less ecient. As for the build time measurements, the values on larger data proved unrealistic and incomparable due to the networking environement, which had more inuence over the outcome then the methods themselves. The build time can correctly be compared only in relation to the dynamic structure at the Central Processor, which has yet to be developed for both methods.. 6 Open problems 6. Dynamic Structure For both methods it remains to be seen what would be the most convenient dynamic structure at the Central Processor, from which these static tables would be built. Clearly, none of the structures itself is dynamic in the form presented. An insertion or deletion of a node in case of the LC-Trie method might change the completeness property and force rebuilding the whole table. In case of the Method, insertion operation is possible, but deletion is impossible to carry out, due to the expanding of nodes - we are not able to tell whether a node is just expansion or an entry, once it is in the forwarding table. 6. Optimization Schemes The LC-Trie Method authors already implemented an optimized version, where a node is considered as complete and path is compressed even if there is only more than half of nodes present in its complete descendant's trie. However, this optimization adds high complexity to the build algorithm. 8

21 The Method proposal includes an optimization on the very sparse lower level chunks, on which dierent means of storing entries and lookup procedures could be applied. Such approach reduces the size in some cases considerably and might also lead to better lookup performance. However, it is somehow inconsistent with the overall lookup scheme and thus requires more complicated lookup and build algorithm with more conditional branches. With respect to simplicity of a potential router design, we did not include these optimizations in our experiments. An obvious candidate for another kind of optimization of the Method would be precomputation - rst let us nd out what would be good Levels of Cut (has to be a power of ) according to prex length distribution and then let the method operate on such levels. 6.3 Towards IPv6 Both methods obviously scale non-problematically to the higher level of 8 bit adresses, although, the memory requirements for the build process of the Cut Vector Method might be overwhelming. It remains to be seen how the future routing tables will be organized and what kind of prex distribution will emerge in order to pick the more convenient method. References [] S. Nilsson and G. Karlsson. Fast address lookup for Internet routers. Proceedings IFIP th International Conference on Broadband Communications '98, pp. -, 998. [] S. Nilsson's homepage. [3] M. Degermark, A. Brodnik, S. Carlsson, S. Pink. Small Forwarding Tables for Fast Routing Lookups. ACM Computer Communication Review, 7():3-, October 997. [] W. Doeringer, G. Karjoth and M. Nassehi. Routing on longest-matching prexes. IEEE/ACM Transactions on Networking, ():86-97, February 996. [5] Internet Performance and Analysis (IPMA) Project. Michigan University and Merit Network. [6] J. L. Bentley and M. D. McIlroy. Engineering a sort function. Software - Practise and Experience, 3():9-65. [7] P. L'Ecuyer. Ecient and Portable Combined Random Number Generators. CACM, June 998, Volume 3, Number 6. [8] R. Jain. The Art of Computer Systems Performance Analysis. JohnWiley & Sons, 99. 9