Search tree for policy based packet classification in communication networks

[0002] This invention relates to the field of packet data communication networks. It is more particularly directed to packet data transmission systems that provide service to individual packets based on defined policy criteria.

[0003] This invention addresses the problem of efficiently supporting multiple services in packet networks. A key aspect of such support involves discriminating among different packets based on their contents and administratively defined policies. Most packet data networks, including the global Internet and various enterprise networks based on the Internet protocol (IP), have employed a “nondiscriminatory best-effort service model.” In this model, network offers a uniform service to all traffic, in the sense that devices treat all packets equally in terms of their access to resources. An alternate model, known as “policy based service differentiation model” has several advantages. In this model, network offers many kinds and levels of service where different packets may get different treatment based on administratively defined policies.

[0004] This latter service model is motivated by several factors. Firstly, the number and variety of applications that generate packet traffic in networks is continuously increasing. Each of these applications has varying networking service requirements. Secondly, technologies and protocols that enable provision of many kinds of services having different levels of security and Quality of Service (QoS) are widely available. However, access to these services needs to be regulated because these services consume resources such as network bandwidth, memory and processing cycles in network devices. Thirdly, business objectives or organizational goals may be better served by discriminating between different kinds of traffic in the network rather than by treating all traffic in a uniform manner.

[0005] The importance of these motivating factors is illustrated by considering some common examples:

[0006] Traffic generated by an application such as voice over IP (VOIP) requires a low delay service while that generated by a file transfer application can tolerate longer delays.

[0007] When two network service providers, or an enterprise and a network service provider, enter into a bilateral Service Level Agreement (SLA), the agreement may dictate that the service provider guarantee performance levels (e.g., bandwidth, delay, packet loss, etc.) to certain classes of traffic under specific conditions. Obviously, enforcement of such an SLA calls for policy based differentiation among various packets in the network.

[0008] Traffic generated by a web commerce application includes packets that carry sensitive financial transaction information which need a high level of security while most other web traffic does not.

[0009] A firewall that protects a company network may have to filter incoming traffic and selectively drop certain packets based on security policies.

[0010] A Virtual Private Network (VPN) implemented on a shared public packet data network may incorporate security and QoS features for specific categories of traffic.

[0011] As an example of how traffic could differ in its importance, consider the traffic generated by casual World-Wide-Web browsing by employees as opposed to that generated by important mission-critical applications. Since both kinds of traffic compete for the same network resources, the latter, being more important, should be insulated from the former.

[0012] A central requirement in enabling policy based service differentiation in packet networks, is that many network devices need to play an active role in classifying packets into categories based on applicable policy rules. It would be advantageous to have an efficient method to do such classification.

[0013] In general, rules that specify service differentiation policies are called Policy Rules and are of the form:

[0014] if (policy condition) then (policy action).

[0015] In the context of IP networks, which is one of the most common packet switched networks today, policy conditions are primarily specified in terms of various packet attributes. These attributes include header fields that identify source and destination addresses of the packet, applications identified by the source and destination port numbers, value of the protocol field, type-of-service-byte, etc. Additionally, policy conditions may also include other criteria such as time of day, identity of the local interfaces on which packet has arrived or will depart, etc. Such packet attributes and criteria used in choosing policy rules are herein referred to as ‘selector’ attributes. In general, policy rules are range based in the sense that policy conditions of the policy rules are defined in terms of ranges of selector attribute values.

[0016] Policy actions in policy rules include accepting or dropping data packets (for instance, in the context of a firewall functionality), accepting or denying a request for resource reservation (for instance, in the context of a protocol such as RSVP), encrypting data packets, authenticating the sender, (for instance, in the context of the IPSEC standards), metering the data traffic, marking the type-of-service byte in packet header, shaping the traffic rate, (for instance, in the context of the differentiated services standards).

[0017] FIG. 1 is an example of how policy administration may be organized. It shows a scenario in which a set of rules are defined as security policy rules (e.g. drop all incoming traffic that is destined to port number X, encrypt all outgoing traffic originating from sources in the address range A1 . . . A2, and leaving on interface Y) and another set as policy rules for quality of service based discrimination (e.g. mark all traffic from sources in the address range A1 . . . A2 and leaving on interface Y as high priority). These sets of rules are installed in a device 100 through configuration from a configuration utility 110. Device 100 is a network edge device that provides service differentiation. It contains security enforcement (filtering) module 120 and quality of service enforcement (filtering) module 130. These modules are respectively responsible for security and quality of service based differentiations. During configuration, an administrator configures the two modules over an interface 115 providing the modules 120130 with their corresponding policy rules. Such configuration is done from a console attached to the device. As data packets 140 arrive at device 100, the two modules 120 and 130 separately process the packet in an order that is determined by the device architecture. The data packets 145 leave the device after receiving appropriate conditioning treatment.

