Network Working Group J. Heath
Request for Comments: 3051 J. Border
Category: Informational Hughes Network Systems
January 2001
Network Working Group J. Heath
Request for Comments: 3051 J. Border
Category: Informational Hughes Network Systems
January 2001
IP Payload Compression Using ITU-T V.44 Packet Method
使用ITU-T V.44数据包方法的IP有效负载压缩
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.
版权所有（C）互联网协会（2001年）。版权所有。
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 (RFC 2393). RFC 2393 defines a method for applying lossless compression to the payload portion of IP datagrams.
本文件描述了一种基于国际电信联盟（ITU-T）建议V.44中描述的数据压缩算法的压缩方法。建议V.44是调制解调器标准，但该建议的附录B第B.1条描述了V.44在分组网络中的实现（例如，V.44分组方法）。本文件定义了V.44数据包方法在互联网协议（IP）有效载荷压缩协议（RFC 2393）中的应用。RFC 2393定义了一种对IP数据报的有效负载部分应用无损压缩的方法。
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.
V.44数据包方法基于LZJH数据压缩算法。在本文件其余部分中，术语V.44数据包方法和LZJH是同义词。
Table of Contents
目录
1. Introduction...................................................2
1.1 General....................................................2
1.2 Background of LZJH Data Compression........................2
1.3 Intellectual Property Rights...............................3
1.4 Specification of Requirements..............................4
2. Compression Process............................................4
2.1 Encoder Dictionary.........................................4
2.2 Encoder Output.............................................4
2.3 Padding....................................................4
3. Decompression Process..........................................5
3.1 Compressed Datagram........................................5
3.2 Original Uncompressed Datagram.............................5
4. IPComp Association (IPCA) Parameters...........................5
4.1 Transform ID...............................................5
4.2 Security Association Attributes............................5
4.3 Manual configuration.......................................5
4.4 Minimum packet size threshold..............................6
4.5 Compressibility test.......................................6
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. Acknowledgements...............................................6
8. References.....................................................6
9. Authors' Addresses.............................................7
10. Full Copyright Statement.......................................8
1. Introduction...................................................2
1.1 General....................................................2
1.2 Background of LZJH Data Compression........................2
1.3 Intellectual Property Rights...............................3
1.4 Specification of Requirements..............................4
2. Compression Process............................................4
2.1 Encoder Dictionary.........................................4
2.2 Encoder Output.............................................4
2.3 Padding....................................................4
3. Decompression Process..........................................5
3.1 Compressed Datagram........................................5
3.2 Original Uncompressed Datagram.............................5
4. IPComp Association (IPCA) Parameters...........................5
4.1 Transform ID...............................................5
4.2 Security Association Attributes............................5
4.3 Manual configuration.......................................5
4.4 Minimum packet size threshold..............................6
4.5 Compressibility test.......................................6
5. Security Considerations........................................6
6. IANA Considerations............................................6
7. Acknowledgements...............................................6
8. References.....................................................6
9. Authors' Addresses.............................................7
10. Full Copyright Statement.......................................8
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) [RFC2393]. This document is written with the assumption that the reader has an understanding of the IPComp protocol.
本文件规定了LZJH数据压缩（无损数据压缩算法）在IP数据报有效载荷中的应用。LZJH数据压缩将与IP有效负载压缩协议（IPComp）[RFC2393]结合使用。本文档的编写假设读者了解IPComp协议。
LZJH is similar to the algorithm described in [LZ78] although it also has aspects which are similar to the algorithm described in [LZ77]. As such, it provides the execution speed and low memory requirements of [LZ78] with compression ratios that are better than [LZ77]. 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
LZJH类似于[LZ78]中描述的算法，尽管它也有类似于[LZ77]中描述的算法的方面。因此，它为[LZ78]提供了比[LZ77]更好的执行速度和低内存要求。最初是为卫星行业独立压缩IP数据报而开发的，非常适合IPComp应用。对LZJH算法进行了修改，以压缩调制解调器环境中的连续数据流，此修改版本是
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.
建议五.44。LZJH是一种自适应、通用、无损数据压缩算法。ITU-T选择它作为建议V.44的基础，这是基于它在各种数据类型（特别是web HTML）中的性能，以及它的压缩比特性、每MIP和所使用的内存（与其他候选算法相比）。它的编码器非常高效，在数据中第二次遇到两个字符的字符串时，可以用3位编码该字符串。
A typical [LZ78] 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 [LZ78] dictionary between datagrams which adversely affects execution times.
典型的[LZ78]压缩算法（如V.42bis）不适合IPComp应用程序，因为它需要花费太长时间来建立字典，导致独立压缩的IP数据报的压缩率很低。它还需要太多的周期来重置数据报之间的[LZ78]字典，这会对执行时间产生不利影响。
Similarly, a typical [LZ77] 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.
类似地，典型的[LZ77]压缩算法在IPComp应用程序中由于执行时间差而受到影响。哈希表有助于在压缩连续数据时缩短执行时间，这可能会导致IPComp应用程序中的执行时间缩短，因为它们必须在每个数据报之间重置为初始状态。
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.
LZJH不仅在编码或解码分组数据时具有优越的执行时间，而且IP数据报之间字典的重置也非常简单。编码器只需要初始化256字数组和少量变量，而解码器只需要初始化少量变量。
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.
LZJH算法为IPComp应用程序使用1525个条目的字典，总共只有16K的字典内存。在编码过程中，不匹配的字符被编码为序数，匹配的冗余字符串被编码为表示冗余字符串的码字或字符串扩展长度。在解码过程中，序号、码字和字符串扩展长度被解释为完全重新创建原始数据报负载。
The details of LZJH data compression can be found in [V44].
LZJH数据压缩的详细信息见[V44]。
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.
IETF已收到关于本文件所含部分或全部规范的知识产权要求通知。有关更多信息，请查阅在线权利主张列表。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The compression of datagrams is performed by a function called the Encoder.
数据报的压缩由一个称为编码器的函数执行。
The transmitting entity MUST reset the encoder dictionary prior to processing each datagram's payload, as specified in clause 7.5.1 of [V44]. 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.
按照[V44]第7.5.1条的规定，传输实体必须在处理每个数据报的有效载荷之前重置编码器字典。这确保了每个数据报的有效载荷可以独立于任何其他有效载荷而正确解压缩，这是在数据报可能丢失或无序接收的环境中所需要的。
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.
传输实体必须在数据报的最后一个字节被传递到编码器后刷新未处理的编码器数据，以便压缩数据报可以作为一个单元传输。刷新确保所有数据都已处理并包含在输出中，即压缩数据报已完成，当前数据报中的任何数据都不会与下一个数据报一起处理。
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.
有效负载压缩算法的输入是IP数据报有效负载。该算法的输出是一个新的（希望更小）有效载荷。输出有效负载包含压缩或未压缩格式的输入有效负载数据。输入和输出有效负载的长度均为整数字节。
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 [V44].
如果使用未压缩表单，则输出有效负载与输入有效负载相同，并且省略IPComp头。如果使用了压缩格式，则输出有效负载将以IPComp头作为前缀，并按照[V44]第6.3条中的定义进行编码。
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
使用LZJH压缩的数据报有效负载总是以最后一个或两个压缩数据字节中的刷新码字结束。刷新码字可以从第二个到最后一个压缩数据字节开始，到最后一个压缩数据字节结束，或者完全在最后一个数据字节内。FLUSH码字用于发出信号，表示
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.
压缩有效负载的大小必须以整个八位字节为单位。
The decompression of datagrams is performed by a function called the Decoder.
数据报的解压缩由一个称为解码器的函数执行。
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 [V44], the receiver decodes the payload data field of the datagram according to the procedure specified in clause 6.4 of [V44].
如果接收到的数据报被压缩，接收器必须在处理数据报之前重置解码器字典。这确保在数据报丢失或接收顺序错误的情况下，每个数据报可以独立于任何其他数据报进行解码。按照[V44]第7.5.2条的规定，从处于初始状态的解码器字典开始，接收器根据[V44]第6.4条规定的程序对数据报的有效载荷数据字段进行解码。
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.
如果接收到的数据报未被压缩，则接收器不执行压缩解码，并将数据报的有效载荷数据字段未经更改地传递到下一协议层。
IKE [RFC2409] MAY be used to negotiate the use of the LZJH compression algorithm to establish an IPCA, as defined in [RFC2393].
IKE[RFC2409]可用于协商LZJH压缩算法的使用，以建立IPCA，如[RFC2393]中所定义。
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.
LZJH转换ID的值是ipcompu LZJH。此值用于协商使用IKE的LZJH数据压缩算法的使用。
There are no other parameters required for the negotiation of the LZJH compression algorithm using IKE.
使用IKE协商LZJH压缩算法不需要其他参数。
The CPI value IPCOMP_LZJH is used for manually configured IPComp Compression Associations.
CPI值IPCOMP_LZJH用于手动配置的IPCOMP压缩关联。
As stated in [RFC2393], 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.
如[RFC2393]所述，小数据包可能无法很好地压缩。在internet网页和电子邮件文件上使用LZJH算法进行的非正式测试表明，通常生成扩展数据的平均有效负载大小约为50字节。因此，实现可能不希望尝试压缩大约50字节或更小的有效负载。
The LZJH algorithm, as described in [V44], is easily modified to incorporate an adaptive compressibility test, as referenced in [RFC2393]. Annex B of [V44] specifies the mechanism for including such a test in LZJH.
如[V44]所述，LZJH算法易于修改，以纳入自适应压缩性测试，如[RFC2393]所述。[V44]附录B规定了LZJH中包含此类试验的机制。
This document does not add any further security considerations to those discussed in [RFC2393].
本文件未在[RFC2393]中讨论的安全注意事项之外添加任何其他安全注意事项。
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 [RFC2407]. IANA has assigned a value of 4 for this purpose.
本文档不引入任何新的名称空间。IPCOMP_LZJH的值是从[RFC2407]中定义的IPsec IPCOMP转换标识符空间分配的。IANA为此指定了一个值4。
This document is modeled upon [RFC2395].
本文件以[RFC2395]为蓝本。
[LZ77] Lempel, A., and Ziv, J., "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, May 1977.
[LZ77]Lempel，A.，和Ziv，J.，“顺序数据压缩的通用算法”，IEEE信息论学报，第IT-23卷，第3期，1977年5月。
[LZ78] 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.
[LZ78]Lempel，A.，和Ziv，J.，“通过可变速率编码对单个序列的压缩”，IEEE信息论学报，第IT-24卷，第5期，1978年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2393] Shacham, A., "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[RFC2393]Shacham，A.，“IP有效载荷压缩协议（IPComp）”，RFC 23931998年12月。
[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.
[RFC2395]Friend，R.和R.Monsour，“使用LZS的IP有效负载压缩”，RFC 2395，1998年12月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November, 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换”，RFC 2409，1998年11月。
[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44 "Data Compression Procedures", November 2000.
[V44]国际电联电信标准化部门（ITU-T）建议V.44“数据压缩程序”，2000年11月。
Jeff Heath Hughes Network Systems 10450 Pacific Center Ct. San Diego, CA 92121
杰夫·希思·休斯网络系统10450太平洋中心Ct。加利福尼亚州圣地亚哥92121
Phone: 858-452-4826 Fax: 858-597-8979 EMail: jheath@hns.com
电话：858-452-4826传真：858-597-8979电子邮件：jheath@hns.com
John Border Hughes Network Systems 11717 Exploration Lane Germantown, MD 20876
约翰·博德·休斯网络系统公司，马里兰州日尔曼镇探索巷11717号，邮编20876
Phone: 301-601-4099 Fax: 301-601-4275 EMail: border@hns.com
电话：301-601-4099传真：301-601-4275电子邮件：border@hns.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。