BACKGROUND OF THE INVENTION Packet-based communication networks (such as the Internet) transfer information between computers and other equipment using a data transmission format known as packetized data. The stream of data from a data source (e. g., a host computer) is divided into variable or fixed length"chunks"of data (i. e., packets). Switches (e. g., routers) in the network route the packets from the data source to the appropriate data destination. In many cases, the packets may be relayed through several routers before they reach their destination. Once the packets reach their destination, they are reassembled to regenerate the stream of data.

The routers receive and transmit streams of data over multiplexed lines.

That is, each line transmits packets from several sources by sending the packets for each source over the line at different periods of time.

Conventionally, the flow of packets from a given data source to a given data destination may be referred to as a data flow. Thus, a multiplexed line typically supports many data flows.

Conventional packet-based networks use a variety of protocols to control data transfer throughout a network. For example, the Internet Protocol ("IP") defines procedures for routing data through a network. To this end, IP specifies that the data is organized into frames, each of which includes an IP header and associated data. The routers in the network use the information in the IP header to forward the packet through the network. In the IP vernacular, each router-to-router (or switch-to-router, etc.) link is referred to as a hop.

As the demand for data services grows, so too does the need for more bandwidth on data networks. One solution to this problem is to add more capacity. That is, add more lines and routers. This, however, is a relatively

expensive proposition. Another solution is to increase the throughput on existing lines. One method of accomplishing increased throughput involves compressing the data being routed over the line.

Data compression algorithms convert data defined in a given format to another format so that the resulting format contains fewer data bits (i. e., the ones and zeros that define digital data) than the original format. Hence, the data is compressed into a smaller representation. When the original data is needed, the compressed data is decompressed using an algorithm that is complementary to the compression algorithm.

Many compression schemes use what are known as history files.

Typically, a history file contains a series of mappings between the original data and the compressed representations of the actual data. In compression schemes that use history files, the compressor and decompressor use identical history files. In this case, the history files may be supplied to each component or dynamically created by each component using known algorithms.

Some data compression schemes have been proposed for data networks. In one scheme, all packets routed over a given path in the network are compressed as they enter the path and decompressed as they exit the path.

For example, a compressor may be installed at one end of the path. The compressor compresses all of the packets being routed over that path. A decompressor at the other end of the path decompresses all of the packets it receives from the path. The decompressor then routes the packets to their destination. Conventionally, a single history file may be used for all of the data at each end of the path.

In another scheme, each packet routed over a given path in the network is individually compressed. In this case, a new history file may be used for each packet.

Data compression schemes such as the ones described above may, at times, be relatively inefficient in compressing data routed over a path.

Consequently, a need exists for an improved data compression scheme for multi-flow data.

SUMMARY OF THE INVENTION In one embodiment of the invention, data routed over a multiplexed path is compressed before it is sent over the path and is decompressed on the other end of the path. To increase the degree of the data compression, the system may separately compress data flows or groups of data flows that are routed over the path.

When data enters the path, the system analyses the data to be sent over the path to identify the data flows associated with that data. Then, a data compressor uses a history file associated with each flow or group of flows to compress the data. In addition, the system associates an indicator with the data. The indicator uniquely identifies the flow or flow group. The system then sends the compressed data and the (non-encoded) associated indicator together over the path.

At the other end of the path, the system reads the indicator accompanying the compressed data to identify the flow or flow group associated with that data. A data decompressor uses a history file associated with the flow or flow group to decompress the compressed data.

In one embodiment, the invention is implemented in a pair of devices installed on each end of an IP hop. For example, the devices may be installed between a pair of routers in the network. The device on the sending end of the hop intercepts each packet that the router sends over the hop. The device identifies the session associated with the packet (in the case of a TCP packet) and uses a history file associated with that session (or a group of sessions that includes that session) to compress the packet. In one embodiment, the device generates the history file at the start of each session (or at the start of the first in a group of sessions) and uses the same history file for all of the packets in that session (or session group). The compressed packet and an associated identifier are then sent over the hop.

The device on the other end of the hop intercepts each inbound packet from the hop. The device identifies the session (or session group) associated with the packet (in the case of a TCP packet) by reading the identifier and uses a history file associated with that session (or session group) to decompress the

packet. As in the data compressor, a separate history file may be used for each session (or session group).