[0018] In this illustration, parts of the packet processing steps are similar in both modules 120 and 130. These steps involve determining which of the specified set of policy rules are applicable. Module 120 scans only the security policy rules, and module 130 scans only the quality of service policy rules. Each module also directly applies the relevant actions to packets once an applicable policy rule is found. Often, in practice, creating a meaningful higher level service requires combination of multiple lower level services. For example, a virtual private network service offering may combine both security and quality-of-service elements. In such a scenario, packets belonging to a certain class will require both security and quality of service specific actions. In the case illustrated in FIG. 1, this implies that such packets go through identical classification steps twice, once in module 120 and again in module 130. In general, in a network device architecture that implements policies through separate configuration of multiple service specific modules, there is likelihood of redundant steps in processing individual packets. This reduces the overall throughput.

[0019] The classification process to determine applicability of a set of policy rules to a packet is in itself a time consuming process. This is primarily because of the multiple dimensions and criteria involved. Each policy condition may be specified in terms of sub-nets or arbitrary address ranges (particularly when addresses are dynamically assigned) for source or destination, similarly for protocol and port number fields in IP packet headers. Assets are inefficiently used to preprocess a given set of rules and order them by priority. During packet processing, a module sequentially scans the list of policy rules to determine whether a given rule is applicable to the packet being processed. This is continued until a first match is found or the end of list is reached. If a match is found, the module applies the actions specified in the matched rule and hands over the packet to the next module after completing its processing. If no match is found, packet receives the default treatment in the module. Since such a sequential search is time consuming, some of the recent published work has sought to design more efficient packet classification methods. Two of the most relevant ones are discussed below.

[0020] Given the increasing importance of policy based service differentiation in packet networks, there is a need for efficient solution to the multi-attribute packet classification problem. Since such classification often consumes computational resources affecting the device performance, it is advantageous that this be done using a few simple instructions and avoiding redundant processing.

[0021] The following are definitions of terms used herein:

[0022] Selector attribute: A packet's attributes and/or administrative criteria used in defining policy conditions in policy rules. Values of selector attributes for a packet are used to determine which policy rules are applicable for that packet.

[0023] Policy Rule: A rule which specifies the specific treatment that is to be accorded to a particular class of packet traffic under defined conditions. It is generally of the form:

[0024] if (policy condition) then (policy action)

[0025] Policy Condition: A part of a policy rule that specifies a class of packet traffic and administrative criteria for which the rule applies. A policy condition is formally defined in terms of selector attributes.

[0026] Policy Action: A part of a policy rule that specifies particular action(s) to be executed when the policy rule is deemed applicable.

[0027] Range Based Policy Rule: A policy rule whose conditions can contain at least one range of values for one or more selector attributes.

[0028] Policy Based Classification: The process of determining which policy rules are applicable for a particular packet.

[0029] Multidimensional space: An Euclidean space in two or more dimensions. In an embodiment of the present invention, each dimension corresponds to a particular selector attribute.

[0030] Hypercube: Analogous to a rectangle in two dimensions or a cube in three dimensions. Also referred to herein as a box.

[0031] Point Location Problem: The problem of determining in which of a given set of hypercubes a given point in multidimensional space belongs. As used herein, the point location problem is obtained by modeling a packet to be classified based on policy rules as a point, and the policy rule conditions as hypercubes in a multidimensional space.

[0032] Hyperplane: Analogous to a line in two dimensions. In an advantageous embodiment of the present invention, a hyperplane is orthogonal to one of the coordinate axes.

[0033] Bounding Box: A hypercube that restricts the point location problem by guaranteeing that the given point must lie in this hypercube.

[0034] Left-subproblem: A smaller point location problem obtained by focusing on a portion of the multidimensional space that lies to the left (or any one side) of a chosen hyperplane.

[0035] Right-subproblem: A smaller point location problem obtained by focusing on the portion of the multidimensional space that lies to the right (or another side) of a chosen hyperplane.

[0036] Combined Policy-matching (or Policy rule matching) Engine (CPE): A module in the example architecture responsible for policy based packet classification.

[0037] Policy Manager/Repository (PMR): A module in the example architecture that stores the policy rules.

[0038] Policy Enforcement Entity (PEE): A module in the example architecture where actions specified by policy rules are executed.

[0039] Search Tree: A data structure that guides a policy classification process by specifying appropriate comparisons of selector attributes and branch instructions based on the results of a comparison.

[0040] Root Node: The first node of a search tree, where a packet classification process begins.

[0041] Intermediate Node: A non-terminal node of the search tree.

[0042] Leaf Node: A terminal node of the search tree.

