This Utility Patent Application claims priority to German Patent Application No. DE 103 53 289.7, filed on Nov. 14, 2003, which is incorporated herein by reference.
The present invention relates to a method and to a device for compressing data packets, in particular data packets according to the IPv6 standard, and to a method and a device for decompressing data packets encoded using the method.
Data packets have long been sent via the Internet according to what is known as the IPv4 (Internet Protocol Version 4) standard. Each data packet has what is known as a header which contains, for example, a source address and a destination address as well as other information necessary to forward the data packet via the Internet or another network. For these data packets according to the IPv4 standard a compression algorithm is widely used for the header data, the algorithm being based on the fact that, in a sequence of data packets, the data in the header frequently does not change or changes only slightly, for example because all data packets are to be sent to the same address. Therefore, only data which changes frequently or coincidentally is transmitted in each header with this compression algorithm. Occasionally therefore a packet with a complete header is transmitted while subsequent headers are based on the header of the completely transmitted packet and only contain changes relating to this header.
These compression algorithms are based on a connection between two adjacent network nodes, a data packet typically being sent to the respective destination address via a large number of network nodes. It is necessary here for each packet to be decompressed and compressed again in each node. In addition, if many streams of data packets are to be sent via one connection, the situation may occur where the allocation of the header to a previously sent header is difficult and the data packets therefore have to be sent uncompressed with complete headers.
To take account of the steep growth in the Internet, a new standard, IPv6, has been proposed which, for example, can address a larger address space. With this standard what are known as “extension headers”, which, for example can contain a so-called routing table which indicates via which routers or network nodes the data packet is to be sent, can be used. These router tables often require a large amount of storage space.
One embodiment of the present invention provides a method and a device for compressing data packets and, in particular, header data, which does not require allocation of a data packet to a preceding data packet. One embodiment is suitable for the compression of headers according to the IPv6 standard.
According to one embodiment of the invention for compressing a data packet, the data packet comprising at least a first data block and a second data block and the first data block referring to a second data block, it is proposed to compress the second data block and it is to be noted in the data packet that the second data block has been compressed.
This noting can, for example, take place in the second data block, in particular in a field which indicates the second data block type. Furthermore, compression parameters like a Huffman table for decompressing said second data block may be stored in the data packet.
In one embodiment, the compression does not depend on the preceding data packets, but takes place within a single data packet.
The first data block can, in particular, be a main header of the data packet and the second data block an extension header of the data packet. The extension header can, for example, comprise network addresses via which the data packet is to be routed in a network.
In one embodiment, the method is suitable for compressing data packets according to the IPv6 standard, wherein the extension header can in this case be a routing header. In one embodiment, compression of the second data block is carried out here using a lossless compression algorithm, for example what is known as the Huffman algorithm. A Huffman table used for this purpose can be stored in the data packet and directly transmitted, but a predetermined Huffman table can also be used which, for example, takes account of generally occurring data symbol distributions.
In order to compress the Huffman table itself, for a first and a second data symbol, of which the codes correspond except for the last bit, it is possible for only the code of the first data symbol to be entered and the second data symbol to be associated with the first data symbol in the Huffman table. This means that in the representation of the Huffman table as a binary tree, in each case only the code which corresponds to a left-hand leaf or the code which corresponds to a right-hand leaf of the binary tree is ever transmitted. This principle can generally be applied in compression algorithms according to the Huffman method to reduce the Huffman table.
The accompanying drawings are included to provide a further understanding of the present invention and are incorporated in and constitute a part of this specification. The drawings illustrate the embodiments of the present invention and together with the description serve to explain the principles of the invention. Other embodiments of the present invention and many of the intended advantages of the present invention will be readily appreciated as they become better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.
In the following Detailed Description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in which the invention may be practiced. In this regard, directional terminology, such as “top,” “bottom,” “front,” “back,” “leading,” “trailing,” etc., is used with reference to the orientation of the Figure(s) being described. Because components of embodiments of the present invention can be positioned in a number of different orientations, the directional terminology is used for purposes of illustration and is in no way limiting. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.
The embodiment described hereinafter is based on the compression of headers according to the IPv6 standard. The method according to the invention or the device according to the invention can, however, easily be transferred to other data packets and other components of data packets.
Field 7 is 128 bits and contains a source address of the data packet. Field 8 is also 128 bits long and contains a destination address of the data packet.
As data packets in the Internet are not sent via fixed transmission paths, but rather the route of data packets may vary, it may be desirable to predetermine network nodes or so-called routers via which the data packet is to be routed. For this purpose, the possibility of providing the data packet with a so-called routing header as the extension header is provided in the IPv6 standard.
Following field 15 are N, where N is a maximum of 23, address fields 161 to 16N, which are each 128 bits in length and contain the addresses of the network nodes to be used.
When this routing header is processed in a node, a check is made as to whether field 14 is not equal to zero. If this is the case, the following address, and possibly the corresponding bit from the “strict/loose bit map”, pertaining to the address, is extracted. Field 8 of the IPv6 header 9 of the data packet and the corresponding address field 16 of the routing header 17 are then exchanged, so the data packet is forwarded to the next network node to be used.
The ascertained compression parameters are stored in tabular form in a memory 22 and used in block 21 to compress the data block, in other words the routing header 17 in the present example. The table from the memory 22 is then added to the compressed data block in block 23. Of course, the compression parameters may be stored also in a form different from a table. In addition, the data block is identified as being compressed, and this can take place, for example, in that a field corresponding to field 11 is placed in front of the compressed data block and one of the numbers (101 to 255) previously not defined for this field is used in order to indicate that it is a compressed data block. However, it would, for example, also be possible to indicate this in field 5 of the IPv6 header 9 by means of a previously unused number. In addition, other fields can be used for the purpose of indicating the size of the table with the compression parameters, the size of the compressed data or the compression method. It may also be indicated whether just one header or data block or a plurality of data blocks or headers, optionally multiplexed, have been compressed.
In the case of a compressed routing header as in the present example, the fields 12, 13 and 14 are unchanged. In this example, a network node receiving the packet, which is not the final destination node, can, by means of the information there, decompress the address in a targeted manner using a suitable compression method, the address being required by the network node to forward the data packet, and can leave the remaining contents of the compressed routing header unchanged.
A device according to
The so-called Huffman algorithm is used in this case as the compression algorithm. This is based on the fact that frequently occurring data symbols are allocated a short code, less frequently occurring data symbols, on the other hand, are allocated a longer code. This shall be described hereinafter with reference to an example. The following table shows an example of a typical routing header with 23 addresses. The fields correspond here to those illustrated in
It can clearly be seen that the zero, for example, occurs very frequently in the addresses. The colons in the addresses are used here for the purpose of sub-division. The codes resulting according to the Huffman algorithm for the data symbols 0 to f used are shown in the following table, the Huffman code being given as a binary number.
In this case the Huffman code “1”, which has a length of 1 bit, is allocated to the data symbol. On the other hand, the Huffman code 011110, which has length of 6 bits, is allocated to the substantially less frequently occurring data symbol 6.
The allocation can also be illustrated by means of a binary tree as illustrated in
For longer address tables, which can also occur in data blocks, or if the method is applied to a large number of headers of this type, an even better compression ratio may even result, as is illustrated in the following table for five different examples. Here the address tables have between 84840 and 814464 entries. The gain in compression is above 50% in each case.
An additional compression results when only the code for the symbol of the left-hand “leaf” of the binary tree from
The Huffman code in each row is the Huffman code for the data symbol in the data symbol 1 column. The code for the data symbol in the data symbol 2 column is produced in that the last bit is inverted in each case.
A reduced Huffman table of this type can be used not only in the context of the described method for compressing data packets, but generally for compressing data using the Huffman algorithm and can be implemented both in terms of hardware, using fixed logic circuits, and also in terms of software. The length of the compressed header plus the Huffman table results in a length of 2114 bits for the illustrated example, the table now only having a length of 140 bits. The gain in compression has therefore increased to 31.3% per packet. If a plurality of routing headers are examined an even better ratio can generally be achieved here.
The present invention is not limited to the use of the Huffman algorithm. Any lossless compression algorithms such as arithmetic algorithms, algorithms of the LZ (Lempel-Ziv) family or adaptive algorithms can be used.
The compression can also be extended to other data blocks of the data packet. These other data blocks do not then have to be decompressed at all in network nodes which are not the network nodes predetermined by the destination address of the data packet.
Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the specific embodiments discussed herein. Therefore, it is intended that this invention be limited only by the claims and the equivalents thereof.
Number | Date | Country | Kind |
---|---|---|---|
103 53 289.7 | Nov 2003 | DE | national |