Flexible flow-aging mechanism
Granted 19 Oct 2010 · 3 office actions
Current assignee: RPX Corporation · originally Extreme Networks, Inc.
Law firm: Law firm · Log in to unlock
Attorney: Attorney · Log in to unlock
Inventors: Jeffrey Fowler, Rahul Kasralikar · Examiner: Steven H Nguyen · AU 2473 · TC 2400
Life of the application
21 dated eventsAbstract
A flow identifier is stored in a memory to identify a network flow. The memory is capable of storing multiple flow identifiers for multiple flows. Packet statistics are collected for each of the flows. The packet statistics are compared and a flow identifier is subsequently selected and removed from the memory.
Description
7 parts›FIELD
Embodiments of the invention relate to the handling of packet flows through a network switch, and particularly to flow-aging in a switch.
›BACKGROUND
A network flow, also referred to herein as simply a “flow,” is a sequence of network packets sharing certain characteristics. A common set of characteristics used to define a flow is referred to as a “5-tuple.” A 5-tuple is a sequence of packets sharing the same source and destination address, source and destination port, and protocol (5 values total, hence the “5-tuple” label.) Other combinations of flow characteristics may also be used to define a network flow.
Many network switches employ filters or other devices/mechanisms to control the flow of network traffic through the switch. One approach to filtering and/or control is a flow-based approach. In one example of a flow-based approach, a list/table of various flow entries (e.g., as defined by the 5-tuple) is maintained at the switch. When a packet enters the switch, the packet is checked to see if it matches a flow entry in the list/table. Based on the results of checking the packet, an action is then taken on the packet (e.g., blocking, forwarding, redirecting, etc.).
The list/table of flow entries is typically stored in a finite memory/cache. Thus, only a limited number of flow entries can be stored at a time. When the memory becomes full of entries, a decision must be made to determine how to handle new entries seeking inclusion in the list/table (i.e., whether to add or remove an entry from the list/table). This decision-making process and the subsequent actions associated with removing flow entries to make room for new entries is referred to herein as aging, or flow-aging.
Existing flow-aging mechanisms rely on packet counters or hardware refresh bits to decide whether a flow is to be aged out or not. These mechanisms are limited in that the aging process is typically based on simple packet-difference arithmetic, providing very little flexibility for aging out flows.
›SUMMARY
A flow identifier for a network flow is received from an intrusion prevention system (IPS) device and a request is made for the flow identifier to be stored in a memory. The memory is capable of storing multiple flow identifiers for multiple flows and provides a basis for forwarding packets directly through a switch. Packet statistics (beyond basic packet counts from a single counter) are collected for each of the flows. Rather than relying on simple packet counts or status bits for a single flow, the packet statistics for the different flows are analyzed and corresponding flows are prioritized. Based on the prioritization and a policy, a determination is made whether to remove a flow identifier from memory to allow the received flow identifier to be added.
›BRIEF DESCRIPTION OF THE DRAWINGS
The following description includes discussion of various figures having illustrations given by way of example of implementations of embodiments of the invention. The drawings should be understood by way of example, and not by way of limitation.
FIG. 1 is a block diagram of an embodiment of the invention having a flow-aging manager.
FIG. 2 is a flow diagram of an embodiment of the invention.
›DETAILED DESCRIPTION · 1 of 3
A network switch operates in conjunction with an external intrusion prevention system (IPS) to provide network security (e.g., threat detection and/or mitigation). The switch redirects traffic to the IPS for further inspection, sometimes referred to as “deep packet inspection.” Most external IPS devices do not have the bandwidth capabilities to inspect traffic in real-time without significantly throttling or bottlenecking the traffic. Thus, switches typically redirect only a portion of the overall traffic to an IPS device (based on a policy, a set of rules or parameters, etc.)
The IPS device analyzes the redirected traffic to determine whether a particular flow is good (e.g., safe, not a threat, etc.) or bad (e.g., viruses, worms, denial of service (DoS) attacks, etc.). These determinations are communicated back to the switch to provide a basis for future redirection decisions. For example, an IPS device might determine that a particular flow (e.g., flow B) is a good flow. The IPS sends a notification to the switch identifying flow B as a good flow. The switch stores a flow identifier (e.g., a 5-tuple) for flow B in a memory. Thus, once a flow identifier for flow B is stored in the memory, any subsequently received packets associated with flow B will generate a match with the flow B identifier in memory, causing the switch to forward the flow B packets through the switch without redirecting them to the IPS device (because it has already been determined that flow B packets are safe for the network).
The memory used for storing flow identifiers can be any memory (e.g., random access memory (RAM), read-only memory (ROM), flash memory, etc.). In one embodiment the memory used to store the flow identifiers is a content addressable memory (CAM). In another embodiment, a ternary CAM, or TCAM, is used to store the flow identifiers. Given that a memory has a finite number of storage locations, the addition of new flow identifiers eventually causes the memory to become full. When the memory is full, new flow identifiers cannot be automatically added to the memory. Instead, a decision must be made at the switch either to remove a flow identifier from the memory (to make room for a new flow identifier) or to deny the new flow identifier from being added to the memory. A flow-aging mechanism handles the decision-making process for adding and/or removing flow identifiers from the memory.
In one embodiment, flow-aging decisions are based both on dynamically updated packet statistics collected at the switch and a flow-aging policy or set of rules. Packet statistics may include cumulative packet counts for different flows, a change or delta in a packet count over a time interval, a ratio of two cumulative packet counts, a ratio of a change or delta in two packet counts over a time interval, etc. The variety of packet statistics provides flexibility to the decision-making process for adding and/or removing flow identifiers from the memory. In another embodiment, the flow-aging mechanism compares existing flows or other information such as forwarding entries from a media access control (MAC) table, a routing table, access control lists (ACLs) or other rules installed by other applications to aid in the decision-making process for adding/removing flow identifiers from the memory.
FIG. 1 illustrates an embodiment of the invention having a flow-aging manager 120 . Traffic 101 enters switch 110 where it is received by flow handler 112 . Flow handler 112 initially examines traffic 101 to find packets having a recognized flow identifier. A table/list of flow identifiers is stored in memory 114 . Memory 114 can be any memory/cache, including ROM, RAM, flash memory, CAM, etc. In one embodiment, the table/list of flow identifiers identifies flows that have been designated as “good” flows (discussed in more detail below). In other embodiments, the table/list identifies flows that meet other specified criteria.
When a packet enters flow handler 112 , the packet is examined to determine its flow identifier (e.g., the 5-tuple that includes source and destination address, source and destination port, and IP protocol). Flow handler 112 then compares this flow identifier against entries stored in memory 114 . If flow handler 112 finds a matching entry in memory 114 , the packet is associated with a good flow and is forwarded through switch 110 without being redirected. If, on the other hand, flow handler 112 does not find a matching entry in memory 114 , the packet is redirected to traffic selector 116 .
Traffic selector 116 monitors various conditions in traffic 101 and includes various rules/policies for the selection and redirection of flows to the external IPS device 130 . IPS 130 performs deep packet inspection to determine whether a packet/flow is safe or whether it is a threat to the stability/integrity/functionality of the network and/or its instrumentalities. If IPS 130 determines that a particular flow is safe for the network, it is considered a “good” flow. IPS 130 notifies flow-aging manager 120 of the good flow and flow-aging manager 120 forwards a flow identifier associated with the good flow to flow-handler 112 . Flow-handler 112 attempts to store the flow identifier in memory 114 . Assuming space is available for a new entry, the flow identifier is stored in memory 114 . Once the flow identifier for the good flow is stored in memory 114 , future incoming packets associated with the good flow are forwarded directly through the switch 110 .
If memory 114 is full, new flow identifiers cannot be added as entries unless an existing entry is deleted/removed from memory 114 , referred to herein as “aging out” a flow. Flow-aging manager 120 manages the flow-aging process and creates a flexible flow-aging environment where policies and/or rules affecting decisions and/or selections can be adapted to changing network conditions and/or a changing network environment. Thus, flow-aging manager 120 contributes to increasing efficiency in the forwarding of packets/traffic in a switch.
›DETAILED DESCRIPTION · 2 of 3
In particular, packet statistics unit 122 collects/maintains packet statistics for incoming traffic 101 . The packet statistics can include, but are not limited to, cumulative packet counts for one or more flows, a change or delta in a packet count over a time interval, a ratio of two cumulative packet counts, and/or a ratio of a change or delta in two different packet counts over a time interval.
Packet statistics unit 122 may also collect statistics for reverse/outbound traffic associated with a flow. For example, in one embodiment, packet statistics unit 122 tracks the number of incoming Transmission Control Protocol (TCP) synchronize (SYN) packets received for a particular flow. Meanwhile, packet statistics unit 122 can also track the number of outbound TCP SYN-acknowledge (SYN-ACK) packets associated with the flow.
A packet statistics analyzer 124 analyzes the collected packet statistics based on a policy or set of rules. The policy or set of rules can be manually updated by a network administrator or it can be dynamically updated based on network conditions. Packet statistics analyzer 124 prioritizes flows using the packet statistics and the policy (or set of rules). For example, in one embodiment, packet statistics analyzer 124 uses “packet count over time” statistics and gives higher priority to a high volume flow than to a low volume flow. Or, in another embodiment, priority may be given to a particular type of flow (e.g., mail traffic, file transfer protocol (FTP) traffic, structured query language (SQL) traffic, etc.).
Flow selector 126 selects flows to be aged out based on the packet statistics analysis and the flow-aging policy. When a flow identifier is presented for addition into memory 114 , flow selector 126 selects an entry, if any, to be removed from memory 114 so that the new flow identifier can be added. Based on the policy, flow selector 126 may determine not to remove any entries from the table, thus denying the addition of the new flow identifier to the table.
When the flow selector 126 selects an entry for removal from memory 114 , the selection is communicated to flow handler 112 and the selected flow identifier is removed from memory 114 . Once a flow identifier is removed from memory 114 , future incoming packets associated with the removed flow identifier will be redirected to traffic selector 116 , and possibly IPS 130 , instead of being forwarded directly through switch 110 . If packets associated with the removed flow identifier are redirected and later inspected by IPS 130 and the corresponding flow is again tagged as a good flow, the removed flow identifier will be forwarded to flow-aging manager 120 and evaluated for re-entry into memory 114 . Depending on the network conditions and/or associated flow-aging policies/rules, the previously removed flow identifier may or may not be re-admitted into memory 114 .
FIG. 2 illustrates another embodiment of the invention. A network switch (or other network device) receives a flow identifier from an external IPS device 210 and a storage request is made for the flow identifier. Flow identifiers may be stored in a cache, a memory, or other storage medium. When a flow identifier is stored in memory, it distinguishes the associated flow from other traffic flowing through a switch or network device. For example, in one embodiment, flow identifiers are stored to distinguish known good flows from unknown flows or from known network threats. In other embodiments, flow identifiers may be stored to differentiate between flows based on certain characteristics such as, for example, source and/or destination of the traffic, traffic types, traffic classes, etc. Thus, in one embodiment of the invention, if a flow identifier is stored in memory for a particular flow, packets associated with the flow are identified and forwarded directly through the switch without being redirected for further inspection.
The memory used for storing flow identifiers is of finite capacity. Thus, if a new flow identifier is received by the switch and the memory is full, a decision is made to determine whether to remove a flow identifier from the memory (and subsequently add the new flow identifier) or to reject the new flow identifier.
To facilitate the decision-making process, the switch, or other network device, collects packet statistics 220 for traffic flowing through the switch or other network node. These statistics can include cumulative packet counts for one or more flows, a change or delta in a packet count over a time interval, a ratio of two cumulative packet counts, and/or a ratio of a change or delta in two different packet counts over a time interval. In one embodiment, packet statistics are collected only for those flows having an associated flow identifier stored in memory. In other embodiments, packet statistics can be collected for a selected/desired group or subset of flows.
The collected packet statistics are analyzed based on a policy or set of rules. The policy or set of rules can be manually updated by a network administrator or it can be dynamically updated based on network conditions. Flows are then prioritized, 230 , using the packet statistics and the policy (or set of rules). For example, in one embodiment, priority is determined using “packet count over time” statistics (i.e., higher priority is given to a high volume flow than to a low volume flow). In another embodiment, priority is determined based on the particular type of flow (e.g., mail traffic, FTP traffic, SQL traffic, etc.). Other priority schemes may also be used.
Once the flows have been prioritized, the system determines whether to remove a flow identifier from memory 240 . The stored flow identifier having the lowest priority is selected and is compared against the flow identifier received from the IPS device. The flow-aging policy determines whether to keep the selected flow identifier (and deny entry to the received flow identifier) or to remove the selected flow identifier and add the received flow identifier to the memory. For example, the flow-aging policy may give priority to higher volume flows. Thus, if the flow associated with the selected flow identifier has a higher volume than the flow for the received flow identifier, the system will determine to keep the selected flow identifier and deny entry to the received flow identifier. On the other hand, if the flow associated with the selected flow identifier has a lower volume than the flow for the received flow identifier, the system will determine to remove the selected flow identifier and subsequently add the received flow identifier to the memory.
›DETAILED DESCRIPTION · 3 of 3
Embodiments of the invention described above may include hardware, software, and/or a combination of these. In a case where an embodiment includes software, the software data, instructions, and/or configuration may be provided via an article of manufacture by a machine/electronic device/hardware. An article of manufacture may include a machine accessible/readable medium having content to provide instructions, data, etc. The content may result in an electronic device, for example, a filer, a disk, or a disk controller as described herein, performing various operations or executions described. A machine accessible medium includes any mechanism that provides (i.e., stores and/or transmits) information/content in a form accessible by a machine (e.g., computing device, electronic device, electronic system/subsystem, etc.). For example, a machine accessible medium includes recordable/non-recordable media (e.g., read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc. The machine accessible medium may further include an electronic device having code loaded on a storage that may be executed when the electronic device is in operation. Thus, delivering an electronic device with such code may be understood as providing the article of manufacture with such content described above.
As used herein, references to one or more “embodiments” are to be understood as describing a particular feature, structure, or characteristic included in at least one implementation of the invention. Thus, phrases such as “in one embodiment” or “in an alternate embodiment” appearing herein describe various embodiments and implementations of the invention, and do not necessarily all refer to the same embodiment. However, they are also not necessarily mutually exclusive. The above descriptions of certain details and implementations, including the description of the figures, may depict some or all of the embodiments described above, as well as discussing other potential embodiments or implementations of the inventive concepts presented herein.
Besides what is described herein, various modifications may be made to the disclosed embodiments and implementations of the invention without departing from their scope. Therefore, the illustrations and examples herein should be construed in an illustrative, and not a restrictive sense. The scope of the invention should be measured solely by reference to the claims that follow.
Claims as granted
20 claimsLog in to read the claims of this application.
Log in to unlockClassifications
3 codes- H04L12/26
Claim changes
SoonSee which claims were amended, added or cancelled during examination, with every added and removed word marked.
The published claims of this application are not paired with the granted ones in what we hold.
File wrapper
See the full prosecution history — every USPTO and applicant action on this file, in order.
Log in to unlockDocuments
Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.
Log in to unlockChain of title
See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.
Log in to unlock