3051
INFORMATIONAL
IP Payload Compression Using ITU-T V.44 Packet Method
Authors: J. Heath, J. Border
Date: January 2001
Stream: Legacy
Abstract
This document describes a compression method based on the data compression algorithm described in International Telecommunication Union (ITU-T) Recommendation V.44. This document defines the application of V.44 Packet Method to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). This memo provides information for the Internet community.
RFC 3051
INFORMATIONAL
Network Working Group J. Heath
Request for Comments: 3051 J. Border
Category: Informational Hughes Network Systems
January 2001
<span class="h1">IP Payload Compression Using ITU-T V.44 Packet Method</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes a compression method based on the data
compression algorithm described in International Telecommunication
Union (ITU-T) Recommendation V.44. Recommendation V.44 is a modem
standard but Annex B, Clause B.1, of the recommendation describes the
implementation of V.44 in packet networks (e.g., V.44 Packet Method).
This document defines the application of V.44 Packet Method to the
Internet Protocol (IP) Payload Compression Protocol (<a href="./rfc2393">RFC 2393</a>). <a href="./rfc2393">RFC</a>
<a href="./rfc2393">2393</a> defines a method for applying lossless compression to the
payload portion of IP datagrams.
V.44 Packet Method is based upon the LZJH data compression algorithm.
Throughout the remainder of this document the terms V.44 Packet
Method and LZJH are synonymous.
<span class="grey">Heath & Border Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
Table of Contents
<a href="#section-1">1</a>. Introduction...................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a> General....................................................<a href="#page-2">2</a>
<a href="#section-1.2">1.2</a> Background of LZJH Data Compression........................<a href="#page-2">2</a>
<a href="#section-1.3">1.3</a> Intellectual Property Rights...............................<a href="#page-3">3</a>
<a href="#section-1.4">1.4</a> Specification of Requirements..............................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Compression Process............................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a> Encoder Dictionary.........................................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a> Encoder Output.............................................<a href="#page-4">4</a>
<a href="#section-2.3">2.3</a> Padding....................................................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Decompression Process..........................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a> Compressed Datagram........................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a> Original Uncompressed Datagram.............................<a href="#page-5">5</a>
<a href="#section-4">4</a>. IPComp Association (IPCA) Parameters...........................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a> Transform ID...............................................<a href="#page-5">5</a>
<a href="#section-4.2">4.2</a> Security Association Attributes............................<a href="#page-5">5</a>
<a href="#section-4.3">4.3</a> Manual configuration.......................................<a href="#page-5">5</a>
<a href="#section-4.4">4.4</a> Minimum packet size threshold..............................<a href="#page-6">6</a>
<a href="#section-4.5">4.5</a> Compressibility test.......................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Security Considerations........................................<a href="#page-6">6</a>
<a href="#section-6">6</a>. IANA Considerations............................................<a href="#page-6">6</a>
<a href="#section-7">7</a>. Acknowledgements...............................................<a href="#page-6">6</a>
<a href="#section-8">8</a>. References.....................................................<a href="#page-6">6</a>
<a href="#section-9">9</a>. Authors' Addresses.............................................<a href="#page-7">7</a>
<a href="#section-10">10</a>. Full Copyright Statement.......................................<a href="#page-8">8</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a> General</span>
This document specifies the application of LZJH data compression, a
lossless data compression algorithm, to IP datagram payloads. LZJH
data compression is to be used in conjunction with the IP Payload
Compression Protocol (IPComp) [<a href="./rfc2393" title=""IP Payload Compression Protocol (IPComp)"">RFC2393</a>]. This document is written
with the assumption that the reader has an understanding of the
IPComp protocol.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a> Background of LZJH Data Compression</span>
LZJH is similar to the algorithm described in [<a href="#ref-LZ78" title=""Compression of Individual Sequences via Variable Rate Coding"">LZ78</a>] although it also
has aspects which are similar to the algorithm described in [<a href="#ref-LZ77" title=""A Universal Algorithm for Sequential Data Compression"">LZ77</a>].
As such, it provides the execution speed and low memory requirements
of [<a href="#ref-LZ78" title=""Compression of Individual Sequences via Variable Rate Coding"">LZ78</a>] with compression ratios that are better than [<a href="#ref-LZ77" title=""A Universal Algorithm for Sequential Data Compression"">LZ77</a>].
Originally developed for the satellite industry to compress IP
datagrams independently, it is ideal for the IPComp application. The
LZJH algorithm was modified to compress a continuous stream of data
for a modem environment and this modified version is the basis for
<span class="grey">Heath & Border Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
Recommendation V.44. LZJH is an adaptive, general purpose, lossless
data compression algorithm. It was selected by the ITU-T as the
basis for Recommendation V.44 based on its performance across a wide
variety of data types, particularly web HTML's, and based on its
compression ratio characteristics, per MIP and memory utilized (as
compared to other candidate algorithms). Its encoder is extremely
efficient and can encode a two character string with 3 bits the
second time that string is encountered in the data.
A typical [<a href="#ref-LZ78" title=""Compression of Individual Sequences via Variable Rate Coding"">LZ78</a>] compression algorithm, such as V.42bis, is not
suitable for an IPComp application since it takes too long to build
up its dictionary, resulting in poor compression ratios on IP
datagrams that are compressed independently. It also requires too
many cycles to reset an [<a href="#ref-LZ78" title=""Compression of Individual Sequences via Variable Rate Coding"">LZ78</a>] dictionary between datagrams which
adversely affects execution times.
Similarly, a typical [<a href="#ref-LZ77" title=""A Universal Algorithm for Sequential Data Compression"">LZ77</a>] compression algorithm suffers in the
IPComp application due to poor execution times. Hash tables, that
help improve execution times when compressing continuous data, may
cause deterioration of execution times in an IPComp application since
they must be reset to an initial state between each datagram.
LZJH not only has superior execution times when encoding or decoding
packet data, but the reset of the dictionary between IP datagrams is
trivial. The encoder requires only the initialization of a 256 word
array and a handful of variables while the decoder requires only the
initialization of a handful of variables.
The LZJH algorithm uses a dictionary of 1525 entries, a total of only
16K of dictionary memory, for the IPComp application. During the
encode process unmatched characters are encoded as ordinals and
matched redundant strings of characters are encoded as codewords or
string-extension lengths that represent the redundant strings.
During the decode process the ordinals, codewords, and string-
extension lengths are interpreted to re-create exactly the original
datagram payload.
The details of LZJH data compression can be found in [<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>].
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a> Intellectual Property Rights</span>
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specifications contained in this
document. For more information, consult the online list of claimed
rights.
<span class="grey">Heath & Border Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a> Specification of Requirements</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Compression Process</span>
The compression of datagrams is performed by a function called the
Encoder.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a> Encoder Dictionary</span>
The transmitting entity MUST reset the encoder dictionary prior to
processing each datagram's payload, as specified in clause 7.5.1 of
[<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>]. This ensures that each datagram's payload can be correctly
decompressed independently of any other, as is required in an
environment where datagrams may be lost or received out of order.
The transmitting entity MUST flush unprocessed encoder data after the
last byte of the datagram has been passed into the encoder such that
the compressed datagram can be transmitted as a unit. The flush
ensures that all data is processed and included in the output, i.e.,
the compressed datagram is complete and no data from the current
datagram will be processed with the next datagram.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a> Encoder Output</span>
The input to the payload compression algorithm is an IP datagram
payload. The output of the algorithm is a new (and hopefully
smaller) payload. The output payload contains the input payload's
data in either compressed or uncompressed format. The input and
output payloads are each an integral number of bytes in length.
If the uncompressed form is used, the output payload is identical to
the input payload and the IPComp header is omitted. If the
compressed form is used, the output payload is prepended with the
IPComp header and encoded as defined in clause 6.3 of [<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>].
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a> Padding</span>
A datagram payload compressed using LZJH always ends with a FLUSH
codeword in the last one or two compressed data bytes. The FLUSH
codeword may start in the 2nd to the last compressed data byte and
end in the last compressed data byte or be totally within the last
data byte. The FLUSH codeword is used to signal the end of the
<span class="grey">Heath & Border Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
compressed data and differentiate compressed data from padding. Any
bits or bytes beyond the FLUSH codeword within the compressed payload
are to be considered padding.
The size of a compressed payload MUST be in whole octet units.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Decompression Process</span>
The decompression of datagrams is performed by a function called the
Decoder.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a> Compressed Datagram</span>
If the received datagram is compressed, the receiver MUST reset the
decoder dictionary prior to processing the datagram. This ensures
that each datagram can be decoded independently of any other datagram
in the event datagrams are lost or received out of order. Beginning
with the decoder dictionary in the initial state, as specified in
clause 7.5.2 of [<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>], the receiver decodes the payload data field of
the datagram according to the procedure specified in clause 6.4 of
[<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a> Original Uncompressed Datagram</span>
If the received datagram is not compressed, the receiver does not
perform compression decoding and passes the payload data field of the
datagram unaltered to the next protocol layer.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IPComp Association (IPCA) Parameters</span>
IKE [<a href="./rfc2409" title=""The Internet Key Exchange"">RFC2409</a>] MAY be used to negotiate the use of the LZJH
compression algorithm to establish an IPCA, as defined in [<a href="./rfc2393" title=""IP Payload Compression Protocol (IPComp)"">RFC2393</a>].
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a> Transform ID</span>
The value of the LZJH Transform ID is IPCOMP_LZJH. This value is
used to negotiate the use of the LZJH data compression algorithm
using IKE.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a> Security Association Attributes</span>
There are no other parameters required for the negotiation of the
LZJH compression algorithm using IKE.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a> Manual configuration</span>
The CPI value IPCOMP_LZJH is used for manually configured IPComp
Compression Associations.
<span class="grey">Heath & Border Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a> Minimum packet size threshold</span>
As stated in [<a href="./rfc2393" title=""IP Payload Compression Protocol (IPComp)"">RFC2393</a>], small packets may not compress well.
Informal tests using the LZJH algorithm on internet web pages and e-
mail files show that the average payload size that typically produces
expanded data is approximately 50 bytes. Thus, implementations may
prefer not to attempt to compress payloads of approximately 50 bytes
or smaller.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a> Compressibility test</span>
The LZJH algorithm, as described in [<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>], is easily modified to
incorporate an adaptive compressibility test, as referenced in
[<a href="./rfc2393" title=""IP Payload Compression Protocol (IPComp)"">RFC2393</a>]. Annex B of [<a href="#ref-V44" title=""Data Compression Procedures"">V44</a>] specifies the mechanism for including
such a test in LZJH.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
This document does not add any further security considerations to
those discussed in [<a href="./rfc2393" title=""IP Payload Compression Protocol (IPComp)"">RFC2393</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
This document does not introduce any new name spaces. The value of
IPCOMP_LZJH is assigned from the IPsec IPCOMP transform identifier
space defined in [<a href="./rfc2407" title=""The Internet IP Security Domain of Interpretation for ISAKMP"">RFC2407</a>]. IANA has assigned a value of 4 for this
purpose.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
This document is modeled upon [<a href="./rfc2395" title=""IP Payload Compression Using LZS"">RFC2395</a>].
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
[<a id="ref-LZ77">LZ77</a>] Lempel, A., and Ziv, J., "A Universal Algorithm for
Sequential Data Compression", IEEE Transactions On
Information Theory, Vol. IT-23, No. 3, May 1977.
[<a id="ref-LZ78">LZ78</a>] Lempel, A., and Ziv, J., "Compression of Individual
Sequences via Variable Rate Coding", IEEE Transactions On
Information Theory, Vol. IT-24, No. 5, Sep 1978.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2393">RFC2393</a>] Shacham, A., "IP Payload Compression Protocol (IPComp)",
<a href="./rfc2393">RFC 2393</a>, December 1998.
<span class="grey">Heath & Border Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
[<a id="ref-RFC2395">RFC2395</a>] Friend, R. and R. Monsour, "IP Payload Compression Using
LZS", <a href="./rfc2395">RFC 2395</a>, December 1998.
[<a id="ref-RFC2407">RFC2407</a>] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", <a href="./rfc2407">RFC 2407</a>, November, 1998.
[<a id="ref-RFC2409">RFC2409</a>] Harkins, D. and D. Carrel, "The Internet Key Exchange", <a href="./rfc2409">RFC</a>
<a href="./rfc2409">2409</a>, November 1998.
[<a id="ref-V44">V44</a>] ITU Telecommunication Standardization Sector (ITU-T)
Recommendation V.44 "Data Compression Procedures", November
2000.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Authors' Addresses</span>
Jeff Heath
Hughes Network Systems
10450 Pacific Center Ct.
San Diego, CA 92121
Phone: 858-452-4826
Fax: 858-597-8979
EMail: [email protected]
John Border
Hughes Network Systems
11717 Exploration Lane
Germantown, MD 20876
Phone: 301-601-4099
Fax: 301-601-4275
EMail: [email protected]
<span class="grey">Heath & Border Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc3051">RFC 3051</a> IP Payload Compression Using ITU-T V.44 January 2001</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Heath & Border Informational [Page 8]
Annotations
Select text to annotate