Method and system for IP fragmentation handling

In a network, packets are fragmented into head and non-head fragments. Non-head fragments are saved up front at an entry point, while a network switch forwards only the head fragment to Layer 4-Layer 7 (L4-L7) features for processing. The switch records changes that are performed on the head fragment's fields by the L4-L7 features while they process the head fragment. At an exit point, fields of the saved non-head fragments are overwritten with information that was recorded for the head fragment. This can include updating or modifying the source and destination parameters of the non-head fragments in an intelligent manner by reusing the results of the packet processing that was performed on the head fragment. This fragmentation handling technique avoids having to redundantly process the non-head fragments in the same manner as the head fragments.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This disclosure relates generally to communication of packets within a network. More particularly but not exclusively, the present disclosure relates to techniques for handling fragmented packets, such as the handling of Internet protocol (IP) fragmentation packets within a communication network.

2. Description of the Related Art

The most basic unit of data transmission in Transmission Control Protocol/Internet Protocol (TCP/IP) or Internet networking is a packet (sometimes referred to as a “datagram”). A packet is a small piece of information coded at a source, marked with the source address (SA), and directed to a destination address (DA). Traditional IP networks and systems rely exclusively on IP addressing to route the packet from one IP network to another, until arriving at the destination address specified in the packet. Routers, switches (such as Ethernet switches), hubs, or other network devices operate to forward packets to their ultimate destination.

IP fragmentation of a packet is generally performed when the packet originates from a network that allows a large packet size, and then the packet must traverse to another network that limits packets to a smaller size in order to reach their destination. Routers typically perform the fragmentation of large packets, while reassembly of fragments back into the original packet is performed at the destination (or sometimes at an intermediate location).

Fragmentation involves the breaking up of a packet into an almost arbitrary number of fragments that can be later reassembled. The SA, DA, identification, total length, fragment offset fields, and other information in an IP packet header are used for fragmentation and reassembly. The receiving destination uses an IP identifier in the identification field to identify and match fragments that belong to the same packet, while the fragment offset fields are used to identify the position of each fragment in the original packet. This header information, along with other header information, provides sufficient information to reassemble packets. See generally Information Services Institute, Internet Protocol: DARPA Internet Program Protocol Specification, September 1981.

When dealing with IP-fragmented packets, the only fragment that has sufficient information that can be utilized by Layer 4-Layer 7 (L4-L7) features (at the receiving station or at intermediate locations, such as at a switch) is the head fragment that has all of the header information. The trailing fragments, including fragments that collectively contain the pieces of the original packet data, are generally useless for purposes of L4-L7 operations. Therefore, processing all of these packets with the L4-L7 features amounts to wasting precious processor cycles. Furthermore, in fragmentation schemes where the header information is duplicated into all of the individual fragments (as compared to fragmentation schemes where only one fragment generally has most of the original header information), processing all of the individual fragments with the L4-L7 features also amounts to a redundant and an unnecessary waste of processor cycles.

As an illustration of this redundancy, suppose an IP packet “P” is fragmented into n+1 fragments f0, f1, f, . . . fn. The only fragment that will have any utility for the L4-L7 features is the head fragment f0. In the worst case scenario, the head fragment f0 is received last by a switch (or by some other network component in the communication path)—however, by the time the head fragment f0 is received, the switch would already have forwarded the previous n fragments to the L4-L7 features by then, and the L4-L7 features (whether at the switch, at the receiving station, or at an intermediate location) would already have processed these n fragments before receiving the head fragment f0. The L4-L7 features, only after processing these n fragments, would then realize that these are fragments of an original packet and that there is not sufficient useful information that can be obtained therefrom, and further would have to save these n fragments until the head fragment f0 is finally received and processed. However, as one can note, the L4-L7 features performed substantially unnecessary processing on the n non-head fragments prior to receipt of the head fragment f0.

BRIEF SUMMARY OF THE INVENTION

One aspect of the present invention provides a method that includes receiving packet fragments at an entry point. The method determines if a packet fragment received at the entry point is a head fragment or a non-head fragment. If the received packet fragment is a non-head fragment, the method determines if a helper session associated with a head fragment corresponding to the non-head fragment is present, updates the non-head fragment with routing information from the helper session, and forwards the non-head fragment based on the routing information from an exit point. Otherwise, the method stores the non-head fragment if the helper session is not present, and waits for the corresponding head fragment to be received at the entry point.

If the received packet fragment is the head fragment, the method processes the head fragment. At the exit point, the method updates any stored corresponding non-head fragment with routing information obtained as a result of processing the head fragment and forwards the updated non-head fragment from the exit point.

DETAILED DESCRIPTION

Embodiments of techniques to handle fragmentation of packets, such as