[0043] Therefore, it is an aspect of the present invention to present methods, system, apparatus, computer devices and architecture for enabling policy based service differentiation in packet networks that reduce the number of packet classification steps.

[0044] It is yet another aspect of the present invention to provide a method of preprocessing a given set of policy rules by modeling the policy conditions in the policy rules as multidimensional boxes (hyper-cubes) to generate a search tree.

[0045] It is a further aspect of the present invention to provide a method of classifying packets to determine applicable policies with the help of the search tree using few and simple instructions.

[0046] It is still yet another aspect of the present invention to implement preprocessing of policy rules to build a search tree, and use the search tree to classify packets as computer readable program code contained on a computer usable medium.

[0047] In an embodiment of the present invention, the aforementioned aspects are achieved by identifying applicable actions for a packet in one classification step. This step itself uses few simple compare and branch instructions according to a search tree constructed by preprocessing policy rules using multidimensional box (hyper-cube) representations of policy rule conditions.

[0048] These and other aspects, features, and advantages of the present invention will become apparent upon further consideration of the following detailed description of the invention when read in conjunction with the drawing figures, in which:

[0049] FIG. 1 illustrates a system for enabling policy based services in packet networks;

[0050] FIG. 2 illustrates an example architecture in which classification steps are reduced by localizing these steps in a ‘Combined Policy-matching Engine’ in accordance with the present invention;

[0051] FIG. 3 illustrates an example representation of a policy rule condition as a rectangle (hyper-cube or box of dimension two) when only two attributes are used in accordance with the present invention;

[0052] FIG. 4aillustrates an example search tree formed as a binary search tree in accordance with the present invention;

[0053] FIG. 4bshows an example internal node in a binary search tree in accordance with the present invention;

[0054] FIG. 4cshows an example leaf node in a binary search tree in accordance with the present invention;

[0055] FIG. 5 shows an example flowchart of a packet classification process in accordance with the present invention; and

[0056] FIG. 6 shows an example representation of four different policy rule conditions using two attributes, with a hyperplane that may be considered during construction of the search tree in accordance with the present invention.

[0057] In the following description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific example embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

[0058] An example architecture 200 for discriminated policy-based services is shown in FIG. 2. The application of the methods outlined in this invention is not restricted to this architecture, which is provided solely as a guide for the purpose of illustration. A Policy Manager/Repository (PMR) 210 provides tools used by a network policy administrator to define, validate and store policy rules. The Policy Enforcement Entity (PEE) 240 resides in a device that processes packet traffic. For example, such devices may be either endhosts that generate packets, or routers that forward packets.

[0059] In general, the Policy Enforcement Entity 240 has several service specific modules that influence the treatment a packet receives in the device. Controlling the behavior of these modules results in the actions specified by the applicable policies.

[0060] In an embodiment, an entire (or a large part of a) classification operation is carried out in a Combined Policy-matching Engine (CPE) 220. As part of initialization, the Combined Policy-matching Engine 220 fetches a number of policy rules from the Policy Manager/Repository 210 and organizes them into an efficient search tree. This search tree is used by the Combined Policy-matching Engine 220 to provide traffic classification service to the Policy Enforcement Entity 240. It does this by reporting the results of classification in the form of the applicable actions that need to be executed within the service specific modules of the Policy Enforcement Entity 240.

[0061] FIG. 2 particularly illustrates this architecture in the context where the Policy Enforcement Entity 240 is an edge router. In this architecture, the Policy Enforcement Entity 240 obtains all actions that are applicable for a packet by querying the Combined Policy-matching Engine 220. The decisions returned by the Combined Policy-matching Engine 220 determine the actual treatment that a packet receives within the Policy Enforcement Entity 240. It may also influence the order in which the service specific modules, such as Security Enforcement Module 280 and QOS Enforcement Module 290, process the entering packets 240 before they leave the device in a possibly conditioned or transformed state 245.

[0062] The decisions 270 returned by the Combined Policy-matching Engine 220 depend on the following:

[0063] The set of policy rules obtained from the Policy Manager/Repository 210 over the interface 230.

[0064] The set of values for Selectors 260 which are defined as the attributes associated with an incoming packet that are necessary for packet classification. Policy Enforcement Entity 240 provides these values as inputs in the query using the Combined Policy-matching Engine Interface 250.

[0065] Some common and important selector attributes include the source address, destination address, protocol, source port, destination port, the Type Of Service (TOS) field, the ingress and the egress interface (for a router), etc.

