[要約] 要約：RFC 3051は、ITU-T V.44パケット方式を使用したIPペイロードの圧縮に関する規格です。 目的：この規格の目的は、IPネットワーク上でのデータ転送の効率を向上させるために、ITU-T V.44パケット方式を使用してIPペイロードを圧縮する方法を提供することです。
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.
Copyright（c）The Internet Society（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
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.
このドキュメントは、IPデータグラムのペイロードへのロスレスデータ圧縮アルゴリズムであるLZJHデータ圧縮の適用を指定します。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 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.
LZJHは[LZ78]で説明されているアルゴリズムに似ていますが、[LZ77]で説明されているアルゴリズムに類似した側面もあります。そのため、[LZ77]よりも優れた圧縮比を使用して、[LZ78]の実行速度と低いメモリ要件を提供します。もともとは、IPデータグラムを独立して圧縮するために衛星業界向けに開発されましたが、IPCompアプリケーションに最適です。LZJHアルゴリズムは、モデム環境の連続データストリームを圧縮するために変更され、この変更されたバージョンは推奨V.44の基礎です。LZJHは、適応的、汎用、損失のないデータ圧縮アルゴリズムです。ITU-Tによって選択され、さまざまなデータ型、特にWeb HTMLのパフォーマンスに基づいて、MIPごとに使用されたMIPおよびメモリあたりの圧縮比特性に基づいて、推奨v.44の基礎として選択されました（他と比較して候補アルゴリズム）。そのエンコーダーは非常に効率的で、2回目の文字列がデータで遭遇する2回目の2文字の文字列を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.
V.42BISなどの典型的な[LZ78]圧縮アルゴリズムは、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アプリケーションに合計16kの辞書メモリの1525エントリの辞書を使用しています。エンコードプロセスでは、未満の文字が序数としてエンコードされ、一致した文字の文字列は、冗長文字列を表すコードワードまたは文字列拡張長としてエンコードされます。デコードプロセス中に、通常のデータグラムペイロードを正確に再現するために、縦座標、コードワード、および文字列拡張長の長さが解釈されます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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 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.
LZJHを使用して圧縮されたデータグラムのペイロードは、常に最後の1つまたは2つの圧縮データバイトでフラッシュコードワードで終わります。フラッシュコードワードは、2番目から最後の圧縮データバイトから始まり、最後の圧縮データバイトで終了するか、完全に最後のデータバイト内にある場合があります。フラッシュコードワードは、圧縮データの終わりを信号にし、圧縮データをパディングから区別するために使用されます。圧縮されたペイロード内のフラッシュコードワードを越えたビットまたはバイトは、パディングと見なされます。
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]を使用して、[RFC2393]で定義されているように、LZJH圧縮アルゴリズムの使用を交渉してIPCAを確立することができます。
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の値はIPComp_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]に記載されているように、小さなパケットはうまく圧縮されない場合があります。インターネットWebページと電子メールファイルで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情報に関するトランザクション、Vol。IT-23、No。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トランザクションに関する情報理論、Vol。IT-24、No。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 2393、1998年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、「The Internet Key Exchange」、RFC 2409、1998年11月。
[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44 "Data Compression Procedures", November 2000.
[V44] ITU Telecommunication Standardizationセクター（ITU-T）推奨V.44「データ圧縮手順」、2000年11月。
Jeff Heath Hughes Network Systems 10450 Pacific Center Ct. San Diego, CA 92121
Jeff Heath Hughes Network Systems 10450 Pacific Center Ct。サンディエゴ、CA 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
John Border Hughes Network Systems 11717 Exploration Lane Germantown、MD 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.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。