Patent Application
20100232426
This invention relates to methods and systems for flow-forwarding of data packets in packet networks (e.g. broadband data networks, Internet, etc.). In particular, the invention relates to techniques for implementing rules to be applied to packet flows that are efficient and so can be implemented on less expensive hardware.
As there are many possible valid combinations of actions that can be applied to data passing through a router, there is an equivalent number of valid rules. Each of these rules must be stored in the router, typically in one or more of the integrated circuit chips used to operate the router. The required capacity to store this large number of rules leads to the need to use higher cost chips in the routers. Larger capacity routers may store up to 100,000 rules.
EP 1557012 A (PACKETFRONT SWEDEN AB) 27.07.2005 discloses a router having a hardware accelerated path and a software accelerated path for data flow and a memory means for storing the appropriate path, hardware or software accelerated, for any given data flowing through the router. Constant updating of the memory means allows effective use of the limited hardware resources and avoids storing unused flows. Such an approach is known as ‘hierarchical flow forwarding’ (HFF).
A typical ‘n-tuple’ data flow, known here as a ‘micro-flow’ can be defined by a number of parameters, for example source IP address, destination IP address, IP protocol, source port in router and destination port in router. In its simplest ‘1-tuple’ form has these five data. With a typical router and 5-tuple IP flow there are potentially more than 1010 possibilities.
This invention recognises that similar data flows often have some of the parameters with values that are similar. For example, several users using the same basic router for a given service will have close values of source and destination IP addresses. By gathering or aggregating such flows, the number of rules needed can potentially be reduced.
One aspect of the invention comprises a method of forwarding a series of data packets in a data flow in a network, wherein the data packets having N predetermined parameters where N>1 and ranges of values of the N parameters defining an N-dimensional parameter space, and wherein the data flow is one selected from a series of aggregated data flows, the method comprising:
N is preferably five, in which case, the parameters can be numerical values indicating destination IP address (DST IP), source IP address (SRC IP), protocol, source port (SRC PORT) and destination port (DST PORT).
The parameter space can be limited by the maximum and minimum possible values of the parameters for the system of interest.
The method preferably comprises determining the number of data flows in each hyper-cube. Hardware or software acceleration can be applied to the data flows in each hype-cube. Preferably, hardware acceleration is applied to data flows in the hyper-cubes containing the highest number of data flows.
An individual data flow of the type described above in relation to
Example:
This invention uses the concept of an aggregated data flow formed from a number of individual micro-flows. Such aggregation can be where source IP addresses are all related to a single router and so vary only in the last component of the address; where destination IP addresses are also related to a single router; where the source and destination ports on the routers can be selected from a given number of possible ports.
Example:
This aggregated flow also includes the micro-flow described above and covers:
Such an aggregated flow has 70368744177664 possible variants in total. The total number of possible flows in a full IP five-tuple is 20282409603651670423947251286016.
This invention is based on the use of aggregate flows such as the one described above instead of using exact flow matches/micro-flows (as has been used previously in HFF, for example). This allows the operating system in the router to treat many IP sessions to/from one customer as one aggregated flow and reduce the possible number of flows into a minimum. There are several reasons why this can be desirable, including:
The invention also uses the concepts of N-dimensional parameter space and N-dimensional hyper-cubes in parameter space. In the examples given above, the five parameters defining either a micro-flow or an aggregated flow: SRCIP, DSTIP, Protocol, SRC PORT, DST PORT can be specified as independent numeric values. The ranges of each of these possible values can be considered as dimensions. In the cases given above, five parameters are used to describe the flows so the flows can be considered to have five dimensions and any flow described by these parameters can be considered to exist in the space defined by these five parameter dimensions. A micro-flow is a point in this parameter space. An aggregated flow is an N-dimensional body within this parameter space. A hyper-cube is a defined part of this N-dimensional space.
It will be appreciated that flows can be described in a number of dimensions. The example given above uses five parameters/dimensions, but other values of N can be used depending on the parameters being used to control the flow in question. To assist in understanding the invention, an example using just two dimensions, SRCIP and DSTIP can be considered. In this case, the hyper-cube is a two-dimensional polygon.
In order to optimise the performance of the router, it is important that the rules are applied independently. In the example of
An example of a method according to the invention follows. In this case, the traffic pattern is:
As will be appreciated, the only possible variability in this pattern is in the selection of destination port. All of the other parameters have a single value.
In this example, a policy “x1” having an access control list (ACL) attached to it is attached to the destination IP (i.e. any flow to this destination IP must be checked against the rules in the access control list):
x1 ACL
The access control list comprises the broad rules that define the regions in the parameter space. Rules 20 and 40 do not apply to the traffic pattern defined above as they apply only to TCP flows. As Rule 50 permits all flows, it makes no changes. Filtering the traffic pattern described above by applying these rules gives the aggregate flows shown in Table 1 below
The filter creates the deny-entries for destination ports 445, 137 and 138-139 and then it fills the rest of the “space” in this dimension with permit entries. We can also see that the “largest” flows are inserted in hardware as these flows get more hits than the others and so are better candidates for hardware insertion.
An input data packet is filtered through a synthesized input ACL. This is constructed by multiplying an interface input ACL, policy-maps and per-policy ACLs with each other. As a part of this operation all duplicate and otherwise meaningless entries are removed. The final input ACL is then structured in a five dimensional tree.
In order to perform a lookup in the input ACLs, all relevant fields from the packet are extracted and a separate lookup is done in each of the tree's dimensions. The result is then combined and a final rule is found.
The tree can be viewed as a set of non-overlapping ranges. For every lookup performed, the result will be a range, which is then used to form the start and endpoints of the hyper-cube in that respective dimension.
Forming of the hyper-cube occurs in a learning step. The input, forwarding and output ACLs each mask out the parts of the five tuple field for which that particular ACL has no relevance. The final result is that all the three steps together contribute in constructing a hyper-cube that is as big as possible without overlapping with any conflicting rules in the packet's path.
When constructing the flow, a ‘don't-care’ bit mask is ANDed with L3 and L4 fields to generate a power-of-two sized hyper-cube. The mask can be stored in a linked list for each block and represents the size of the cube. The flow itself can be stored in a per-mask hash. The flow-structure represents the “position” of the cube in the hyper space.
To be able to compute the maximum allowed size of the hyper-cubes to be created, five balanced binary trees are kept (one per dimension) for each list of filters (two per port, one for inbound traffic and one for outbound traffic).
Table 2 shows a simple set of rules 1-5 (*=any):
Slicing this in a per dimension sorted tree (i.e. determining which rule applies for each discrete value of a give dimension) gives the results shown in Tables 3-7 (an applicable rule is indicated by an X in the relevant column):
SrcIP
DstIP
Protocol
SrcPort
DstPort
The lookup is conducted by using a greater-or-equal search in each of the five trees. The result is then combined by searching for the first (lowest rule) number where all of the five dimensions have an ‘x’ marked.
The following packet is passed through the filter:
Searching the tree yields:
ANDing the result gives:
The first/lowest rule entry is 4. Consulting the filter chain, the packet should match rule number 4 just as this lookup yielded. This algorithm is known as the “Lucent Bit Vector Algorithm” and is described in detail in LI, Ji, et al. Scalable Packet Classification Using Bit Vector Aggregating and Folding. MIT LCS Technical Memo: MIT-LCS-TM-637. April 2003.
The final step is to construct the hyper cube as is summarised in Table 9 below. The ‘low’ value is equal to the hit in the tree search. The ‘high’ value is equal to the next entry in the tree minus one. If no ‘next’ entry exist it is equal to the maximum value of that dimension.
This cube covers:
Thus, in total, a possible of 18320645203993559040 micro flows.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06076262.2 | Jun 2006 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP07/54820 | 5/18/2007 | WO | 00 | 2/19/2010 |