[0066] Some internal state within the Combined Policy Matching Engine 220 that may be instantiated, set or modified by the various service specific modules of the Policy Enforcement Entity 240 using the Combined Policy Matching Engine Interface 250. For example, one policy at a firewall may dictate that all packets matching specified conditions be transmitted within an IPSec tunnel. When the first packet matching these conditions is received at the Combined Policy Matching Engine 220, it returns a decision 270 directing the Security module 280 to install an IPSec tunnel. In this case, after IPSec signaling has been successfully completed and tunnel state installed in the router, the Security Enforcement Module 280 instructs the Combined Policy-matching Engine 220 to return the tunnel handle as part of the decision returned for all succeeding data packets matching the policy conditions.

[0067] The selectors having values for a packet passed as input of query by the Policy Enforcement Entity 240, are important because policy rule conditions are defined in terms of their ranges. For example, a policy rule may be defined for specific source and destination address ranges. One important observation in this regard is that, selector values have numerical equivalents. Consequently, given a certain set of selectors, say “D” selectors, each policy condition is represented by a “D” dimensional box, or hyper-cube having edges wherein each edge is defined by one selector range.

[0068] FIG. 3 illustrates a policy rule condition for an example situation which has only two selectors, (“D”=2), say source and destination addresses. A packet with given selector values then can be represented as a single point 300 in a two dimensional space, with the source address attribute on the X-axis 310 and the destination address attribute on the Y-axis 320. Consider a policy rule whose conditions are defined by the source address range [s1330, s2340] and the destination address range [d1350, d2360]. With this geometric representation, the condition part of this policy rule is represented by a rectangle whose left and right boundaries along the X-axis are defined by the lines x=s1330, and x=s2340, and those along the Y-axis are defined by the lines y=d1350, and y=d2360. Thus, this policy rule is applicable to a given packet whose source address is ‘s’ and destination address is ‘d’, if the corresponding “point” representation of the packet 300 lies within the “box” representation 370 of the policy rule condition. Point 300, as shown in FIG. 3, does not lie in box 370.

[0069] In general, for “D” attributes, the packets are represented geometrically as points in a “D” dimensional space, and the policy rule conditions as “D” dimensional boxes (hypercubes) having faces defined by hyperplanes associated with the left (one side) and right (another side) boundaries of the attribute ranges in the policy conditions. Given a packet and a particular set of policy rules that are similarly represented, the policy matching problem can be thought of as identifying all the policy condition “boxes” to which the given packet “point” belongs. Priorities associated with corresponding rules are used to resolve ambiguous actions. This geometric representation of the packet classification problem is central to the search tree construction process. It allows the design of packet classification techniques that are flexible enough to deal with a wide variety of selectors and rules within a single framework.

[0070] An example of a search tree is shown in FIG. 4a. In the embodiment described, the search tree is a binary tree rooted at 400. The tree has two kinds of nodes, interior node 400 and 410, and leaf nodes 420, 422 and 424 in the illustration. The root node 400 is generally considered to be an interior node. Root node 400 has two integer values ‘d1’ and ‘v1’ and two pointers indicating the left 402, and right 404, subtrees.

[0071] FIG. 4bshows an internal node 410 of the tree in greater detail. An internal node stores a dimension number 442, a threshold integer value 444, pointer to left child node 446 and right child node 448.

[0072] FIG. 4cshows a leaf node 422 of the tree in greater detail. The leaf node 422 stores a short list of candidate boxes 462, and two lists of dimensions 464 and 468 associated with each candidate box. The lists specify the dimensions along which the lower and upper boundaries of a candidate box is to be checked to verify whether a given point belongs to that box. The precise meaning of these fields will become clearer in the context of the search tree traversal method described next.

[0073] Given a point p=(p_1, . . . , p_D) in “D” dimensions, the search tree is traversed to determine all the boxes that contain p. Generally, if no match is found, a default policy decision is returned.

[0074] An example of a search method is illustrated with a flowchart shown in FIG. 5. The search begins at the root node by assigning Current Node to the Root Node in the initialization step 500. This step also initializes Selector array with values from the packet attributes to represent it as a point in the “D” dimension space. The next step in each iteration is a comparison 510, which determines if the current node is an interior node or a leaf node. If it is an interior node, the search proceeds along path 512 to step 520. Step 520 assigns to ‘d’ the dimension number stored in the current node and to ‘v’ the threshold value from the current node. Next, comparison in step 530 checks if the value of a “d”th attribute in the selector array associated with the packet is at least as large as the value ‘v’ obtained in step 520. If so, the left child of the Current Node is made the new Current Node in step 540, otherwise, the right child is made the new Current Node in step 550. In either case, the search proceeds to begin another iteration with the comparison in step 510. Such iterations end when the result of comparison in 510 indicates that the Current Node is a leaf node. In this case, path 514 leads to the final step of 560, where each of the candidate rules in the leaf node are tested for applicability for the current packet.