As an overview, one embodiment of the invention reduces the wastage of processor cycles by saving non-head fragments and forwarding only the necessary packets (e.g., head fragments) to L4-L7 features. In an embodiment, non-head fragments are saved right in the beginning, when a network device (such as a switch) receives the fragments at an entry point. The switch waits for a head fragment to arrive, and once it is received, the switch then forwards the head fragment to the appropriate L4-L7 feature(s). The switch records changes that are performed on the head fragment's fields by the L4-L7 features while they process the head fragment. At an exit point, fields of the saved non-head fragments are overwritten with information that was recorded for the head fragment. That is, an embodiment of the invention modifies the source and destination parameters of the non-head fragments in an intelligent manner by reusing the results of the packet processing that was performed on the head fragment. Hence, all of the fragments can be forwarded to the correct destination for subsequent reassembly—complex computation associated with reassembly is left to the endpoint destination, thereby further saving processor cycles at the switch.

Such a technique may be viewed as a form of “global fragmentation handling.” That is, rather than having the L4-L7 features process each and every fragment (both head and non-head fragments) in substantially a similar way, an embodiment processes only the head fragment and the results of that processing are applied to all the non-head fragments, without having to independently process each of the non-head fragments. Furthermore, an embodiment of the invention provides a technique where the processing performed by the L4-L7 features is substantially fragmentation independent. That is, the L4-L7 features need not and do not make any processing decisions that are dependent on the nature of the IP fragments (e.g., the L4-L7 features do not need to determine whether the fragment is a head or non-head fragment, the relative location of the fragment in the original packet, the number of fragments that are needed to form the complete packet, and so forth). By forwarding the head fragment to the L4-L7 features and saving (and not forwarding the non-head fragments), the L4-L7 features can simply process the head fragment without having to account for fragmentation issues.

While embodiments are described herein in the context of IP packets and the ISO layer model, it is to be appreciated that the invention is not specifically limited to IP packets and this model. Embodiments of the invention may be implemented in other types of systems where data is fragmented, and need to be processed and reassembled in an efficient manner.

FIG. 1is a block diagram that illustrates a technique to handle fragmented packets. Packets (or more particularly, fragments of packets) are received at one or more packet entry points100. Both head and non-head fragments traverse through the entry point(s)100. A network device, such as a switch102, receives the fragments. The switch102operates as an “edge device” that processes IP traffic on behalf of an endpoint of a TCP/IP communication path (where traffic to the endpoint is indicated generally inFIG. 1by an arrow from a packet exit point108to a destination or a receiver end).

The processing performed by the switch102can include processing associated with Layer 2 (L2), Layer 3 (L3), or L4-L7. For instance, L4 processing can include port-based mapping using source and destination address information, while L5-L7 processing can include session-based, geography-based, username-based, etc. processing, which for the sake of brevity are not described in detail herein because such details would be familiar to those skilled in the art having the benefit of this disclosure.

A firewall104may be present to filter or manipulate packets (or fragments) based on L4-L7 information. One or more other network devices, such as a transparent cache switching (TCS) device106, may also be present to direct, store, or otherwise process packets (or fragments) based on L4-L7 information. Another example of a network device (alternatively or in addition to the TCS device106) is a context switch engine.

The firewall104and TCS device106are shown inFIG. 1merely as examples of L4-L7 components or features. Other types of L4-L7 features may be implemented in the TCP/IP communication path. Moreover, the switch102itself may have its own L4-L7 features integrated therein to perform processing associated with L4-L7. An example of the switch102(having L4-L7) features is the ServerIron® product available from Foundry Networks, Inc. of San Jose, Calif.

In the fragmentation-handling technique ofFIG. 1, whenever a fragment arrives at the entry point100, the fragment is treated just like a normal packet by the switch102and is forwarded to the appropriate L4-L7 feature(s) (such as the firewall104, TCS device106, and/or L4-L7 features integrated in the switch102) based on a Media Access Control (MAC) address lookup. The received fragment is either a head or non-head fragment. The L4-L7 feature(s) create(s) a special helper session when the switch102receives the head fragment. The index for this helper session is the IP Identifier, which is common to all of the fragments that constitute the original IP packet.

Any other fragment with the same IP identifier that is received via the entry point100after the creation of this helper session is processed immediately—and thus, these non-head fragments undergo a redundant L4-L7 processing that was previously performed on the head fragment. If the switch102has not yet received the head fragment, then the helper session is not yet available, and all the currently received non-head fragments are stored in an array until the head fragment is received. On the arrival of the head fragment, the helper session is created by the L4-L7 feature(s), which then perform L4-L7 processing on all of the fragments currently stored in the array. In case the head fragment is not received for some reason, the stored fragments are aged out after a period of time.

