[要約] RFC 2395は、LZSを使用したIPペイロードの圧縮に関する規格です。その目的は、ネットワークトラフィックの効率を向上させ、帯域幅の節約を実現することです。
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.
Copyright（C）The Internet Society（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圧縮アルゴリズムに基づく圧縮方法について説明します。このドキュメントは、IPペイロード圧縮プロトコル[IPCOMP]へのLZSアルゴリズムの適用を定義します。 [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
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アルゴリズムは、多種多様なデータ型で使用するための汎用の可逆圧縮アルゴリズムです。そのエンコード方式は非常に効率的で、長さが2オクテットという短いストリングの圧縮を提供します。
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アルゴリズムは、2,048バイトのスライディングウィンドウを使用します。圧縮中に、データの冗長なシーケンスは、それらのシーケンスを表すトークンで置き換えられます。解凍中、元のデータが正確に復元されるように、元のシーケンスがトークンに置き換えられます。 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アルゴリズムの効率は、元のデータの冗長度に依存します。 [Calgary] Corpusファイルセットの圧縮率の表は、セクション7の付録に記載されています。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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>
<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
<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 ...
<長さ>：= 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 ...
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を使用して圧縮されたデータグラムペイロードは常に、最後の圧縮データバイト（<エンドマーカー>とも呼ばれます）で終わります。これは、埋め込みを明確にするために使用されます。これにより、後続ビットとバイトをパディングと見なすことができます。
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は、[IPCOMP]で定義されているように、IPCAを確立するためのLZS圧縮方法の使用をネゴシエートするために使用される場合があります。
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.
解釈のインターネットIPセキュリティドメイン[SECDOI]で指定されているIPCOMP_LZSとしてのLZS変換ID。この値は、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.
著者は、現在議論が活発であり、IPと圧縮を統合するためのプロトコル仕様を生成するために取り組んでいるIPPCPワーキンググループメーリングリストの参加者に感謝します。
[AH] Kent, S., and R., Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[AH]ケント、S、およびR、アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[ANSI94] American National Standards Institute, Inc., "Data Compression Method for Information Systems," ANSI X3.241- 1994, August 1994.
[ANSI94] American National Standards Institute、Inc。、「Data Compression Method for Information Systems」、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 Payload Compression Protocol（IPComp）」、RFC 2393、1998年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 Transactions On Information Theory、Vol。 IT-23、No。3、1977年5月。
[RFC-1962] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[RFC-1962]ランド、D。、「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 Compression Protocol（LZS-DCP）」、RFC 1967、1996年8月。
[RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC-2003]パーキンス、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. 5973 Avenida Encinas Suite 110 Carlsbad、CA 92008
EMail: rfriend@hifn.com
Robert Monsour Hi/fn Inc. 2105 Hamilton Avenue Suite 230 San Jose, CA 95125
Robert Monsour Hi / fn Inc. 2105 Hamilton Avenue Suite 230 San Jose、CA 95125
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 |
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。