[0075] This testing involves the following detailed sub-steps: If the list of candidate boxes stored in the leaf node is empty, then search terminates without finding a match. When this happens, a default policy decision is returned by the Combined Policy-matching Engine. Otherwise, each of the candidate boxes in the candidate list is considered for applicability, one by one. The applicability test for each box is aided by the two lists of dimensions associated with each candidate box. These are examined as follows:

[0076] Let W=((x_{1}, y_{1}), . . . , (x_{D}, y_{D}))

[0077] denote a candidate box. Here, x_{1} and y_{1} represent the lower and the upper bounds of the range in dimension 1 used to specify the condition. The pairs (x_{2}, y_{2}) (x_{3}, y_{3}), . . . , (x_{D}, y_{D}) have similar interpretations. The given point p belongs to box W if both of the following conditions hold:

[0078] i. for each dimension d in the upper bound dimension list associated with W, Selector Array[d]<=y_{d}, and

[0079] ii. for each dimension d in the lower bound dimension list associated with W, Selector Array[d]<=x_{d}.

[0080] If none of the boxes in the candidate list meets the above conditions then search terminates without finding a match. In this case, the default policy decision is returned by the Combined Policy-matching Engine.

[0081] During its initialization, the Combined Policy-matching Engine 220 fetches the relevant policy rules from the Policy Manager/Repository 210 and preprocesses them to construct the search tree. In a particular embodiment, for flexibility and the convenience of trading memory space for computation time, we allow for building the search tree based on fewer dimensions, say “D_e”, where “D_e” may be less than or equal to the actual number of Selectors “D” used to define policies. In this context of chosen set of selectors, two boxes,

[0082] W_1=((x_{11}, y_{11 }), . . . , (x_{D1}, y_{D1})),

[0083] and

[0084] W_2=((x_{12}, y_{12}), . . . , (x_{D2}, y_{D2})),

[0085] are defined to be equivalent, if the relations

[0086] x_{11}=x_{12}, and

[0087] y_{11}=y_{12}

[0088] hold for 1<=I<=D_e.

[0089] The detailed steps in building the search tree structure are described below.

[0090] Step 1. Initialization, Includes the Following Substeps:

[0091] Let S_{init}={W_1, . . . , W_N} represent the entire set of policy rules.

[0092] Let Y_1(S)={y_{ij}: W_j ε S} represent the set of right end-points in dimension i of all the boxes W_j in set S.

[0093] Let m_i and M_i denote respectively the minimum and maximum possible values in the i-th dimension.

[0094] Let B_{init}=((m_1, M_1), . . . , (m_D, M_D)) be the subset of the entire “D”-dimension space representing the bounding box. Any given point p in the classification problem must belong to B_{init}.

[0095] Step 2. Building the Search Tree:

[0096] The search tree is constructed by calling a recursive routine such as buildTree described below. The routine buildTree is first invoked with the variables S_{init} and B_{init} initialized in step 1.

[0097] The routine buildTree is described next. It accepts two input parameters: a list of boxes S and a bounding box B. It creates a new tree node and calls itself recursively to create left and right subtrees if the node created is an interior node. The bounding box B represents the region within which the given point p must lie if tree traversal during search reaches that newly created node.

[0098] An example, buildTree(S, B) routine is performed using the following steps:

[0099] If S is empty then create a leaf node with an empty candidate box list, empty upper and lower bound lists and terminate.

[0100] If all boxes in S are equivalent, or if none of the boxes in S has a right boundary y_d that is within the bounding box B, then create a leaf node as follows and then terminate:

[0101] Set the list of candidate boxes in the leaf node to S.

[0102] Let W=((x_{1}, y{l}), . . . , (x_{D}, y_{D}))

[0103] be a box in S. For each box W in S, create the two associated dimension lists as follows:

[0104] i. For each dimension 1<=d<=D_e, include d in lower bound list if x_d>m_d.

[0105] ii. For each dimension 1<=d<=D_e, include d in upper bound list if y_d<M_d.

[0106] Else, invoke the routine findBestCut (described below), with the parameters S and B. This routine evaluates the set of left and right boundaries Y_{i}(S) of boxes in S that are inside the bounding box B, according to a cost function (to be described later). It returns the best one as defined by dimension number d

[0107] and threshold value v*. Use these values in the next step as described below.

[0108] Create an interior node as follows:

[0109] i. set the dimension number and the threshold value in the interior node to d* and v* respectively.

[0110] ii. form left subtree as follows. Let S_{left} denote the boxes in S whose lower boundary along dimension d* is at most v*, that is,

[0111] S_{left}={W=((x_{1}, y_{1}), . . . , (x_{D}, y_{D})) ε S: x_{d*}<=v*}.

[0112] iii. Let B_{left} denote the bounding box for the left child as follows:

[0113] B_{left}=((m_1, M_1), . . . , (m_{d*−1}, M_{d*−1}), (m_{d*}, v*), (m_{d*+1}, M_{d*+1}), . . . , (m_{D_e}, M_{D_e})).

[0114] iv. Invoke buildTree with the parameters S_{left} and B_{left} to form the left subtree of the newly created interior node.

[0115] v. Let S_{right} denote the boxes in S whose upper boundary along dimension d* is strictly greater than v*, that is,

[0116] S_{right}={W=((x_{1}, y_{1}), . . . , (x_{D}, y_{D})) in S: y_{d*}>v*}.

[0117] vi. Let B_{right} denote the bounding box for the right child as follows:

[0118] B_{right}=((m_1, M_1), . . . , (m_{d*−1}, M_{d*−1}), (v*, M_{d*}), (m_{d*+1}, M_{d*+1}), . . . , (m_{D_e}) (M_{D_e})).

[0119] vii. Invoke buildTree with the parameters S_{right} and B_{right} to form the right subtree of the newly created interior node.

[0120] Recall that at each stage, the search tree construction works on two inputs: a set of boxes S and a bounding box B, and creates a new node in the tree.

[0121] The bounding box B represents the region within which a given point must lie if tree traversal during search reaches that newly created node. The findBestCut routine is used to create the new node. The findBestCut routine looks for a “good” D_{e−1} dimensional hyperplane. A hyperplane can be used to divide the original problem into two smaller subproblems. One subproblem deals with all those boxes from S that are partly or wholly to the “left” of the hyperplane, but not those that are wholly to its “right”. The bounding box for this subproblem is obtained by replacing the appropriate right boundary of the bounding box B by the hyperplane. Similarly the other sub-problem deals with those boxes that are partly or wholly to the “right” of the hyperplane but not those that are wholly to the left of the hyperplane. The bounding box for this sub-problem is obtained by replacing the appropriate left boundary of the bounding box “B” by the hyperplane.

[0122] FIG. 6 shows an example of problem decomposition using a hyperplane. The example involves four policy rule conditions in two dimensions. The x axis 601 and the y axis 602 are used for source and destination addresses, respectively. The four policy rule conditions are represented by four rectangles: C1610, C2620, C3630 and C4640. The original bounding box for the problem is the larger box 650.

[0123] Suppose a hyperplane defined by the right face of the box C2 along the source address dimension is being considered. In two dimensions, such a hyperplane is line 600, defined by x=y_{1,2} 605 in FIG. 6. With respect to this hyperplane 600, the original search space is divided into two smaller subspaces: a left one and a right one, and the original problem correspondingly is divided into a left and a right sub-problem. The original problem is reduced to the left sub-problem if it is known that the point to be searched is either on this hyperplane or to its left. On the other hand, it is reduced to the right sub-problem if it is known to be on its right.

[0124] Thus, the bounding box for the left subproblem 660 is obtained by replacing the right boundary of the original bounding box 650 along the x-axis by hyperplane (line) 600, the hyperplane of division. Similarly, that for the right subproblem 670 is obtained by replacing the left boundary of the original bounding box 650 along the same axis by the same hyperplane (line) 600. Since box C4640 is the only box from the original set of boxes that lies wholly to the right of the hyperplane 600, the left sub-problem deals only with boxes C1610, C2620, and C3630. Analogously, the right sub-problem deals with boxes C3630 and C4640 only, excluding the boxes C1610 and C2620 that are wholly on the left of the hyperplane 600. Note that box C3630, being “cut” by the hyperplane, is part of both the left 660 and right 670 subproblems. While the figure illustrates one such hyperplane, the findBestCut routine examines bounding surfaces of all boxes as potential cuts for subdividing the problem and returns the “best” one based on some criteria. The returned hyperplane is identified by the dimension number and the attribute value associated with the hyperplane. For example, the hyperplane 600 in FIG. 6 is identified by dimension=1 (x-axis) and threshold value=y_{1,2}

[0125] It should be noted that the choice of the hyperplane affects the depth of the tree, which is related to the search time and the size of the tree, which is related to the space requirements. It is often sufficient to consider only the unique right and left bounding surfaces of the boxes as candidate hyperplanes.

[0126] Generally, in an embodiment of the present invention, the following or other criteria is used to evaluate different hyperplanes in a given dimension:

[0127] Maximize the minimum of number of the boxes entirely to the left of the hyperplane and those entirely to the right of the hyperplane. Even more generally, one associates a weight with each of the boxes and maximizes the minimum of the weighted sum. Examples of weight assignments are:

[0128] i. the volume of the box that lies within the bounding box, or

[0129] ii. the number of edges of the box that lie within the bounding box.

[0130] It is advantageous to use a type of cost function and/or weight so that a hyperplane chosen according to this function tends to balance the “complexity” of the two subproblems. A balanced complexity tends to reduce the query time.