In another embodiment, the method of the invention is implemented by installing appropriate software modules in the equipment (e. g., routers) on the ends of the path. The equipment is configured so that packets are processed as above and stored in the internal memory of the equipment, as necessary.

In many cases, a system or method implementing the teachings of the invention may provide more efficient compression than conventional systems or methods that compress different types of data using a common history file. For example, when different flows contain different types of data (e. g., one flow contains e-mail messages in Japanese while another contains HTML data), the system or method of the invention may use separate history files for each type of flow. This increases the probability that each of the history files will contain data that it specifically adapted to the corresponding flows. To continue the above example, the history file for Japanese e-mail messages may contain some frequently used Japanese words, or dates and headers similar to"From" and"To"which are likely to be found in e-mail messages. In contrast, HTML data may contain typical HTML strings such as"<html>"or"<center>".

Significantly, it may be seen that it is unlikely that a history file will contain data related to the other flows. For example, the e-mail history file probably will not include the"<html>"string. The presence of the specifically adapted data and the absence of the unrelated data in each history file may, in many circumstances, significantly improve the effectiveness of the compression.

Thus, by compressing data separately for each flow, a system or method implemented according to the invention may provide a higher degree of compression in comparison to conventional compression systems or methods.

BRIEF DESCRIPTION OF THE DRAWINGS These and other features of the invention will become apparent from the following description and claims, when taken with the accompanying drawings, wherein similar references characters refer to similar elements throughout and in which: FIGURE 1 is a block diagram of one embodiment of a data network incorporating a compression system in accordance with the invention; FIGURE 2 is a block diagram of a flow compressor constructed according to the invention; FIGURE 3 is a block diagram of a flow decompressor constructed according to the invention; FIGURE 4 is a flowchart of operations that may be performed by a compression system implemented according to the invention; FIGURE 5 is a flowchart of operations that may be performed by a decompression system impiemented according to the invention; and FIGURE 6 is a block diagram of another embodiment of a data network incorporating compression and decompression in accordance with the invention.

DESCRIPTION OF EXEMPLARY EMBODIMENTS FIGURE 1 iliustrates a single IP hop in a data network system S employing one embodiment of the invention. A router 20 at one end of the hop sends packets to another router 22 on the other end of the hop. The packets sent over the hop are associated with individual data flows (F1 = the first flow 24, F2 = the second flow 26, etc.).

The link between the routers 20 and 22 may be either a permanent or temporary link. It is used to transfer unmodified layer 3 protocol packets. Layer 3 is a network layer protocol and encompasses, for example, the Internet Protocol and those that conform to the Open System Interconnection ("OSI") reference model.

In accordance with one embodiment of the invention, a flow compressor 28 extracts individual flows and/or groups of flows from the inbound packets.

Each individual flow or group of flows may then be separately compressed by a compressor 30. The compressed flows are sent to the other end of the hop where a flow decompressor 32 separately decompresses each flow or flow group.

In the flow compressor 28, a flow identifier 34 analyzes an inbound packet to identify the layer 4 flow associated with the packet. Layer 4 is a transport layer protocol and encompasses, for example, the Transmission Control Protocol ("TCP") and those that conform to the Open System Interconnection ("OSI") reference model. The flow identifier 34 associates the flow with an identifier (ID 36). This identifier 36 uniquely identifies the associated flow or flow group.

The flow compressor 28 uses the ID 36 sent by the flow identifier 34 to retrieve a compression history file. As illustrated in FIGURE 1, several history files 38 are stored in the flow compressor 28, each of the history files 38 is associated with an active flow or an active flow group. The compressor 30 uses the retrieved history file to compress the packet.

Next, the flow compressor 28 associates an indicator with the packet.

The indicator uniquely identifies a flow or flow group. The flow compressor 28 sends this indicator with the compressed data to the flow decompressor 32 on

the other end of the hop so that the flow decompressor 32 can determine with which flow or flow group the compressed packet is associated.

At the flow decompressor 32, a flow identifier 40 reads the indicator accompanying the compressed packet to identify the flow or flow group associated with the packet. The flow identifier then sends an identifier (ID 42) to a decompressor 44 to enable the decompressor 44 to retrieve the appropriate compression history file 46. In accordance with conventional compression/decompression techniques, the compressor 30 and the decompressor 44 are implemented in a manner that ensures that each of them maintains analogous state information (compression history) for a given flow. In other words, for a given state in a particular flow, the corresponding history files in both the flow compressor 28 and the flow decompressor 32 will contain identical state information.