FIG. 2is a block diagram that illustrates a technique to handle fragmented packets according to an embodiment of the invention, and is to be contrasted and compared with the technique ofFIG. 1. More particularly,FIG. 2illustrates that the head fragment is forwarded to and processed by the L4-L7 features and the non-head fragments are saved in the meantime (and not redundantly processed by the L4-L7 features in the same manner as the head fragment), whileFIG. 1illustrates that all packets (whether head or non-head packets) are processed by the L4-L7 features.

In an embodiment, an entry point200and an exit point202are chosen to ensure that all packets (or fragments thereof) traverse through those two points. At the entry point200, a fragment is checked to determine if it is a non-head fragment. For non-head fragments, software or other machine-readable instructions at a switch204determines if there is any helper session (or other session provides routing information) that is already present and that matches (or can otherwise be associated to) the non-head fragment. Such software can be stored on a machine-readable storage medium206or other suitable storage location accessible by the switch204, which itself can be implemented using the ServerIron® product of Foundry Networks, Inc. in an embodiment.

If there is an existing helper session that matches the non-head fragment, then a routing tag or other suitable routing information is attached to the non-head fragment to ensure that the non-head fragment is forwarded to the same destination as its corresponding head fragment. Address fields in the non-head fragment may also be updated with a port or other destination address if needed. IP and TCP/UDP check sums are also modified accordingly. Information for the routing tag can include a destination port, MAC, and/or IP address, which can be obtained from a session pointer data structure in the helper session in one embodiment. The non-head fragment itself therefore does not undergo L4-L7 processing and is instead directly forwarded by the switch206to the exit point202, as symbolically represented inFIG. 2by a broken line.

In an embodiment, a “helper session” from above is a session that is created to store the forwarding information for the packet or fragment thereof. One helper session can be created per head fragmented packet. The index into this session is the tuple (src_ip, dst_ip, ip_identifier, ip_idenffier, ip_protocol), for example. The non-head fragments will have the same tuple in their header and can thus refer to the forwarding information that is stored in the helper session. These helper sessions are short-lived, so as to avoid running out of session entries in case of a large number of fragmented packets. Most of the fragments arrive within a short interval, and therefore, a helper session can be freed within 8 seconds in an example implementation.

The session pointer data structure (session_ptr) is an example implementation detail to refer to the session above. An illustration of the routing tag (or other routing information) is a forwarding index that maps to the outgoing port or ports. In one embodiment, the fragments are sent out based on a bit array, where each bit maps to individual ports. Depending on which bits are “on,” the packets are sent out on those ports.

If there is no matching helper session at the entry point200, the non-head fragment is saved or otherwise stored (such as in the storage medium206), until the switch204receives its corresponding head fragment. When the head fragment arrives, the switch204forwards the head fragment to its respective L4-L7 features for packet processing just like any regular packet would otherwise be processed. Such L4-L7 feature(s) may be found in a firewall208, in a TCS device210, or in some other network device or combination thereof, including L4-L7 features integrated in the switch204itself. This L4-L7 processing can include assigning destination port addresses, identifying the session to which the head fragment belongs, translation of addresses, or other L4-L7 processing that would be familiar to those skilled in the art having the benefit of this disclosure and which are not described in further detail herein for the sake of brevity.

At the common exit point202, an embodiment provides software to check if the fragment is a head fragment of a fragmented IP packet. Such software may be stored at a machine-readable medium212. The machine-readable medium212can be located at the receiver end (such as at a client terminal); at the switch204, or at any location in between, including being the same storage medium as the storage medium206. The exit point202may also be similarly defined at the receiver end, at the switch204, or at any location in between where fragments are routed subsequent to the L4-L7 processing.

In operation, after the L4-L7 processing is completed by the L4-L7 features, this software at the exit point202searches for the session pointer data structure that corresponds to the head fragment and which has now been created by the L4-L7 features during their packet processing, and creates the helper session. The forwarding information from this helper session is stored in the storage medium212in an embodiment, and includes information such as destination addresses, IP identifiers to match the head fragment with its non-head fragments, session identifiers, and other information. Using this stored information, the software processes any non-head fragments stored in the queue at the storage medium206and which are associated with this head fragment. Such processing can include overwriting fields in the non-head fragments with forwarding information (such as destination port addresses) that were obtained when their corresponding head fragment was processed by the L4-L7 features. These updated non-head packets are then forwarded to the receiving end for reassembly.

Therefore and as can be contrasted between the techniques ofFIGS. 1-2, the technique ofFIG. 1performs L4-L7 processing on all of the fragments even after fragmentation-specific processing is performed, as opposed to the technique ofFIG. 2where fragmentation handling is performed after the L4-L7 feature is done with its packet processing on only the head fragment. This saves much redundant processing, since the results of the L4-L7 processing of a head fragment ofFIG. 2can be reused to minimally process non-head fragments.