[0131] Minimize the number of boxes that lie on both sides of the hyperplane. A hyperplane chosen according to this function tends to reduce the space (i.e., memory) requirements.

[0132] Minimize the distance of the hyperplane from the center of the bounding box. This cost function also tends to balance the “complexity” of the two subproblems.

[0133] An advantageous embodiment uses a combination of the heuristics described alone or in combination with other heuristics. The findBestCut routine returns the best hyperplane from amongst all the dimensions.

[0134] The proposed architecture covers a number of different device arrangements depending on the function placement, including the following:

[0135] The Policy Manager/Repository may be collocated with the Policy Enforcement Entity and use a local configuration interface coupled with an internal database to provide the necessary functionality, or it may be implemented in a directory server which is accessible by a protocol such as LDAP.

[0136] The Policy Enforcement Entity, may be an end-host, where the packets are locally generated and intended for transmission on the network or it may be a network device such as a router or a firewall, where the packets are received on an incoming interface and are intended to be forwarded towards the ultimate destination.

[0137] The Combined Policy-matching Engine may be collocated with the service specific modules in the Policy Enforcement Entity. In this case the interface between them is a device specific API. Alternatively, the Combined Policy-matching Engine may be located in an external policy server and policy decisions may be outsourced to this device, while the service specific modules are located at the Policy Enforcement Entity such as the router or firewall. In such an architecture, the policy server functions as a single policy decision point serving a number of different network devices.

[0138] Thus an embodiment of the present invention may be implemented as a method for performing policy based classification of packets in a packet stream. The method comprising: obtaining a plurality of policy rules defined for a packet classification problem, the policy rules being range based; representing each policy rule condition as a hypercube in multidimensional space; choosing at least one hyperplane in the multidimensional space that divides a present classification problem such as to create an internal node having branches of a search tree, wherein each of the branches represents a sub-problem; and repeating the step of choosing by treating each sub-problem as being the present classification problem until a defined classification problem resolution is achieved.

[0139] In more particular embodiments of the method the step of choosing includes mapping the packet classification problem into a point location problem; and/or each policy rule includes at least one policy condition and at least one policy action; and/or conditions of the policy rules are defined in terms of ranges of selector attribute values; and/or the selector attributes include one or more of the following: source address, destination address, protocol, source port, destination port, incoming interface, outgoing interface, type of service value, and time of day; and/or the method includes creating a leaf node at each branch terminus at which the defined classification problem resolution is achieved; and/or the method includes storing in each internal node both a selector attribute identity and a threshold value corresponding with a respective said at least one hyperplane; and/or the method includes storing in each leaf node information about any candidate policy rule potentially applicable to a packet; and/or the information includes identity of every rule of the any candidate policy rule, and identity of any particular selector field attribute associated with the any candidate policy rule; and/or each particular selector field attribute is associated with at least one bound of a policy rule condition employed in performing a comparison to at least one specific attribute of each particular packet reaching the each leaf node; and/or the policy rule condition has an upper bound and a lower bound; and/or the step mapping includes limiting a search space to an original bounding box; and/or in each instance of the point location problem, the step of choosing the one hyperplane is restricted to choosing a hyperplane from among all bounding faces of hypercubes that lie within a current bounding box of the instance of the point location problem; and/or the bounding box for a left sub-problem is obtained by replacing a right boundary of the original bounding box in a same dimension as a dimension of the hyperplane; and/or the bounding box for a right sub-problem is obtained by replacing a left boundary of the original bounding box in a same dimension as a dimension of the hyperplane; and/or the method includes employing a particular hyperplane selected to divide a current instance of the classification problem to include all the hypercubes in the current instance of the classification problem that are to a first side of the particular hyperplane in a first sub-problem identified by a first branch of the internal node created, to include the hypercubes in the current instance of the classification problem that are to a second side of the particular hyperplane in a second sub-problem identified by a second branch of the internal node created, and to include all hypercubes in the current instance of the classification problem that are cut by the particular hyperplane in both the first and second sub-problems; and/or a defined level of resolution is said to have been achieved if a sub-problem at hand includes a defined number of hypercube faces lying within the current bounding box; and/or the step of choosing includes selecting a particular hyperplane which maximizes a minimum number of hypercubes constituting the current classification problem instance lying entirely to a first side and entirely to a second side of the hyperplane; and/or the step of choosing employs a secondary objective to choose the hyperplane which minimizes the number of hypercubes constituting a current classification problem instance that are cut by the chosen hyperplane; and/or the method includes traversing the search tree to identify applicable policy rules for each packet.

