Network Working Group R. Friend
Request for Comments: 2395 R. Monsour
Category: Informational Hi/fn, Inc.
December 1998
Network Working Group R. Friend
Request for Comments: 2395 R. Monsour
Category: Informational Hi/fn, Inc.
December 1998
IP Payload Compression Using LZS
使用LZS的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 (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This document describes a compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams.
本文描述了一种基于LZS压缩算法的压缩方法。本文档定义了LZS算法在IP有效负载压缩协议[IPCOMP]中的应用。[IPCOMP]定义了一种将无损压缩应用于互联网协议数据报有效负载的方法。
Table of Contents
目录
1. Introduction...................................................2
1.1 General....................................................2
1.2 Background of LZS Compression..............................2
1.3 Licensing..................................................3
1.4 Specification of Requirements..............................3
2. Compression Process............................................3
2.1 Compression History........................................3
2.2 Compression Encoding Format................................3
2.3 Padding....................................................4
3. Decompression Process..........................................4
4. IPComp Association (IPCA) Parameters...........................4
4.1 ISAKMP Transform ID........................................5
4.2 ISAKMP Security Association Attributes.....................5
4.3 Manual configuration.......................................5
4.4 Minimum packet size threshold..............................5
4.5 Compressibility test.......................................5
5. Security Considerations........................................5
6. Acknowledgements...............................................5
7. References.....................................................6
8. Authors' Addresses.............................................7
1. Introduction...................................................2
1.1 General....................................................2
1.2 Background of LZS Compression..............................2
1.3 Licensing..................................................3
1.4 Specification of Requirements..............................3
2. Compression Process............................................3
2.1 Compression History........................................3
2.2 Compression Encoding Format................................3
2.3 Padding....................................................4
3. Decompression Process..........................................4
4. IPComp Association (IPCA) Parameters...........................4
4.1 ISAKMP Transform ID........................................5
4.2 ISAKMP Security Association Attributes.....................5
4.3 Manual configuration.......................................5
4.4 Minimum packet size threshold..............................5
4.5 Compressibility test.......................................5
5. Security Considerations........................................5
6. Acknowledgements...............................................5
7. References.....................................................6
8. Authors' Addresses.............................................7
9. Appendix: Compression Efficiency versus Datagram Size..........8
10. Full Copyright Statement......................................9
9. Appendix: Compression Efficiency versus Datagram Size..........8
10. Full Copyright Statement......................................9
This document specifies the application of LZS compression, a lossless compression algorithm, to IP datagram payloads. This document is to be used in conjunction with the IP Payload Compression Protocol [IPCOMP]. This specification assumes a thorough understanding of the IPComp protocol.
本文档指定了LZS压缩（一种无损压缩算法）在IP数据报有效负载中的应用。本文档将与IP有效负载压缩协议[IPCOMP]结合使用。本规范假设完全理解IPComp协议。
Starting with a sliding window compression history, similar to [LZ1], Hi/fn developed a new, enhanced compression algorithm identified as LZS. The LZS algorithm is a general purpose lossless compression algorithm for use with a wide variety of data types. Its encoding method is very efficient, providing compression for strings as short as two octets in length.
从滑动窗口压缩历史开始，类似于[LZ1]，Hi/fn开发了一种新的增强压缩算法，称为LZS。LZS算法是一种通用无损压缩算法，用于各种数据类型。它的编码方法非常有效，为长度短至两个八位字节的字符串提供压缩。
The LZS algorithm uses a sliding window of 2,048 bytes. During compression, redundant sequences of data are replaced with tokens that represent those sequences. During decompression, the original sequences are substituted for the tokens in such a way that the original data is exactly recovered. LZS differs from lossy compression algorithms, such as those often used for video compression, that do not exactly reproduce the original data.
LZS算法使用2048字节的滑动窗口。在压缩过程中，冗余的数据序列被替换为表示这些序列的标记。在解压期间，原始序列被替换为令牌，从而精确地恢复原始数据。LZS不同于有损压缩算法，例如通常用于视频压缩的有损压缩算法，后者不能精确地再现原始数据。
The details of LZS compression can be found in [ANSI94].
LZS压缩的详细信息可在[ANSI94]中找到。
The efficiency of the LZS algorithm depends on the degree of redundancy in the original data. A table of compression ratios for the [Calgary] Corpus file set is provided in the appendix in Section 7.
LZS算法的效率取决于原始数据中的冗余度。第7节附录中提供了[Calgary]语料库文件集的压缩比表。
Hi/fn, Inc. holds patents on the LZS algorithm. Licenses for a reference implementation are available for use in IPPCP, IPSec, TLS and PPP applications at no cost. Source and object licenses are available on a non-discriminatory basis. Hardware implementations are also available. For more information, contact Hi/fn at the address listed with the authors' addresses.
Hi/fn，Inc.拥有LZS算法的专利。参考实施的许可证可免费用于IPPCP、IPSec、TLS和PPP应用程序。源许可证和目标许可证是在非歧视的基础上提供的。硬件实现也可用。有关更多信息，请联系Hi/fn，地址与作者地址一起列出。
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 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
The sender MUST reset the compression history prior to processing each datagram's payload. This ensures that each datagram's payload can be decompressed independently of any other, as is needed when datagrams are received out of order.
在处理每个数据报的有效负载之前，发送方必须重置压缩历史记录。这确保了每个数据报的有效负载可以独立于任何其他数据报进行解压缩，这是在数据报接收顺序错误时所需要的。
The sender MUST flush the compressor each time it transmits a compressed datagram. Flushing means that all data going into the compressor is included in the output, i.e., no data is held back in the hope of achieving better compression. Flushing is necessary to prevent a datagram's data from spilling over into a later 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 [ANSI94], which is repeated here for informational purposes ONLY.
如果使用未压缩表单，则输出有效负载与输入有效负载相同，并且省略IPComp头。如果使用了压缩格式，则输出有效负载将以IPComp头作为前缀，并按照[ANSI94]中的定义进行编码，此处重复此操作仅供参考。
<Compressed Stream> := [<Compressed String>] <End Marker>
<Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte)
<Compressed Bytes> := <Offset> <Length>
<Compressed Stream> := [<Compressed String>] <End Marker>
<Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte)
<Compressed Bytes> := <Offset> <Length>
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset)
0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
<End Marker> := 110000000
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset)
0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
<End Marker> := 110000000
<b> := 1 | 0
<b> := 1 | 0
<Length> := 00 = 2 1111 0110 = 14 01 = 3 1111 0111 = 15 10 = 4 1111 1000 = 16 1100 = 5 1111 1001 = 17 1101 = 6 1111 1010 = 18 1110 = 7 1111 1011 = 19 1111 0000 = 8 1111 1100 = 20 1111 0001 = 9 1111 1101 = 21 1111 0010 = 10 1111 1110 = 22 1111 0011 = 11 1111 1111 0000 = 23 1111 0100 = 12 1111 1111 0001 = 24 1111 0101 = 13 ...
<Length>：=00=2 1111 0110=14 01=3 1111 0111=15 10=4 1111 1000=16 1100=5 1111 1001=17 1101=6 1111 1010=18 1110=7 1111 1011=19 1111 0000=8 1111 1100=20 1111 0001=9 1111 1101=21 1111 0010=10 1111 1111 1110=22 1111 0011=11 1111 1111 1111 0000=23 1111 0100=12 1111 1111 0001=24 1111 0101=13。。。
A datagram payload compressed using LZS always ends with the last compressed data byte (also known as the <end marker>), which is used to disambiguate padding. This allows trailing bits as well as bytes to be considered padding.
使用LZS压缩的数据报有效负载始终以最后一个压缩数据字节（也称为<end marker>）结束，该字节用于消除填充歧义。这允许将尾随位和字节视为填充。
The size of a compressed payload MUST be in whole octet units.
压缩有效负载的大小必须以整个八位字节为单位。
If the received datagram is compressed, the receiver MUST reset the decompression history prior to processing the datagram. This ensures that each datagram can be decompressed independently of any other, as is needed when datagrams are received out of order. Following the reset of the decompression history, the receiver decompresses the Payload Data field according to the encoding specified in section 3.2 of [ANSI94].
如果接收到的数据报被压缩，接收器必须在处理数据报之前重置解压缩历史。这确保了每个数据报可以独立于任何其他数据报进行解压缩，这是在数据报接收顺序错误时所需要的。重置解压历史后，接收器根据[ANSI94]第3.2节中规定的编码对有效载荷数据字段进行解压。
If the received datagram is not compressed, the receiver needs to perform no decompression processing and the Payload Data field of the datagram is ready for processing by the next protocol layer.
如果接收到的数据报未被压缩，则接收器不需要执行解压缩处理，并且数据报的有效载荷数据字段已准备好由下一协议层进行处理。
ISAKMP MAY be used to negotiate the use of the LZS compression method to establish an IPCA, as defined in [IPCOMP].
ISAKMP可用于协商LZS压缩方法的使用，以建立[IPCOMP]中定义的IPCA。
The LZS Transform ID as IPCOMP_LZS, as specified in The Internet IP Security Domain of Interpretation [SECDOI]. This value is used to negotiate the LZS compression algorithm under the ISAKMP protocol.
LZS转换ID为IPCOMP_LZS，如解释的Internet IP安全域[SECDOI]中所指定。该值用于协商ISAKMP协议下的LZS压缩算法。
There are no other parameters required for LZS compression negotiated under ISAKMP.
根据ISAKMP协商的LZS压缩不需要其他参数。
The CPI value IPCOMP_LZS is used for a manually configured IPComp Compression Associations.
CPI值IPCOMP_LZS用于手动配置的IPCOMP压缩关联。
As stated in [IPCOMP], small packets may not compress well. Informal tests using the LZS algorithm over the Calgary Corpus data set show that the average payload size that may produce expanded data is approximately 90 bytes. Thus implementations may not want to attempt to compress payloads smaller than 90 bytes.
如[IPCOMP]中所述，小数据包可能无法很好地压缩。使用LZS算法对卡尔加里语料库数据集进行的非正式测试表明，可能产生扩展数据的平均有效负载大小约为90字节。因此，实现可能不希望尝试压缩小于90字节的有效负载。
There is no adaptive algorithm embodied in the LZS algorithm, for compressibility testing, as referenced in [IPCOMP].
如[IPCOMP]中所述，LZS算法中没有用于压缩性测试的自适应算法。
This document does not add any further security considerations that [IPCOMP] and [Deutsch96] have already declared.
本文件未添加[IPCOMP]和[Deutsch96]已经声明的任何其他安全注意事项。
The LZS details presented here are similar to those in PPP LZS-DCP Compression Protocol (LZS-DCP), [RFC-1967].
此处提供的LZS详细信息与PPP LZS-DCP压缩协议（LZS-DCP）[RFC-1967]中的内容类似。
The author wishes to thank the participants of the IPPCP working group mailing list whose discussion is currently active and is working to generate the protocol specification for integrating compression with IP.
作者希望感谢IPPCP工作组邮件列表的参与者，他们的讨论目前正在进行中，并正在努力生成压缩与IP集成的协议规范。
[AH] Kent, S., and R., Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]Kent，S.，和R.，Atkinson，“IP认证头”，RFC 2402，1998年11月。
[ANSI94] American National Standards Institute, Inc., "Data Compression Method for Information Systems," ANSI X3.241- 1994, August 1994.
[ANSI94]美国国家标准协会，“信息系统的数据压缩方法”，ANSI X3.241-1994，1994年8月。
[Calgary] Text Compression Corpus, University of Calgary, available at ftp://ftp.cpsc.ucalgary.ca/pub/projects/text. compression.corpus.
[卡尔加里]卡尔加里大学文本压缩语料库ftp://ftp.cpsc.ucalgary.ca/pub/projects/text. 压缩。语料库。
[IPCOMP] Shacham, A., "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.
[IPCOMP]Shacham，A.，“IP有效载荷压缩协议（IPCOMP）”，RFC 23931998年12月。
[LZ1] Lempel, A., and Ziv, J., "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, May 1977.
[LZ1]Lempel，A.，和Ziv，J.，“顺序数据压缩的通用算法”，IEEE信息论学报，第IT-23卷，第3期，1977年5月。
[RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC-1962]兰德博士，“PPP压缩控制协议（CCP）”，RFC 1962，1996年6月。
[RFC-1967] Schneider, K., and R. Friend, "PPP LZS-DCP Compression Protocol (LZS-DCP)", RFC 1967, August 1996.
[RFC-1967]Schneider，K.和R.Friend，“PPP LZS-DCP压缩协议（LZS-DCP）”，RFC 1967，1996年8月。
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC-2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[SECDOI] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[SECDOI]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
Robert Friend Hi/fn Inc. 5973 Avenida Encinas Suite 110 Carlsbad, CA 92008
Robert Friend Hi/fn Inc.加利福尼亚州卡尔斯巴德大道恩西纳斯110号5973号套房，邮编92008
EMail: rfriend@hifn.com
EMail: rfriend@hifn.com
Robert Monsour Hi/fn Inc. 2105 Hamilton Avenue Suite 230 San Jose, CA 95125
Robert Monsour Hi/fn Inc.加利福尼亚州圣何塞市汉密尔顿大道2105号230室95125
EMail: rmonsour@hifn.com
EMail: rmonsour@hifn.com
The following table offers some guidance on the compression efficiency that can be achieved as a function of datagram size. Each entry in the table shows the compression ratio that was achieved when LZS was applied to a test file using datagrams of a specified size.
下表提供了一些关于压缩效率的指南，这些效率可以作为数据报大小的函数来实现。表中的每个条目都显示了使用指定大小的数据报将LZS应用于测试文件时达到的压缩比。
The test file was the University of Calgary Text Compression Corpus [Calgary]. The Calgary Corpus consists of 18 files with a total size (all files) of 3.278MB.
测试文件是卡尔加里大学文本压缩语料库〔卡尔加里〕。卡尔加里语料库由18个文件组成，总大小（所有文件）为3.278MB。
Datagram size,|
bytes | 64 128 256 512 1024 2048 4096 8192 16384
--------------|----------------------------------------------------
Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14
ratio |
Datagram size,|
bytes | 64 128 256 512 1024 2048 4096 8192 16384
--------------|----------------------------------------------------
Compression |1.18 1.28 1.43 1.58 1.74 1.91 2.04 2.11 2.14
ratio |
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。