FIG. 3is a flowchart300of fragmented packet handling at the entry point200according to an embodiment of the invention. Components of the flowchart300may be implemented in software or other machine-readable instruction stored on machine-readable medium (such as the storage medium206). It is appreciated that the various operations depicted in the flowchart300need not necessarily occur in the exact order shown, and that certain operations may be combined, added, removed, or modified as appropriate.

At a block302, packets and/or fragments thereof are received at the entry point202. The entry point202may be defined in a software function of the switch204, for instance, in a manner that all packets and/or fragments thereof traverse through the entry point202. The software at the block302determines whether the packet is fragmented—in most cases, it is a fragment that is received at the entry point200, unless some prior reassembly has already been performed prior to reaching the entry point200. If the packet is not fragmented, then the packet is forwarded to the L4-L7 features by the switch204(if appropriate) at a block304and is processed by these features at a block306.

If the packet is determined to be fragmented at the block302, however, then a block308determines whether the received fragment is the head fragment. If the received fragment is the head fragment, then the head fragment is forwarded to the L4-L7 features at the block304and processed by these features at the block306.

If the fragment is a non-head fragment as determined at the block308, then the software attempts to locate any present corresponding helper session at a block310. If such a helper session is present, then forwarding information is obtained from the session pointer data structure at a block312. This forwarding information can include information for a routing tag, destination port address, or other information to associate the non-head fragment to its proper destination.

At a block314, the non-head fragment is updated with the forwarding information. For example, the non-head fragment can be updated with a routing tag, destination port address can be overwritten into address fields, or other routing information or parameters can be updated. The updated non-head fragment is forwarded to its next destination at a block316, which can be the final destination or an intermediate location.

If the helper session is not present at the block310, then the non-head fragment is stored in the storage medium206at a block318. The switch204waits for the head fragment at a block320, and the process repeats at the block302.

FIG. 4is a flowchart400of fragmented packet handling at the exit point202according to an embodiment of the invention. As with the flowchart300ofFIG. 3, components of the flowchart400may be implemented in software or other machine-readable instruction stored on machine-readable medium (such as the storage medium212). It is also appreciated that the various operations depicted in the flowchart400need not necessarily occur in the exact order shown, and that certain operations may be combined, added, or modified as appropriate. It is further appreciated that components of the flowchart400may be combined with or added to the components of the flowchart300.

At a block402, the software determines whether a received fragment (or packet) is a head fragment. For example, if a non-head fragment or an un-fragmented packet is received at the block402, then these are forwarded to their next destination at a block404, which in one embodiment is the block310ofFIG. 3. With regards to a non-head fragment, such a fragment may originate from the block316ofFIG. 3, after this non-head fragment has been matched to a current session and has been updated accordingly as described above. With regards to an un-fragmented packet, such a packet may have been previously processed by the L4-L7 features at the block306ofFIG. 3and can now be forwarded at the block404to its next destination.

If a head fragment is received at the block402, then this head fragment has been already processed at the block306ofFIG. 3by the L4-L7 features. The head fragment's corresponding non-head fragments are either or both stored at the storage medium206or waiting to be received at the entry point200. In one embodiment at a block406, the software locates the session pointer data structure associated with that head fragment. The session pointer data structure would have been created by this time by the L4-L7 features at the block306, while packet processing the head fragment (as symbolically depicted inFIG. 4by an arrow from the block306that inputs into the block406).

At a block408, the helper session associated with the head fragment is created. In one embodiment, information from the session pointer data structure can be used to populate the helper session, including source and destination IP addresses, source and destination port addresses, IP identifiers to match fragments that belong together, session information to match fragments to the same session, network address translation (NAT) results, and so forth.

At a block410, any corresponding non-head fragments that are stored in the storage medium206are updated using the session pointer data structure information as obtained from the helper session. In one embodiment and as described above, this update can include overwriting fields of the non-head fragments with destination addresses, adding routing tags, or providing other routing information. At a block412, the non-head and head fragments are forwarded to their next destination, where they can be reassembled.

The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention and can be made without deviating from the spirit and scope of the invention.

For example, embodiments have been described herein in terms of head and non-head fragments, in that some fragments may contain substantially more packet header information than other fragments. It is appreciated that one embodiment of the invention can be applied to fragmentation schemes where the same header information is duplicated into all fragments. In such an implementation, L4-L7 processing can still be performed on only one of the fragments (which is treated as the “head fragment”), while the other fragments are treated as “non-head fragments” even though they may contain substantially the same header information as the “head fragment.”