[0140] Alternate embodiments provide a method for classifying each of a plurality of packets in a packet stream on a packet based communication network, the method comprises: classifying a plurality of policy rules that apply to the packets based on multiple selector fields that include packet attributes; processing the policy rules for constructing a comparison based search tree structure; for each packet, identifying all the selector attributes that are relevant for packet classification; and traversing the comparison based tree structure to identify all applicable rules for each packet, where the applicability of a policy rule depends upon whether the selector attributes associated with a packet fall within a range of values determined from a policy rule specification.

[0141] In more particular embodiments of this method the packet attributes include at least one attribute chosen from a group consisting of values of header fields, header contents, identity of local interface on which packet arrived, and time of day; and/or the network is an IP network and the selector attributes include at least one attribute chosen from a group consisting of source address, destination address, protocol, source port, destination port, incoming interface, outgoing interface, type of Service value, time of day, and where policy conditions are specified using a range of values for at least one attribute; and/or leaf nodes of the comparison based tree specify a list of potentially applicable rules,

[0142] Another alternate embodiment implements the present invention as an article of manufacture comprising a computer usable medium having computer readable program code means embodied therein for causing policy based classification of packets in a packet stream, the computer readable program code means in the article of manufacture comprising computer readable program code means for causing a computer to effect: obtaining a plurality of policy rules defined for a packet classification problem, the policy rules being range based; representing each policy rule condition as a hypercube in multidimensional space; choosing at least one hyperplane in the multidimensional space that divides a present classification problem such as to create an internal node having branches of a search tree, wherein each of the branches represents a sub-problem; and repeating the step of choosing by treating each sub-problem as being the present classification problem until a defined classification problem resolution is achieved.

[0143] In more particular embodiments of the article of manufacture, the computer readable program code means in the article of manufacture further comprising computer readable program code means for causing a computer to effect: employing the search tree for classifying each of the packets; and/or creating a leaf node at each branch terminus at which the defined classification problem resolution is achieved; and/or storing in each internal node both a selector attribute identity and a threshold value corresponding with a respective said at least one hyperplane; and/or storing in each leaf node information about any candidate policy rule potentially applicable to a packet.

[0144] Another alternate embodiment implements the present invention as an apparatus for performing policy based classification of packets in a packet stream, the apparatus comprising: means for obtaining a plurality of policy rules defined for a packet classification problem, the policy rules being range based; means for representing each policy rule condition as a hypercube in multidimensional space; means for choosing at least one hyperplane in the multidimensional space that divides a present classification problem such as to create an internal node having branches of a search tree, wherein each of the branches represents a sub-problem; and means for repeating a step of choosing said at least one hyperplane by treating each sub-problem as being the present classification problem until a defined classification problem resolution is achieved.

[0145] In more particular embodiments of the apparatus, the apparatus includes means for employing the search tree for classifying each of the packets; and/or the means for choosing includes mapping the packet classification problem into a point location problem. and/or includes means for creating a leaf node at each branch terminus at which the defined classification problem resolution is achieved; and/or includes means for storing in each internal node both a selector attribute identity and a threshold value corresponding with a respective said at least one hyperplane; and/or includes means for storing in each leaf node information about any candidate policy rule potentially applicable to a packet; and/or a defined level of resolution is said to have been achieved if a sub-problem at hand includes a defined number of hypercube faces lying within the current bounding box; and/or the means for choosing selects a particular hyperplane which maximizes a minimum number of hypercubes constituting the current classification problem instance lying entirely to a first side and entirely to a second side of the hyperplane; and/or the means for choosing employs a secondary objective to choose the hyperplane which minimizes the number of hypercubes constituting a current classification problem instance that are cut by the chosen hyperplane; and/or includes means for traversing the search tree to identify applicable policy rules for each packet.

[0146] It is noted that the foregoing has outlined some of the more pertinent aspects and embodiments of the present invention. This invention may be used for many applications. Thus, although the description is made for particular arrangements and methods, the intent and concept of the invention is suitable and applicable to other arrangements and applications. Even though the embodiments and descriptions often refer to right and left subproblems, the invention is clearly useful for any type of node division in any plane. Thus, the left side is to be considered as just a first side and the right side is to be considered as just an other side. The concepts of the invention may be implemented as a system, apparatus and/or method. It may also be implemented as an article of manufacture comprising a computer usable medium having computer readable program code means embodied therein for causing policy based classification of packets in a packet stream. The computer readable program code means in the article of manufacture comprising computer readable program code means for causing a computer to effect methods implementing concepts of the present invention.

[0147] It will be clear to those skilled in the art that other modifications to the disclosed embodiments can be effected without departing from the spirit and scope of the invention. The described embodiments ought to be construed to be merely illustrative of some of the more prominent features and applications of the invention. Other beneficial results can be realized by applying the disclosed invention in a different manner or modifying the invention in ways known to those familiar with the art.