The decompressor 44 uses the retrieved history file 46 to decompress the packet. After the packet is decompressed, the flow decompressor 32 forwards the packet, which is now in its original, uncompressed state, to its destination.

Before treating the components of FIGURE 1 in more detail, the principals of adaptive data compression will be treated briefly. Adaptive compression methods are based on the idea that if the stream of data elements to be encoded is xi, X2, X3, etc., then the encoding of xt is based on information extracted from xi, X2,... Xf-i. Typically, each of the elements is a character.

However in some applications each element may be a word or some other character string. The first t-1 data elements are referred to as the history data at stage t.

The use of the history data enables the compression/decompression system to be adaptive. In other words, there is no need to transfer statistical distribution tables between the compressor and decompressor. Before the decompressor starts decompressing the compressed element xt, the decompressor knows the values of x1,... ut 1. Thus, the decompressor can evaluate the code from which the code-word for xt is extracted in exactly the same way as the compressor. The extracted information may be, for example,

the distribution of the various characters, i. e., their relative frequencies, which are necessary to derive a variable length code (e. g., Huffman's code) or an arithmetic code.

Another method considers the history as a dictionary (and does not count any frequencies) as is done in the Lempel-Ziv algorithms. These algorithms use the history by referring to it later. This enables the algorithm to avoid storing recurring strings more than once. This can be done either by referring explicitly into the history by a pointer giving the location and the length of the recurring string (Lempel-Ziv 77, commonly referred to as LZ77) or by building a table containing selected strings from the history and referring to the appropriate entry in the table (Lempel-Ziv 78, commonly referred to as LZ78).

With the above high-level description in mind, the details of one embodiment of the invention will be treated in conjunction with FIGURES 2-5.

FIGURES 2 and 3 are block diagrams of compressor and decompressor sections, respectively, of a device that is installe in the network. FIGURES 4 and 5 are flowcharts that describe operations that may be performed by the compressor and decompressor sections depicted in FIGURE 2 and 3, respectively, or by other embodiments of the invention.

In FIGURE 2, a flow compressor 28 processes an inbound stream of packets. A network input interface 50 terminates the physical layer and provides layer 2 packets to a processor 52. When the devices are installed between the routers 20 and 22 as illustrated in FIGURE 1, the network interface 50 connects to a wide area network ("WAN") as described above. In some embodiments, the device may be installed farther up the link (i. e., before the router 20). In this case, one or more of the network interfaces (50 and 54) may connect to a local area network ("LAN"). The network interface in this type of system will include a LAN-type interface such as an Ethernet interface. The details of the operation and implementation of network input interfaces are well known in the IP data networking art.

The processor 52 illustrated in FIGURE 2 includes several logical components. The operations of these components are described in conjunction with FIGURE 4 beginning at block 100.

At block 102, the processor 52 receives a layer 2 packet from the interface 50. Then, at block 104, a layer 3 packet identifier 56 reads the packet header to identify the layer 3 protocol of the packet. In the embodiment of FIGURE 2, the level 3 protocol is the Internet Protocol. The packet identifier 56 then sends the protocol information to a session handler 58 via line 60. This enables the session handler 58 to separate the flows. That is, once the session handler 58 knows the protocol of the incoming level 3 packet, the session handler 58 will know how to identify the flow within the packet.

In some embodiments, the flow compressor 28 may be configured to compress all packets. In other embodiments, however, the flow compressor 28 may selectively compress packets. The latter scenario is treated at block 106.

At block 106, a compression bypass component 62 determines whether this packet is to be compressed. If the packet should not be compressed, the compression bypass component 62 routes the packet directly to a packet assembler 64 via line 66 so that the packet bypasses the compression stage.

The operation of the packet assembler 64 at block 126 is discussed below.

The decision of whether to compress a packet may be based on various criteria. For example, the bypass component 62 may reroute all non-IP packets (e. g., RIP packets) so they bypass the compression stage.

In one embodiment, the compression bypass component 62 analyzes the inbound packet to determine whether it is encrypted. If it is encrypted, the bypass component 62 may skip the compression process for this packet.

Also, the bypass component 62 may cooperate with the session handler 58 to identify all packets associated with a given session or a given group of sessions and skip the compression process for the entire session or session group. This may be done, for example, when the packet originates from a well-known port that is used for encrypted data.

If, at block 106, the packet is to be compressed, the packet is routed to the session handler 58 via line 68. A session identifier 70 identifies the layer 4 flow associated with the packet (block 108). For TCP packets, the session identifier 70 may identify a session based on the combination of the source IP

address, the destination IP address, the source port and the destination port.

All of this information is contained in the header of the packet.

The session identifier 70 may also identify a particular session or member of a session group by analyzing the packet data. For example, the session identifier may look for certain strings, or a particular distribution of characters.

In one embodiment, the session handler 58 maintains a session table 72 of all sessions and session groups associated with the packets that have passed through this node of the network. The session table 72 is stored in a data memory 74 as illustrated in FIGURE 2.

The table entries may include an identifier for each session and session group along with information that identifies the flow. For example, an identifier for a session 76 may be associated with a source IP address, a destination IP address, a source port and a destination port. An identifier for a session group 78 may be associated, for example, with a source IP address and a destination IP address, with a port, or with a source IP address. It should be appreciated by one skilled in the art that many other methods of identifying flows may be used in accordance with the teachings of the invention.

At block 110, a new session identifier 80 determines whether the packet is associated with a new session or session group. For example, the new session identifier 80 may compare the current session information with the entries in the session table 72.

If the session information of the inbound packet is not in the session table 72 (i. e., the packet is associated with a new session or session group), the process proceeds to block 112. The session handler 58 passes the session information of the packet to a dictionary maintenance component 82 that creates an entry in the session table 72.

For example, the dictionary maintenance component 82 may generate an identifier that is associated with a session. In this case, the dictionary maintenance component 82 may create an entry 76 in the session table 72 for the identifier and the source IP address, the destination IP address, the source port and the destination port. Alternatively, to create an entry for a session

group 78, the dictionary maintenance component 82 may generate an identifier that is associated with the source IP address of the current session. In this case, the dictionary maintenance component 82 would store this information in the session table 72.

At block 114, the dictionary maintenance component 82 creates a dictionary entry 84 for the new session or session group. Depending on the compression scheme, the new dictionary entry 84 may or may not initially contain information. For example, some adaptive compression schemes generate the dictionary entries on-the-fly. In any event, the newly created compression dictionary information 84 is stored in the data memory 74 (e. g., as dictionary 1 84A) and the corresponding ID is sent to a compressor 86.

If, at block 110, the session information of the incoming packet is in the session table 72 (i. e., the packet is associated with a currently active session or session group), the session handler 58 sends the session identifier (ID) to the compressor 86 via line 88. The compressor 86 uses the ID to fetch the corresponding compression dictionary (e. g., dictionary 1 84A) from the data memory 74 (block 116).

At block 118, after receiving the packet from the session handler 58 via line 90, the packet compressor 86 compresses the packet using the compression dictionary 84. Various packet compression algorithms may be used at this stage. For example, the compressor 86 may implement a compression scheme based on Lempel-Ziv algorithms. A variant of LZ77, mentioned above, is discussed in U. S. Patent Nos. 5,016,009 and 5,126,739 (both of which are entitled Data Compression Apparatus and Method), the contents of which are hereby incorporated herein by reference. Another algorithm, known as LZW (which is a variant of LZ78), is discussed in U. S.

Patent No. 4,558,302, the contents of which is hereby incorporated herein by reference. Compression software also may be commercially available. For example, a packet compressor is sold under the name"STAC LZS"by Stac Electronics.

The packets associated with a given flow or flow group may be compressed separately or collectively. In the first case, the compression is

performed independently for each packet. Here, each packet may, in effect, have its own dictionary. In one embodiment, the packet is compressed using a static algorithm. For example, the algorithm may first scan the packet to gather statistics, then build a Huffman code based on these statistics, and finally rescan the packet to compress it. In another embodiment, the algorithm compresses each packet independently using an adaptive algorithm, like any Lempel-Ziv algorithm.

In the second case, a global compression algorithm may be used that acts on all the packets with the same auxiliary data. In one embodiment, for example, when compressing packet t, the algorithm uses the statistics of not only the packet t itself, but of all the packets 1,2, up to and including t. In another embodiment, the algorithm may base the compression of packet t only on the statistics gathered from packets 1,2, up to including packet t-1, but not packet t itself.

Depending upon system requirements, the compressor 86 may be implemented as several compressors so that several packets may be compressed simultaneously. In this case, the session handler 58 would distribute the packets to the compressors 86 as necessary. Depending on system design requirements, the compressors 86 may be implemented as several compression processes. The compression processes may run on one or more processors 52. Alternatively, the compressor 86 could be implemented in hardware using application specific integrated circuits or other logic circuits.

As represented by block 120, an end session identifier 92 checks the inbound packet to determine whether the current packet is the last packet that will be sent in the session. For example, in TCP, the packet type"FIN"indicates that this is the last packet in a session.

Under some circumstances, the end of a session may serve as an indication that the dictionary 84 and session table entries 76 and 78 may be cleared. For example, when the session is not associated with a group or when the session is the only active session in a group, the entries may be cleared after the last packet for that session is sent over the hop. In this case, the process proceeds to block 122. The dictionary maintenance component 82

deletes the ID and associated information from the session table 72 and deletes the corresponding dictionary entry 84 from the data memory 74.

Alternatively, the session handler 58 may use a time-out mechanism to ensure that obsolete dictionaries 84 and session table entries 76 and 78 are deleted. The time-out may be predefined or dynamic, depending on system resources.

At block 124, a compressed packet identifier 94 marks the compressed packet to indicate that it is compressed. In one embodiment, the compressed packet identifier 94 prefixes a one bit tag to each packet that indicates whether the packet is compressed.

In addition, the compressed packet identifier 94 attaches the indicator to the packet. As discussed above, the indicator identifies the flow or flow group for the packet. The indicator may consist of, for example, a non-encoded index of the flow.

At block 126, the packet assembler 64 assembles the packet (compressed or not) with the other packets being sent over the hop. This will involve, for example, generating a new header with a new checksum for those packets that were compressed.

Finally, at block 128, the processor 52 sends the packets to the network output interface 54. The network output interface 54 processes the network layer (e. g., IP) packets and provides the appropriate physical and data link layers to interface to the network. Details of the operation and implementation of a network output interface are also well known in the IP data networking art.

The process then ends at block 130.

Referring again to FIGURE 1, packets from the flow compressor 28 are routed over the network to the flow decompressor 32 on the other end of the hop. As shown in FIGURE 3, the flow decompressor 32 includes a network input interface 150 that terminates the physical and data link layers and provides network layer (e. g., IP) packets to a processor 152. The details of the operation and implementation of the network input interface 150 may be similar to those discussed above in conjunction with FIGURE 2.

Referring to FIGURE 5 beginning at block 200, the operation of the processor will now be treated in detail. Many of the components and operations depicted in FIGURES 3 and 5 are similar to those discussed above in conjunction with FIGURES 2 and 4. Consequently, these operations will only be treated briefly here.

At block 202, the processor 152 receives a packet from the network input interface 150. As above, the network input interface 150 terminates the physical layer and provides layer 2 packets to the processor 152. At block 204, a layer 3 packet identifier 156 reads the packet header to determine the layer 3 protocol of the packet.

At block 206, a compressed packet identifier 162 determines whether the inbound packet is compressed. As discussed above, this may involve checking a one bit tag prefixed to the packet that indicates whether the packet is compressed. If the packet is not compressed, the process proceeds to block 226 and the packet is forwarded to a packet assembler 164 via line 166. The operations of the packet assembler 164 are discussed below.

If at block 206 the packet is compressed, the packet and associated indicator are sent to a session handler 158 via lines 168 and 160, respectively.

Then, a session identifier 170 reads the indicator that accompanied the packet (block 208). In one embodiment, this process may simply consist of reading an index number assigned to the flow.

At block 210, a new session identifier 180 determines whether the packet is associated with a new session. In a similar manner as discussed above in conjunction with FIGURE 2, the session handler 158 may maintain a session table 172 for the active sessions and session groups.

If the session number of the incoming packet is not in the table, the process proceeds to block 212 and the dictionary maintenance component 182 enters the session or session group information into the session table 172.

Then, at block 214, the dictionary maintenance component 182 creates a compression dictionary entry 184 for the new session or session group.

If, at block 210, the session identifier of the incoming packet is in the session table 172, the process proceeds to block 216. Then, the flow

decompressor 32 uses the ID received via line 188 to fetch the compression dictionary 184 associated with the session or session group.

At block 218, the packet decompressor 186 uses the retrieved compression dictionary 184 to decompress the packet that was received via line 190. The decompression algorithms used by the decompressor 186 are compatible with the compression algorithm used by the compressor 86 in FIGURE 2.

It will be appreciated by one skilled in the art that the compressor 86 and the decompressor 186 may use dictionary schemes as are known in the art.

Thus, dictionaries may be pre-loaded into the data memories in the flow compressor 28 and the flow decompressor 32 or the dictionaries may initially be empty. In addition, the compression and decompression algorithms will use the same procedures to adaptively update the dictionaries 84 and 184 on-the-fly.

As represented by block 220, an end session identifier 192 determines whether the dictionary 184 for the current session or session group is still needed. As discussed above in conjunction with FIGURE 2, if the current packet is the last packet in the session or session group, the process proceeds to block 222. Here, the dictionary maintenance component 182 deletes the session information (176 or 178) from the session table 172, then it deletes the dictionary entry 184 for that session from the data memory 174. Again, these operations may be initiated by some form of background (e. g., time-out) routine.

At block 226, the packet assembler 164 assembles the packet (decompressed or not) with the other packets being sent over the hop. This will involve, for example, generating a new header with a new checksum for those packets that were decompressed.

Finally, at block 228, the processor 152 sends the packets to the network output interface 154. The network output interface 154 processes the network layer (e. g., IP) packets and provides the appropriate physical and data link layers to interface to the network. The details of the operation and implementation of the network output interface 154 may be similar to those of the interfaces discussed above in conjunction with FIGURE 2. The process then ends at block 230.

FIGURE 6 illustrates an embodiment of the invention that is implemented by integrating software modules 250 into equipment 252 installed at each end of a predefined path in the network N. The equipment 252 may consist of routers, bridges, switches, modems or any other equipment in the network N that handle packet traffic.

The packet compression and decompression operations performed by the embodiment of FIGURE 6 are similar to those described above in conjunction with FIGURES 2-5. The compressor software modules 254 and decompressor software modules 256 are linked in with software modules 258 in the equipment in a manner that enables the compressor and decompressor software modules 254 and 256 to intercept and process packets. A data memory 260 in the equipment may be used to store the packet data.

Typically, the compressor and decompressor software modules 254 and 256 may be implemented along the transmission path in the equipment 252 where the packets are fully visible. For example, some of the packets flowing through the network N may be encrypted. Thus, the compressor and decompressor software modules 254 and 256 may be linked in to the switch modules 258 so that the compressor and decompressor software modules 254 and 256 have access to decrypted data.

In FIGURE 6, a compressor 254 and a decompressor 256 are installed on both sides of a duplex link. Accordingly, packet traffic that flows in either direction over the path is compressed on a per session or session group basis.

FIGURE 6 also illustrates that the invention may be used on more than a single IP hop. In FIGURE 6, the packets are routed through the network 262 and, as a result, they may be routed over several hops. For example, another hop between two routers 264 and 266 is shown. In this case, appropriate routing provisions should be made to ensure that all compressed packets are routed to the same receive module at the other end of the path. This may include, for example, defining static routes using IP tunneling.

In the compression scheme above, it is important to maintain the reliability of the link. This is because in order to decompress packet n, the decompressor 256 must first decompress packets 1 through n-1. Reliability

may be provided, for example, by the reliability mechanism associated with TCP, HDLC (in its reliable mode) or PPP (in its reliable mode).

In addition, various initialization procedures may be performed. For example, all dictionaries may be erased and various compression parameters may be exchanged between the flow compressor and the flow decompressor.

These initialization procedures may be accomplished using a relatively simple three-way handshake similar to the one used in TCP.

From the above, it may be seen that the invention provides an effective method of compressing transmitted packets. In particular, the invention may provide a higher degree of compression and use data memory more efficiently than many conventional systems. While certain specific embodiments of the invention are disclosed as typical, the invention is not limited to these particular forms, but rather is applicable broadly to all such variations as fall within the scope of the appended claims. To those skilled in the art to which the invention pertains many modifications and adaptations will occur.

For example, the devices may be installed at various locations within the network. The invention may be implemented using a variety of hardware and software architectures. The teachings of the invention are applicable to numerous protocols in addition to those described above. A number of compression algorithms and compression history techniques may be used to compress or decompress data. The system may compress and decompress various types of flows of various types of data. Also, other forms of flow identifiers may be used. Thus, the specific structures and methods discussed in detail above are merely illustrative of a few specific embodiments of the invention.