towards a full service network. CIDR. The rst development was cidr 13] which replaced the traditional full length address lookup with variable length pre x ...
Packet Filter Management for Layer 4 Switching Hari Adiseshu Subhash Suri Guru Parulkar Department of Computer Science Washington University St. Louis, MO 63130
Abstract
Packet lters are rules for classifying packets based on their header elds. A lter speci es a pattern for each of the key header elds, and an action that is applied to the packet matching this lter. Packet classi cation is essential to routers supporting services such as Quality of Service (QoS), Virtual Private Networks (VPNs), and rewalls. A lter con ict occurs when two or more lters overlap, creating an ambiguity in packet classi cation. Current techniques for resolving lter con icts are based on prioritizing con icting lters, and choosing the higher priority lter. We show that prioritizing does not always work. Instead, we propose a new scheme for con ict resolution, which is based on the idea of adding resolve lters. Our main results are a geometric framework for studying lters, an algorithm for detecting con icts in a lter database, and an algorithm for resolving con icts. In the special case of 2-dimensional (Source-Destination) lters, we present a very fast algorithm that can be used both for lter con ict detection as well as packet classi cation, thereby eliminating any redundancy between the control path and the data path. A simple version of the algorithm running on a 200 MHz Pentium workstation takes a few microseconds to perform con ict detection and classi cation on a lter database of 40 thousand lters. We also show how a more ecient packet classi cation scheme [11] ts into our framework, which can improve the detection time by another order of magnitude.
1
1 Introduction The Internet is undergoing fundamental changes both in the demand for bandwidth and in the demand for new services beyond the traditional best e ort service. The expanding set of users and the growth of multimedia content have led to exponential increases in the demand for bandwidth. This has fueled the demand for routers able to handle large trac volumes measuring in millions of packets per second. At the same time, router technology is advancing from simple destination based forwarding to incorporate a number of new capabilities which a ect the forwarding process. Successful deployment of these technologies and services is cruicial for the successful evolution of the Internet towards a full service network. CIDR. The rst development was cidr [13] which replaced the traditional full length address lookup with variable length pre x lookups. While cidr was motivated by the need to contain the growth of the routing table and to manage the exiting ipv4 address space in a more ecient manner, it is only recently [7, 11, 12, 2, 10] that schemes have been developed which allow pre x based ip packet forwarding at wire speeds for gigabit links. Quality of Service (QoS) in the Internet. The IntServ wg, the rsvp wg and the new Di Serv wg of the ietf have proposed schemes which rely on installing state in the network associating ip ows with a speci ed QoS. In the IntServ scheme this association is set up along a speci ed path using the rsvp signaling protocol, while in the evolving Di Serv scheme this association is set up out of band at border routers. In addition the newly setup QoS Routing wg is looking at ways in which packets owing between the same source and destination, but having di erent requirements can be routed di erently. In all cases, routers have to look at additional elds besides the destination eld in order to process the packet correctly. Firewalls. Orthogonal to the issue of QoS is the issue of security. Virtually all companies connected to the public Internet operate behind a rewall, which is a router that analyzes each packet entering and leaving the Internet and allows the packet to pass only if it meets some security policies. The policies are implemented in the form of a database associating speci c packets or sets of packets with speci c actions. VPN. Tying up security and QoS is the idea of Virtual Private Networks (vpns) which allow a company to seamlessly interconnect its geographically dispersed sites using public carrier networks. The carrier is responsible for programming its routers to handle packets
owing from or to its vpn customers with the required QoS. What is common in all the previous examples is that the routers in the networks all have state installed in them. The state is an association between a set of packets and the action to be performed on that set. The set of packets is described by the contents of some of the elds in the packets | this is sometimes referred to as a packet lter. The packet lters can include elds from the network layer (ip) as well as higher layer (tcp or udp) elds. For example, an application level ow can be described by a 5-tuple lter consisting of the ip source and destination address, the upper level protocol (tcp or udp) and the upper level protocol source and destination ports. Since the forwarding decision can involve the transport layer, packet forwarding based on matching packets to lters is sometimes referred to as Layer 4 Switching. As shown in Figure 1, 2
the state in the router is installed in the control path which is shown dotted, while the packets traverse the data path shown as a solid line, which is responsible for packet classi cation. Routing Agent
Control Path Data Path
Filter Conflict Detection & Resolution Reservation Signaling & Management Agent
Classifier State Packet Filter
Action
IP Output Processing
IP Packet
Input Processing
Packet Scheduler
Input Driver
IP Packet
IP
Output Driver
Figure 1: State installed in the packet classi er in a router. The state associates the set of packets described by the lters with speci c packet processing actions. The state is installed by routing updates, reservation and signaling protocols and by management entities. In order for the Internet to transform itself from today's chaotic logjam to the full service network of tomorrow, it is important to provide a fast and scalable solution to the problem of packet classi cation and lter matching. While this problem is under active study these days, a related problem has not been studied as well. Although lters provide a general mechanism for introducing new functionality in routers, they can also lead to ambiguities in packet classi cation. This occurs because with lters it is possible that a packet might get mapped to multiple lters, each with a di erent associated action leading to a con ict in packet classi cation. This important problem has not been studied so far. Consider a set of 2-tuple lters each consisting of an ip source and destination mask. Consider the lters (128:112:; ) and (; 128:132:). An ip packet with source and destination addresses (128:112:234:2; 128:122:34:51) will match the rst lter, but not the second. Assume a router has both lters in its database of lters, and it now receives a packet with source and destination addresses (128:112:234:2; 128:132:187:54). As can be seen, the packet matches both lters. Which lter should be selected? Each lter is associated with an action, and these two lters could potentially be associated with diametrically opposite actions. We refer to this problem as the problem of lter con ict. This can be split up into two distinct sub problems. First, how does one detect such con icts ? Second, given a set of con icting lters, how does one resolve these 3
con icts ? The focus of this paper is to present a fast and scalable solution to both problems. We do so by detecting such con icts and resolving them by adding new lters. The problem of con ict detection is a problem of the control path, where lters are added. Is high speed necessary in the control path? Consider, for example, a router processing 1000 lter updates/s. Note for comparison purposes that large scale telephone switches are designed to handle thousands of calls per second. The router has to process the lter update within 1000 microseconds, and that includes the entire control path processing, from receiving the message to admission control, from updating the classi er and the scheduler to propagating any control messages onwards. Clearly, any con ict detection algorithm cannot consume more than a small fraction of the total available time, and therefore has to operate within a few microseconds. The problem becomes more acute when we consider that the lter database can be large | the current Internet backbone routing pre xes themselves number more than 40000. We believe our approach to con ict detection and resolution in lters is fast and scalable enough to be used in the most demanding scenarios of today and beyond. We will cover the performance of our algorithm in greater detail in later sections and contrast it with approaches based on a linear search of the database.
Outline and Roadmap
Section 2 de nes lters abstractly and reviews current solutions to the lter con ict problem. We show that all the current solutions have potentially undesirable outcomes, caused by implicit and in exible mapping of packets to lters. Section 3 presents a key insight to our solution, namely, a con ict between two lters can be resolved by adding a new lter which covers the region of con ict. The intuition for our solution, as well as the nature of the solution are better understood by a geometric transform of the lter con ict problem, as presented in this section. We show that con icts between two lters have certain geometric properties which we exploit in our solution. We also show how solutions to con ict resolution based on lter reprioritization do not work in the general case. Section 4 provides the algorithm for the general solution of con ict detection in lters with arbitrary number of elds. We also show that the number of lters added by our algorithm is optimal in the sense that it is not possible to add fewer lters to resolve con icts. Section 5 provides both a framework algorithm and a concrete solution for 2-tuple lters, for example, lters consisting of ip source and destination address masks. This is important since 2-tuple lters consisting of (ip source, ip destination) addresses are the most widely used lters for unicast and multicast trac management. The principal features of our algorithm in this special case are as follows: Detecting whether a new lter con icts with the database takes a time proportional to the number of bits in the ip address and is independent of the number of lters in the database. Enumerating all lters that are in con ict with a new lter takes a time proportional to the number of con icting lters. Resolving all the con icts created by the addition of a new lter takes a time proportional to the number of con icting lters. We also explain how a newly proposed fast lter classi cation scheme [11] ts into the framework algorithm and can be used to reduce con cit detection times even further, at the expense of increased update times. 4
Section 6 provides experimental results to verify that the performance of our fast algorithm actually is consistent with the desired goal in terms of time, and stays constant irrespective of the number of lters in the database. We contrast our fast algorithm with a linear search through the database in which the con ict detection time rises linearly with the size of the database, becoming two orders of magnitude slower when the database size exceeds 3000 lters. We also show that the memory costs of our algorithm are not high| the database of 30000 lters consumes only 1.7MB. With 16 MB costing around $100 today, we consider the memory costs to be modest. Section 7 presents conclusions and plans for future work. We discuss why the problem of extending our algorithm beyond 2-tuples is so hard, scenarios where we believe the algorithm can be used, and ways to speed up the implementation. Finally, we discuss the use of the algorithm not only for con ict detection, but also for packet classi cation.
2 Con icts in Filters Abstractly, a lter F is a k-tuple (F [1], F [2], : : :, F [k]), where each eld F [i] is a pre x bit string. Each pre x string x: determines a range of addresses, namely, [x0 0; x1 1]; the number of bits appended to x is the di erence between the maximum bit length of x's eld and the number of bits speci ed in x. For instance, the pre x 10 in a 4-bit eld determines the range [1000; 1011] = [8; 11]. We say that an address X matches a pre x x: if X lies in the range [x0 0; x1 1]. We say that a packet P matches a lter F , if each eld of P matches the corresponding pre x of F . For instance, an ip packet with source and destination addresses (128:112:234:2; 128:122:34:51) matches the 2-tuple lter (128:112:; 128:122:), but not the lter (128:112:; 128:132:). Each lter F is associated with an action, denoted A(F ). A packet P matching a lter F should be processed based on A(F ). The problem with lters is that a packet might match multiple lters with con icting values for the action. To illustrate the problem of con icts in lters, let us consider the case of simple 2-tuple lters, consisting of source and destination ipv4 address pre xes. The two elds can either be fully speci ed or wildcarded, or can be partially wildcarded in standard pre x format. Let 128:112: denote the pre x corresponding to network x and let 128:122: denote the pre x of network y. Consider two lters F1 = (128:112:; ), with A(F1 ) =fbw = 100 Mbpsg, and F2 = (; 128:122:), with A(F2 ) =fbw = 1 Mbpsg. The rst lter assigns all packets from source network x a bandwidth of 100 Mbps while the second lter assigns all packets destined to network y a bw of 1 Mbps. Now, consider what happens if the router starts receiving a 10 Mbps ow from source net x destined to net y . We have a con ict since the packets of the ow match both F1 and F2 . Which lter should take precedence? Some of the possibilities are: a) The rst matching lter in the lter database takes precedence. For example, if F1 is stored before F2 in the database, then the ow goes through. On the other hand, if F2 is stored before F1 , than most of the packets of the ow are dropped. This approach is commonly used to resolve con icts in rewalls, where incoming packets are matched against lters speci ed in access control lists and the rst access control list matching the packet determines if the packet crosses the rewall or is dropped. b) Assign priorities to di erent lters, and use the matching lter with the highest priority. This scheme turns out to be identical to scheme a) if we sort the lters in the order of priority.
5
c) Assign priorities to elds so that in case of multiple matches the lter with the most speci c matching eld with the highest priority is selected. For example, if the source address is given higher priority on matches than the destination address, then for packets going from network x to network y the lter F1 is a better match than F2 .
All of these implicit con ict resolution schemes, while simple to implement, su er from some serious drawbacks. For example, in case a), as we have already discussed, depending on whether F1 or F2 is listed, packets of the ow will either go through or be dropped. Thus, this scheme imposes an arbitrariness on the con ict resolution. Case b), as mentioned, su ers from the same problem. In scheme c), with the lters described above, there is no way to assign a 1 Mbps bw for packets going from net x to net y . Thus, this scheme substitutes arbitrariness with in exibility in lter matching. If we substitute a rewall for the QoS aware router described earlier and substitute Allow/Deny for the actions associated with F1 and F2 , we see that lter con icts can also lead to security problems. We formally show in Section 3.1 why such implicit con ict resolution schemes do not work in the general case. At this point, we make a crucial observation: Suppose we introduce a new lter F3 = (128; 112; :; 128; 122:), with A(F3 ) =fbw = 10 Mbpsg, where A(F3) is the bw we wish to assign to packets from net x to net y , and match lters based on most speci c match on all the elds. Then we eliminate the con ict with respect to packets from net x to net y . This follows because now these packets will match F3 rather than F1 or F2 . In short, we have resolved the lter con ict by the addition of a new lter, which explicitly tells us the action to take in the region of con ict.
Related Work
As mentioned earlier, we are not aware of any prior work which explicity addresses the problem of detecting and resolving con icts in lters. Con ict detection among lters is related to the abstract problem of multidimensional range searching, which is studied in computational geometry. The lter database corresponds to a set of N k-dimensional rectangular boxes, and the object is to determine the subset of boxes that intersect a query box. Edelsbrunner [5] has proposed a data structure that can solve this problem in worst-case time O((log N )2k?1 +R), where R is the number of rectangular boxes intersecting the query box. The data structure requires O(N (log N )k?1) space and O(N (log N )k?1) construction time. Unfortunately, the lter con ict problem is somewhat di erent from the multi-dimensional rectangle intersection problem|while a lter contained inside another lter (a lter that is more speci c than the other in all elds) is not a con ict, the corresponding rectangles are considered intersecting in the geometric framework. Thus, the number of rectangle intersections R can be much bigger than the number of lter con icts C . Secondly, even for modest values of N and k, the worst-case time and space bound guaranteed by this data structure are hopelessly bad. For instance, when N = 10; 000 and k = 4, the algorithm guarantees a worst-case search cost of 137 = 62748517, meaning that it is no better than a linear search through the lters.
6
32
Y: IP Dst Address
2
0
Filter A = X1, Y1 A
B
Filter B = X2, Y2.* Filter C = X3.*, Y3
C D
Filter D = X4.*, Y4.*
X: IP Src Address
2
32
Figure 2: Geometric representation of 2-tuple lters. The two elds are the ipv4 source and destination addresses
3 A Geometric View Of Filters and Con icts Our solution to the problem of lter con ict detection and enumeration is motivated and better explained by a geometric transformation of the lter matching problem. To obtain this geometric transform we note that we can graphically view the 2-tuple lter described earlier as a region of a discrete 2-dimensional space bounded by 0 and 232 on each axis. Incoming packets correspond to points in this space. The problem of matching packets to lters is transformed into the geometric problem of matching points to regions within this discrete 2D space. To illustrate this mapping between lters and geometric spaces let us consider some simple 2-tuple lters as shown in Figure 2. A fully speci ed lter is a point, shown in gure as lter A with ip source address X1, and ip destination address Y1. A lter well speci ed in one eld and wildcarded in another eld is a line. As shown in the example, lters B and C fall into this category. For B the ip destination address is partially wildcarded (Y2.*) while the ip source address is fully speci ed (X2). A lter wildcarded in both elds is a rectangle like lter D in which both the source and destination ip addresses are partially wildcarded. Two lters can overlap with each other in two di erent ways. One is a full overlap in which every point of one lters is contained in the other. As shown in Figure 3 lter C is completely contained in lter D. We refer to C as the inner lter and D as the outer lter. The other type of overlap is a partial overlap also shown in Figure 3 with lters A and B. Note that in case of partial overlap neither lter is fully contained within the other. We note that two lters con ict if and only if they have a partial overlap. In case of full overlap a point which falls within the inner lter is matched to the inner lter rather than the outer lter since the inner lter is more tightly speci ed in all dimensions. In case of partial overlap we have a con icting region which is the area common to both lters. A point within this area cannot be unambiguously matched to either lter since neither is better speci ed than the other in both axes. Consider Figure 4 which shows two lters A and B partially overlapping. Note that if an incoming packet maps to region a1 or b1 there is no con ict as to which lter it corresponds to, but if the packet maps to region a2, which is the region of overlap, then we cannot determine 7
32
Y: IP Dst Address
2
0
Partial overlap between A and B A B D
Full overlap between C and D
C
X: IP Src Address
2
32
Figure 3: Overlapping Filters|Partial and Full Overlap Partial overlap between A and B in region a2. Packets in this region in conflict Packets in b1 belong to B
32
Y: IP Dst Address
2
a2
0
X: IP Src Address
b1 B
a1 Packets in a1 belong to A
A 2
32
Figure 4: Con icts caused by partial overlap unambiguously if the packet belongs to lter A or B. We make two important observations at this time: If each eld of the lter is a pre x, con icts can only be of the categories shown in Figure 5A. In particular it is not possible to have con icts of the type shown in Figure 5B. These types of con icts are only possible in case the elds are arbitrary ranges rather than pre xes. By the addition of a new lter which covers the con icting region we can eliminate con ict between two con icting lters. For example, in Figure 4, if we add a new lter covering the region a2 then we resolve the con ict between lters A and B.
3.1 Implicit Con ict Resolution Through Filter Reordering
With the geometrical model of lters, it is easy to understand why implicit schemes for con ict resolution based on lter reordering or reprioritization do not work in the general case. Consider 8
0
32
Y: IP Dst Address
2
Y: IP Dst Address
2
Regions of conflict
32
X: IP Src Address
2
0
32
Figure A- Overlaps possible with prefix filters
X: IP Src Address
2
32
Figure B- Overlaps not possible with prefix filters
Figure 5: Types of con icts possible and not possible with pre x wildcarded lters Figure 6 which shows four overlapping lters A, B, C and D. As can be seen, there are pairwise con icts between A-B, B-C, C-D and D-A. Assume that A has higher priority than B. This is shown geometrically by A being on top of B. Similarly, assume B has higher priority than C and C has higher priority than D. This implies that A has higher priority than D. Now, if we want to give higher priority to D rather than A in their region of con ict as shown in gure, it is not possible, since that would contradict the previous requirement that A has a higher priority than D. Note that by adding an explicit resolve lters in the region of con ict between D and A, we can solve this problem. The lter con ict problem can be formulated as a cycle elimination problem in a directed graph D . Speci cally, we model each lter by a node of a directed graph. We put a directed edge from node F to node G if lters F and G overlap and F has a higher priority than G. Unambiguous classi cation by lter prioritizing is possible if and only if this directed graph D is acyclic. Clearly, if D contains a cycle, then no reordering of lters can avoid ambiguous classi cation. But if D is acyclic, then we can perform a topological sort [9] of the nodes to re-prioritize the lters.
Theorem 3.1 If graph
contains a cycle, then the set of lters cannot be made con ict free without the addition of a new resolve lter. D
We note that a particular cycle can be eliminated by introducing a single resolve lter. For instance, consider the cycle A ! B ! C ! D ! A of Figure 6. Suppose we add a resolve lter E for the con icting pair (A; D), and assign E higher priority than both A and D. Thus, in the graph D , the edge D ! A is replaced by two edges A ! E and D ! E , and the cycle A ! B ! C ! D ! A is eliminated. It follows that the smallest number of resolve lters needed to eliminate all con icts is equal to the smallest number of edges whose removal from D makes the graph acyclic. This problem is known as the smallest feedback arc problem in combinatorial optimization, and it is a well-known NP-Complete problem [8]. Thus, no polynomial-time algorithms exists for 9
32
Y: IP Dst Address
2
0
B D A
C X: IP Src Address
2
32
Figure 6: Con icting Filters. Scenario where it is not possible to resolve con icts by reordering lters determining the smallest number of resolve lter whose addition plus re-ordering will make the lter database con ict-free. Our approach in this paper, therefore, is to add resolve lters for each pair of con icting lters. It is possible to combine our algorithm with some heuristic that tries to break as many cycles as possible with each resolve lter. We have not pursued that strategy yet.
4 The General Algorithm We recall that each lter F is a k-tuple (F [1], F [2], : : :, F [k]), where each eld F [i] is a pre x bit string. We say that two pre xes x: and y: are disjoint if there is no address common to them. Two lters are said to be disjoint if no packet header matches them both. We start with the most basic question: how to determine if two k-tuple lters have a con ict. The following theorem answers this question by giving a necessary and sucient condition for detecting the absence of a con ict. When the condition fails, we have a lter con ict.
Theorem 4.1 If two lters F and G do not have a con ict, then one of the following must hold: 1. 9i, such that the pre xes F [i] and G[i] are disjoint, for 1 i k. 2. 8i, F [i] is a pre x of G[i], or 8i, G[i] is a pre x of F [i].
Proof. If two lters are con ict-free, then they are either disjoint, or one completely contains
the other. Condition (1) captures the case of disjoint lters, while condition (2) is meant to detect the second case. Since each lter can be represented as a rectangular box in the k-dimensional space, if two lters are disjoint, then there must be an axis i along which their projections are disjoint. (This is equivalent to saying that the two disjoint axis-parallel rectangular boxes can be separated by an axis-parallel plane.) In that case, the pre xes F [i] and G[i] are disjoint, showing that condition (1) holds. Let us now suppose that lter G completely contains F . This means that, along each axis i, the address range determined by F [i] is a subrange of G[i]. Equivalently, G[i] is a pre x of F [i], 10
for all i. Similarly, if F contains G, F [i] is a pre x of G[i], for all i. In this case, condition (2) holds, indicating that F and G do not have a con ict. If neither of the two conditions hold, then we must have a con ict. 2 Figure 7 presents the pseudo-code for detecting whether two k-tuple lters have a con ict.
Algorithm 2FilterConflict (F; G) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
(* Determines if F and G con ict. *) for i = 1 to k do if F [i] and G[i] are disjoint return \No Con ict"; Set Flag = 1; for i = 1 to k do if F [i] is not a pre x of G[i] Flag = 0; if (Flag = 1) return \No Con ict"; Set Flag = 1; for i = 1 to k do if G[i] is not a pre x of F [i] Flag = 0; if (Flag = 1) return \No Con ict"; else return \Con ict";
end Algorithm
Figure 7: Algorithm to determine if two lters have a con ict.
4.1 Detecting and Resolving Con icts Algorithm ResolveFilter (F; G)
(* Computes the lter resolving the con ict of F; G. *) 1. for i = 1 to k do 2. Let xi be the longer of the two pre xes F [i] and G[i]; 3. return (x1 ; x2; : : :; xk );
end Algorithm
Figure 8: Computing the lter to resolve con ict of two lters. If two lters F; G have a con ict, our solution is to introduce a new lter H , which is the lter corresponding to the overlap region F \ G. We will call H the resolve lter for F; G. What are the pre x elds for this resolve lter? It is not dicult to see that each eld of H is the longer of the two pre xes in the corresponding elds of F and G. For instance, if F = (101; 1) and G = (10; 111), then H = (101; 111). Figure 8 gives the pseudo-code for computing the resolve lter for two con icting lters. Figure 9 gives the pseudo-code for detecting and/or resolving con icts when a new lter is added. The set C (F ) in that code stores all the lters in the database B that have a con ict with the newly added lter F . If one is only interested in detecting whether a con ict exists, we can 11
quit as soon as Line 4 is executed for the rst time. If one is only interested in enumerating the lters in con ict with F , we don't execute steps 5{6, and simply list out the set C (F ). Finally, if we want to maintain a con ict-free database, we add the necessary resolve lters whenever a new lter creates con icts. Suppose that the existing database B = fF1; F2; : : :; FN g is con ict-free. Once the set C (F ), containing the lters of B that con ict with F , is determined, we compute the resolve lter corresponding to each Fi in C (F ), and add that resolve lter to the database B . A key point to notice that is that adding a resolve lter does not require a recursive call to the algorithm AddNewFilter. This is because adding a resolve lter does not create any new con icts. Thus, the worst case running time of the algorithm for adding a lter is O(N + C ), where N is the size of the current database and C is the number of con icts.
Algorithm AddNewFilter (F; B)
(* Insert a new lter into B . *) 1. Initialize C (F ) = fF g; 2. for i = 1 to jB j do 3. if F and Fi have a con ict then 4. Add Fi to C (F ); 5. for each lter F 0 2 C (F ) do 6. Add ResolveFilter(F; F 0 ) to B ;
end Algorithm
Figure 9: Modifying B upon the addition of a new lter.
4.2 A Bound on the Number of Resolve Filters
Adding a new lter to the database might result in inserting multiple resolve lters. A natural question is this: how many such lters may be added in a worst-case? Our algorithm adds a minimum number of con ict-resolving lters|a resolve lter is added only if the new lter F con icts with an existing lter G, and a con ict can only be avoided by the addition of a lter that maps to the overlap region of the two con icting lters. But is it possible to arrive at a worst-case quantitative bound for the number of resolve lters that may be added? ?We claim that the maximum number of resolve lters added by our algorithm in the worst-case is Nk , which is O((N=k)k). A proof for this bound follows from the format of a resolve lter. Consider a resolve lter H = (x1:; x2:; : : :; xk :). We notice that each xi is a pre x eld in one of the input lters|resolve lter do not generate new pre xes, only new combination ? of pre xes. If we add N lters to an initially empty database, then there can be at most Nk distinct resolve lters, since each of the k pre x elds can come from one of the N lters. In fact, it is possible to produce a list of N lters that leads to (N=k)k resolve lters. The worst-case behavior is caused by the set of N lters shown in Figure 10. The lters are organized in k groups, each with N=k lters. In this example, A1 ; : : :; AN=k are fully speci ed addresses for eld 1, B1 ; : : :; BN=k are fully speci ed addresses for eld 2, and so on. Now, consider adding these lters, one at a time, to an initially empty database. We claim that these lters lead to (N=k)k distinct con icts. In particular, every combination of k lters, choosing one from each group, leads to a distinct con ict. There are (N=k)k such con icts, and therefore (N=k)k resolve lters. 12
Field k
.. .
.. .
.. .
.. .
Field 1 Field 2
A1 .. .
AN=k
.. .
B1
BN=k
.. .
.. .
Z1
ZN=k
.. . .. .
.. .
.. . .. .
.. . .. . .. .
Figure 10: An example leading to (N=k)k resolve lters. The pre xes A1 , : : :, AN=k , B1 , : : :, ZN=k are fully speci ed (point) addresses.
5 An Improved Algorithm for 2-Tuple Filters The general lter algorithm presented in the previous section makes a linear pass through the lter database to detect any con ict and to add a new lter. This linear pass algorithm may suce for lter databases consisting of few hundred lters, but faster solutions are needed for larger databases. In this section, we develop a faster algorithm for con ict resolution in 2-tuple lters. Filters with 2 elds are an important case of packet lters; virtual private networks, for instance, can use ip source-destination pairs. We visualize the lter database in a router to consist of a large number of 1-tupe lters (routing pre xes), some amount of 2-tuple lters (QoS tunnels and VPNs) and 5-tuple fully speci ed lters for application level QoS. It is important to note that the 5-tuple lters do not con ict since they are fully speci ed, and similarly there is no problem with the routing pre xes since there is no notion of con ict with only one dimension. We therefore concentrate on fast con ict detection for 2-tuple lters. The key insight for the new algorithm is the following observation, which follows readily from the general result in Theorem 4.1.
Lemma 5.1 Filters F and G have a con ict if and only if 1. G[1] is a pre x of F [1] and F [2] is a pre x of G[2], or 2. F [1] is a pre x of G[1] and G[2] is a pre x of F [2].
We rst present a framework algorithm which exploits this property before presenting an instance of such an algorithm.
5.1 Framework Algorithm
The algorithm starts with a set of exsiting lters and checks to see if a new lter con icts with any lter in the set. We explain through a process of successive re nement using an example 13
set of lters as shown in Figure 11. A, B, C, D and E constitute the existing set of lters while F is the new lter. While our algorithm can handle any two pre x elds, let us use source and destination addresses for concreteness as shown in gure. We begin with a Best Matching Pre x (BMP) search on the source addresses to check for the best match for lter F. We can do this with any point in lter F, since pre xes do not overlap | we select the left endpoint of F. The search yields the lter D. We search the destination range of D to see if it con icts with F or not. In this case there is no con ict. 2
32
IP Dst Address
E
F
B
C 0
A
D IP Src Address
2
32
Figure 11: Framework Algorithm - Step 1. BMP lookup on rst eld However, if lter F were located as shown in Figure 12 and we were to do the same BMP search on source addresses, we would get lter B, since the source address range of lter B is the best matching pre x for any point in F. As can be seen B does not con ict with A, while lter C does. In order to detect this con ict, it is necessary for the BMP lter to store not only its destination address range, but also the destination address ranges of all lters whose source addresses are a pre x of its own source address, i.e., B should store details of A and C too, since A's and C's source address range is a pre x of B's source address range. Now a check of these destination address ranges reveals that F con icts with C. As seen in Figure 13, the BMP search for the left endpoint of F does not meet a match, even though F con icts with C. To address this situation, we need to do the same steps outlined above, but now reversed so that we begin with a BMP search of the destination address ranges of all the lter, followed by a check on the source address range of all matching lters.
5.2 Trie Based Con ict Detection Algorithm
We will use the example database B shown in Figure 14 to illustrate our scheme. We develop a 2-dimensional recursive trie data structure to solve the lter con ict problem. We begin with some basic de nitions and facts about tries. Recall that a trie is a binary branching tree, with each branch labeled 0 or 1. The bit string 14
2
32
A
IP Dst Address
E
B
D C
0
F IP Src Address
2
32
Figure 12: Framework Algorithm - Step 2. Do lookup on second eld associated with a node u is the concatenation of all the bits from the root to the node u. A trie node v is an ancestor of another node u if v lies on the path from the root to u. Stated another way, the bit string associated with v is a pre x of the bit string at associated with u. If v is a ancestor of u, then u is called a descendant of v . (In Figure 15, for instance, the node c is an ancestor of node d and a descendant of node b.) Our algorithm will need two complementary data structures, one for each of the two cases of Lemma 5.1. In particular, one data structure can eciently isolate the lters whose source eld is a pre x of F 's source eld, and then organize these lters to quickly determine if any of them has the destination eld with F [2] as a pre x. The second data structure reverses the roles of source and destination elds.
Recursive Trie 1
We start by building a trie on all the source address pre xes in the database B . We call this the source trie S (B ). Let u be a node in this trie, and let s(u) denote the bit string associated with u. We associate a second trie D(u) (destination trie) with u, which stores the destination pre xes of the lters whose source pre x is exactly s(u). More precisely, let us de ne the set
X (u) = F B F [1] = s(u) : f
2
j
g
That is, X (u) is the set of lters with source eld equal to s(u). We build a secondary trie D(u) on the destination addresses of the set X (u), which is pointed to by the node u. Figure 15 shows the complete construction. Nodes of destination tries are labeled with the lters associated with that destination address.
15
2
32
A
IP Dst Address
E
B
D F
C
0
IP Src Address
2
32
Figure 13: Framework Algorithm - Step 3. Repeat with BMP lookup on second eld
Recursive Trie 2
The second data structure builds a trie on the destination pre xes in the database B ; call this the destination trie D(B ). For each node u in D(B ), let d(u) be the string associated with u. De ne the set Y (u) = fF 2 B j F [2] = d(u)g: Y (u) is the set of lters with destination eld equal to d(u). We build a secondary trie S (u) on the source addresses of the set Y (u), which is pointed to by the node u 2 D(B ). Filter Source F1 10 F2 10 F3 10 F4 1 F5 1 F6 1 F7 0
F8
Destination 100 011 001 00 11 10 101 1
Figure 14: An example 2-tuple lter database.
16
b 1
0
c
a 1
0
d
0
F8
0
1 0
0 1 F7
1 0
1
1 F3
1
0
F2
F1
1
0
0
F4
F6
1 F5
(Destination trie for node c.)
(Destination trie for node d.)
Figure 15: Recursive Trie 1 for the example database of Figure 14. The source trie S (B ) is shown with thick solid lines; various destination tries are shown in thin lines; dashed lines indicate pointers between a node and its associated destination trie.
5.3 The Con ict Detection Algorithm
Suppose we want to add a new lter F to an existing database B and, if there are con icts, modify the database by adding appropriate resolve lters. We will search both Recursive Tries 1 and 2. When searching Recursive Trie 1, we rst use the source trie S (B ) to locate the longest matching pre x of the source eld F [1]. Let u be the node with this longest matching pre x, and let v1 ; v2; : : :; vm be the nodes in the source trie whose bit strings correspond to (proper) pre xes of F [1]. Observe that v1 ; : : :; vm are all ancestors of u, and possibly u = v1 . We visit each of the destination tries D(v1 ); D(v2); : : :; D(vm) in turn. In each destination trie, say, D(vi ), we locate the longest matching pre x of the destination eld F [2]. If the node z with the longest matching pre x is a leaf then no lters in D(vi ) are in con ict with F . Otherwise (if z is not a leaf), all the lters associated with descendants of z are in con ict with F . The search in the second structure, Recursive Trie 2, is similar, except the roles of source and destination elds are reversed. The completes algorithm is given in Figure 16. As an example, suppose we want to add a lter F = (10; 1) to the database of Figure 14. Then, the node d of the source trie gives us the longest matching pre x for the source eld 10. The ancestors of d associated with pre xes of the source string 10 are b and c. We search the destination trie pointed to by c to locate the longest matching pre x of the destination eld 1. The node with this string is not a leaf, and so all the lters that descend from it are in con ict with F . There are two such lters, F5 and F6 . Indeed, it is easy to see that F5 = (1; 11) and F6 = (1; 10) both have a con ict with F = (10; 1). Next, we search the destination trie pointed to by b, and nd that the node with destination pre x 1 is a leaf. A search of Recursive 17
Trie 2 discovers no new lter con icts, and so there are only two con icts.
Algorithm FastDetect (F; B)
(* Improved algorithm for detecting con ict in 2-tuple lters. *) 1. Initialize C (F ) = fF g; (* Search Recursive Trie 1 *) 2. Let u be the node in the source trie S (B ) for which s(u) is the longest matching pre x of the source eld F [1]; 3. Let v1; v2; : : :; vm denote the nodes in S (B ) whose bit strings correspond to (proper) pre xes of F [1]; 4. for i = 1 to m do 5. Determine the node z in D(vi ) whose string is the longest matching pre x of the destination eld F [2]; 6. Add to C (F ) all the lters stored with a descendant node of z ; (* Search Recursive Trie 2 *) 7. Let u be the node in destination trie D(B ) for which d(u) is the longest matching pre x of the destination eld F [2]; 8. Let v1; v2; : : :; vm denote the nodes in D(B ) whose bit strings correspond to (proper) pre xes of F [2]; 9. for i = 1 to m do 10. Determine the node z in S (vi) whose string is the longest matching pre x of the source eld F [1]; 11. Add to C (F ) all the lters stored with a descendant node of z ; 12. If C (F ) only contains F , then add F to B , and return \No Con ict"; 13. for each lter F 0 2 C (F ) do 14. Add ResolveFilter(F; F 0 ) to B ;
end Algorithm
Figure 16: Improved con ict detection algorithm for 2-tuple lters.
5.4 Correctness of the algorithm FastDetect
In this section, we argue that the algorithm correctly computes all the necessary resolve lters when adding a new lter F . First, we show that every lter G added to C (F ) has a con ict with F . Suppose G is added to C (F ) in line 6. Then, line 2 ensures that, in the source eld, G[1] is a pre x or F [1], and line 5 ensures that, in the destination eld, F [2] is a pre x of G[2]. Thus, by Lemma 5.1, F and G must have a con ict. A similar reasoning holds if G is added in line 11. The second part of the proof is to show that all lters in con ict with F are detected and added to C (F ). Consider any lter G 2 B that has a con ict with F . By Lemma 5.1, either condition (1) or (2) must hold. If condition (1) holds, lines 2-6 detect G; if condition (2) holds, lines 7-11 detect G. Thus, G is correctly added to C (F ). Next, we analyze the worst-case running time of the algorithm. 18
5.5 Analysis of FastDetect
We claim that the algorithm FastDetect takes O(wC + w2 ) worst-case time to add a new lter F , where w is the maximum number of bits in the source or destination elds, and C is the number of lters in B with which F has a con ict. We rst note that every trie in the data structure has height at most w, since the height of a trie is at most the number of bits in the source or destination eld. Let us consider Recursive Trie 1; the other search is identical in worst-case complexity. Since source trie S (B ) has height at most w, there can be at most w ancestors of the longest matching pre x node u. Thus, in steps 3{4, we search at most w destination tries, each of height at most w. In each trie, searching for the longest matching pre x of the destination eld takes w steps. Suppose z is the node with the longest matching destination pre x. If z is a leaf node, then there is no con icting lter in this trie. Otherwise, if z is an internal node, then every lter lying in the subtree below z has a con ict with F . We can list out all such lters at a cost of w per lter, by simply traversing the whole subtree below w. Thus, the total time complexity is O(w2) for searching the w tries, and O(wC ) for enumerating the C lters that are in con ict with F . Once the C resolve lters are computed, the data structures, Recursive Tries 1 and 2, can be updated in O(wC ) time, as shown in the next subsection. Finally, note that both Recursive Tries 1 and 2 need O(Nw) memory, since each stores a lter exactly once, and each lter requires O(w) space.
5.6 Updating the Data Structure
The updating of the data structure is relatively straightforward. A lter F can be added to each of the two recursive tries in O(w) time. Speci cally, rst consider Recursive Trie 1. We search down the source trie S (B ) to see if the source eld F [1] exists. If not, we expand the trie to place an entry for the string F [1]. Let u be the node containing the source eld F [1]. We search D(u) to nd the node z that corresponds to the destination eld F [2]. The node z keeps a pointer to the lter F . Recursive Trie 2 is updated similarly. The update cost is clearly O(w) per lter added. As mentioned in Section 4.1, if a newly added lter F con icts with C existing lters, then the database can be made con ict-free by the addition of precisely C resolve lters|i.e. adding resolve lters does not lead to new con icts. Thus, if adding a new lters creates C con icts, we can update the data structure in O(w2 + wC ) worst-case time.
5.7 Improving Con ict Detection Times
The straightforward trie based search outlined above has the advantage of an update time independent of the number of lters in the database. However the lookup times are of O(w2). This is because when a lookup in the second level trie fails, we backtrack and restart at the root of the next rst level trie. It is possible to use precomputation and em switch pointers [11] to speed up search in a later trie based on a search in an earlier trie. We do not present the details here, since the addition of switch pointers and the necessary precomputation is already explained elsewhere [11]. The main point to note is that it is possible to reduce the con ict detection time from O(w2) to O(w) (More precisely O(log(w) + w=k) for a k-bit expanded trie). The tradeo is that the precomputation involved raises the lter update time to O(N ). The tradeo is summarlized in Table 1. 19
6 Experimental Results
6.1 Implementation Details
Due to patenting issues we did not implement the switch pointer based algorithm described above. We implemented the FastDetect algorithm using a 1 bit trie. The implementation consists of two procedures: an insert() procedure to insert a lter into the database of lters, and a detect() procedure to detect if a new lter con icts with the database (the actual FastDetect algorithm). The detect() procedure works in one of two modes. In the quick mode, it reports whether the new lter con icts with the existing set of lters in the database or not. In the detailed mode, it not only reports whether there is a con ict or not, but also enumerates the list of con icting lters. The implementation, is publicly available1 along with a log of all experiments. In the absence of any publicly available lter database, we constructed an arti cial database by generating ip source and destination addresses and masks using a uniform random number generator. The length of the source and destination masks were uniformly varied from 5 bits to 9 bits to simulate a range of address masks. The implementation was a user level program on the NetBSD operating system running on a 200 Mhz Pentium workstation. We now discuss the individual results. Linear Search
1000
Conflict Detection time (in microseconds)
Conflict Detection time (in microseconds)
FastDetect 300 100 30 10
No Cache With Cache
3 1 10
30
100 300 1000 3000 10000 30000 Number of Filters in Database
1000 300 100 30 10
No Cache With Cache
3 1 10
30
100 300 1000 3000 Number of Filters in Database
10000
Figure 17: Con ict detection time. fast detect is orders of magnitude faster than a linear search once the database size rises beyond 1000 lters
6.2 Con ict Detection
Figure 17 plots the time taken for the FastDetect algorithm in the quick mode to detect the presence of a con ict when a new lter is added to an existing set of lters. The number of lters in the database was varied from 10 to 30000. For a given size of the database, the gure shows 1
http://dworkin.wustl.edu/~ hari/testprog/
20
the average time taken for con ict detection for a new lter. The average time was computed by running the algorithm 1000 times, each time with a randomly generated lter, and then averaging the total time. Two curves are shown for the con ict detection times|one for the cached case and the other for the non-cached case. In the cached case, the algorithm was run repeatedly 1000 times with the same lter, while in the non-cached case the algorithm was run only once with each lter. As expected, the cached times are much better than the non-cached times. Also, as can be seen, the con ict detection time rises much more slowly than the size of the database. As the size of the database increases from 10 to 10000, the con ict detection time rises from around 2 microseconds to 6 microseconds and levels o there. Essentially, once the database size exceeds a certain limit, the algorithm takes a constant amount of time to detect con icts, matching the theoretical bound O(w2), which is independent of the database size. We noted in the introduction that with a target signaling rate of 1000 lter updates/s, the time to detect con icts should be be a small fraction of 1000 microseconds, which is met by our implementation. Figure 17 also plots the con ict detection time using a linear search of the database. Our ecient algorithm FastDetect outperforms the linear search even for database size as small as 20-30. For databases of 3000 lters, the linear search is full two orders of magnitude slower than FastDetect. We also observe that there is little di erence between the cached and the uncached cases for the linear search, since the linear search through the database is not able to make e ective use of the data cache.
6.3 Number of Con icts per Filter 16
16 10k filters
14
14
12
12
Number of Conflicts
Number of Conflicts
1k filters
10 8 6 4 2
10 8 6 4 2
0
0 0
100 200 300 400 500 600 700 800 900 1000 Adding a new filter
0
100 200 300 400 500 600 700 800 900 1000 Adding a new filter
Figure 18: Typical number of con icts for each lter. Mask varies from 5 bits to 9 bits Next, we now look at the number of con icts created by adding a new lter to an existing set of lters. Figure 18 shows the histogram of con icts created by the addition of a typical lter to a database with 1000 lters, and a database with 10,000 lters. We ran FastDetect in detailed mode 1000 times, adding a new lter each time, and plotted the number of con icts for each of those 1000 runs. As expected, for the 10K lter database, adding a new lter causes an order of magnitude more con icts than adding a lter to the 1K lter database. We also experimented with the distribution of lters masks. In the histogram of Figure 18, 21
700
700 1k filters
10k filters 600 Number of Conflicts
Number of Conflicts
600 500 400 300 200 100
500 400 300 200 100
0
0 0
100 200 300 400 500 600 700 800 900 1000 Adding a new filter
0
100 200 300 400 500 600 700 800 900 1000 Adding a new filter
Figure 19: Number of con icts per lter when masks are uniformly distributed from 1 bit to 32 bits. The number of con icts have increased compared to the previous gure. Less masking leads to ver large lters that con ict with practically every lter each lter eld is at least 4 bits long, and we let masks vary uniformly between 5 and 9 bits. As seen in the gure, the number of con icts is relatively small, always less than 16. If we require longer masks, such as between 8 and 15 bits, the number of con icts decrease even further. In fact, the number of observed con icts almost dropped to zero. Figure 19 shows the histogram when the lter masks are allowed to uniformly range from 1 to 32 bits. In this case, the number of con icts surges dramatically. The problem with letting the lter elds vary uniformly over the entire range is that it creates many large lters (with elds like 1, 0) that overlap with most lters. In general, the better speci ed a lter (the longer the mask), the less likely it is to cause a con ict. Conversely, the less speci ed a lter (fewer mask bits), the more likely it is to generate con icts.
6.4 Con ict Enumeration
How much time does FastDetect take to enumerate the list of con icting lters, as opposed to simply detecting the presence of a con ict? Of course, this depends on the number of con icts. Figure 20 shows the time taken for the FastDetect algorithm in the detailed mode to detect con icts and to list the set of con icting lters. This is with a lter database with address masks between 5 bits and 9 bits. In comparison with Figure 17, we see that for small databases, the time taken for quick mode and detailed mode are roughly the same, but as the size of the database increases, the time taken for enumerating the con icting lters dwarfs the time taken for simple con ict detection. This again matches the theoretical observation that the con ict enumeration time is linear in the number of lters in the database. However, it is important to note that the time constant is heavily dependent on the lter distribution. In case the database contains lots of less speci ed lters with fewer mask bits, there are likely to be a lot more con icts, and correspondingly, the time taken to enumerate the con icts will increase.
22
Conflict Detection and Enumeration time (in us)
15
10 9 8 7 6 5 4 3 2 1
No Cache With Cache
10
30
100 300 1000 3000 Number of Filters in Database
10000
Figure 20: Con ict enumeration using Fast Detect.
6.5 Memory Usage
Figure 21 shows the memory utilization of the FastDetect 1 bit trie implementation. Both axes are in log scale. Adding an entry can take up a variable amount of memory depending on the amount of branching of the trie that is distinct from other entries. This leads to non linearities in the database size for small databases, but as the database size increases, the average amount of memory added for each entry becomes roughly the same, leading to a linear increase in database size with increasing number of entries. We observe that the memory cost of 1.7MB leads to a cost of around $10 with the current rate of DRAM memory being $100 per 16 MB.
7 Conclusions
Filters are powerful tools for reducing state in networks supporting QoS. However, multiple overlapping lters can cause con icts in mapping packets to lters. This paper describes the problem and presents innovative solutions based on a geometric transformation of the problem. A general solution is presented for the k-tuple lter, and an optimized version is described for the more common 2-tuple lters consisting of source and destination addresses. The 2-tuple algorithm is able to detect con icts in a time independent of the number of lters in the lter database, and is able to resolve them in a time linear with the number of con icting lters. We have experimentally validated these results using a 1-bit trie implementation, which yielded con ict detection and resolution time in the order of microseconds on a 200 Mhz Pentium workstation. We forsee three principal uses of this algorithm. One is to analyze existing lter databases in rewalls and QoS aware routers to detect con icts. Another use is in Di Serv networks at network entry points where the border routers will mark speci c packets with ow labels based on state setup in the lter database. The third is in next generation signaling protocols which will carry lters and related packet handling information [1, 6]. As the signaling information propagates through the network, network routers can use the algorithm to report con icts back to the originators of the signaling requests. It could be argued that since resolving con icts by adding new resolve 23
Memory (in bytes)
1e+07
1e+06
100000
10000
1000 10
30
100 300 1000 3000 10000 30000 Number of Filters in Database
Figure 21: Memory usage of FastDetect lters would require policy input and possibly human input, there is no need for a fast con ict detection and resolution algorithm. However, as these examples illustrate, the con ict detection is done at one site (a router processing the signaling message) and the con ict resolution is done elsewhere (the source of the message). It is important for routers to be able to process signaling messages as fast as possible in order to leave enough processing power for other tasks like packet forwarding, scheduling and routing updates. We plan to study the use of this algorithm in the IntServ/Di Serv testbed with enhanced signaling [6] we are currently building. It is important to note that while the con ict resolution is primarily aimed at IntServ/Di Serv lters, it can also be applied to lters in rewalls, multicast routers and network monitoring equipment.
Implementation Optimizations and Packet Classi cation
Both the quick and detailed mode running times of the FastDetect algorithm can be decreased by an order of magnitude by moving from a 1 bit trie implementation, like our current implementation, to multibit tries. In particular, fast multibit hashed trie lookups designed for ip pre x matching [4] can reduce the con ict detection times to nanoseconds. The advantage of this scheme is that the insert() procedure is straightforward, while the fast schemes have slower insert() procedures, besides increased memory cost. As described, the algorithm and trie data structures are used only for lter con ict detection in the control path. It is however, possible to reuse the tries for packet classi cation in the data path as well. The main issue here is the speed. Using the trie for packet classi cation yields lookup times comparable to the time taken for con ict detection, in the order of a few microseconds with our current 1 bit implementation. As explained above, it is possible to reduce this by a factor of k while increasing memory utilization 2k times by using k-bit tries. 4 bit tries, for example, can reduce average lookup times to around 1 microsecond. While this is not state of the art, this o ers a good blend of memory utilization and fast insert times, which makes it suitable for border routers which do not have a very high packet throughput, but which need to handle a lot 24
of signaling messages. We contrast the use of our scheme for packet lookups with two state of the art fast packet classi cation schemes in Table 1. Scheme
FastDetect
Set Pruning Trees [11, 3] Grid of Tries [11]
Space Complexity
O(n) O(n2) O(n)
Time Complexity
O(w2) O(2w) O(2w)
Update Cost
O(w) O(w) O(n)
Table 1: Comparison of di erent schemes for packet classi cation. Assume n lters in the database, and each eld of the lter has w bits.
Extensions to the algorithm
Both the general algorithm and the optimized version for the 2-tuple case work on lters with pre x strings. However, lters are sometimes speci ed as ranges. For example, a rewall might block an arbitrary range of ports. It is always possible to transform a subrange of [0, 2k ] into at most 2k pre xes [11]. Thus, a lter with arbitrary ranges can always be transformed into a set of lters with pre x strings. We therefore do not view this as a limitation of our algorithm. We are currently working on fast versions of the con ict detection algorithm for k-tuple lters, where k > 2. One may be tempted to use FastDetect on every pair of elds, and conclude that it nds all con icting lters. Unfortunately, just because k-tuple lters F and G con ict in two elds, it does not necessarily mean that F and G are in con ict. As an example, lters F = (1; 11; TCP) and G = (10; 1; UDP) con ict on the rst two elds but are clearly con ictfree, as evidenced by the third eld. A natural idea would be to build recursive tries with k levels, and use each level to prune the lter database along one of the elds. Unfortunately, the obvious extension of FastDetect is inadequate|speci cally, lters whose eld i is a pre x of lter F 's eld i are compactly stored in a trie, but lters whose eld i is an extension of F 's eld i are not compactly stored. This makes the pruning problem dicult. Finally, in some application level lters, the protocol eld as well as the upper level port numbers are fully speci ed. In those cases, our 2-tuple algorithm can be used for 5-tuple con ict detection. We simply use the protocol and port numbers as a hash key to group lters with a common hash key.
References [1] B. Braden, L. Zhang, S. Berson, S Herxog and S Jamin. Resource Reservation Protocol (RSVP) { Version 1 Functional Speci cation. In RFC2205, September 1997. [2] B. Lampson, V. Srinivasan and G. Varghese. IP Lookups using Multiway and Multicolumn Search. In Infocomm, 1998. [3] D. Decasper, Z. Dittia, G. Parulkar, B. Plattner. Router Plugins: A Software Architecture for Next Generation Routers. In Sigcomm, 1998.
25
[4] Waldvogel et. al. Scalable High Speed IP Routing Lookups . In Computer Communication Review, Vol 27, #4, October 1997. [5] H. Edelsbrunner. A New Approach to Rectangle Intersections (Parts I and II). In Int. J. of Computer Math., pages 209{229, 1983. [6] Hari Adiseshu, Guru Parulkar and Raj Yavatkar. A State Management Protocol for IntServ, Di Serv and Label Switching. In IEEE ICNP, 1998. [7] M. Degermark, A. Brodnik, S. Carlson and S. Pink. Small Forwarding Tables for Fast Routing Lookups. In Computer Communication Review, Vol 27, #4, October 1997. [8] M. R. Garey and D. S. Johnson. Computers and Intractability: A Guide to the Theory of NPCompleteness. W. H. Freeman, 1979. [9] Thomas H Cormen, Charles E Lieserson and Ronald L Rivest. Introduction to Algorithms. The McGraw-Hill Book Company, 1990. [10] V. Srinivasan and G. Varghese. Faster IP Lookups using Controlled Pre x Expansion. In Proc. ACM Sigmetrics, 1998. [11] V. Srinivasan, G. Varghese, S. Suri and M. Waldvogel. Fast and Scalable Layer Four Switching. In Sigcomm, 1998. [12] V.P. Kumar, T.V. Lakshman, D. Stiliadis. Beyond Best E ort: Router Architectures for the Di erentiated Services of Tomorrow's Internet. 1998. [13] Y. Rekhter and T. Li. Classless Inter-Domain Routing. In RFC1517, 1518, 1519, September 1993.
26
