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
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の実装を記述する。この文書は、インターネットプロトコル（IP）ペイロード圧縮プロトコル（RFC 2393）にV.44パケット方式のアプリケーションを定義します。 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
LZJHはまた、[LZ77]に記載されたアルゴリズムに類似している側面を有しているが[LZ78]で説明したアルゴリズムと同様です。このように、[LZ77]よりも優れている圧縮率と実行速度と[LZ78]の低いメモリ要件を提供します。もともと独立した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.
勧告V.44。 LZJHは、適応、汎用、無損失データ圧縮アルゴリズムです。これは、特にウェブのHTMLの、データタイプの様々な横切るその性能に基づいて、推奨V.44のための基礎として、ITU-Tによって選択され、その圧縮率特性に基づいて、利用MIP及びメモリあたりた（他に比べて候補アルゴリズム）。そのエンコーダは、非常に効率的であり、3ビット列がデータに遭遇する第二時間を有する2つの文字列をコードすることができます。
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.
それは独立して圧縮されるIPデータグラムに乏しい圧縮比をもたらす、その辞書を構築するために時間がかかりすぎるので、そのようなV.42bisのような典型的な[LZ78]圧縮アルゴリズムは、のIPCompアプリケーションには適していません。また、悪の実行時間に影響を与え、データグラムの間で[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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ヘッダは省略されています。圧縮形式が使用される場合、[V44]の節6.3において定義されるように、出力ペイロードはIPCompヘッダと付加し、符号化されます。
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を使用して圧縮データグラムペイロードは、常に最後の一つまたは二つの圧縮データのバイト数FLUSHコードワードで終わります。 FLUSHコードワードは、最後の圧縮データのバイトに第二に始まり、最後の圧縮されたデータバイトで終わるか、完全に最後のデータバイト内にあってもよいです。 FLUSHコードワードは、圧縮されたデータの終了を知らせるパディングから圧縮データを区別するために使用されます。圧縮されたペイロード内のFLUSHコードワードを越えて任意のビット又はバイトは、パディングとみなされるべきです。
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]で定義されるように、IPCAを確立するLZJH圧縮アルゴリズムの使用を交渉するために使用されるかもしれません。
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.
[RFC2393]で参照としてLZJHアルゴリズムは、[V44]に記載されているように、容易に適応圧縮試験を組み込むように修正されます。 [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.、およびジブ、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.、およびジブ、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]フレンド、R.とR. Monsour、 "IPペイロード圧縮使い方LZS"、RFC 2395、1998年12月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November, 1998.
[RFC2407]パイパー、D.、RFC 2407、1998年11月、 "ISAKMPのための解釈のインターネットIPセキュリティー・ドメイン"。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換"、RFC 2409、1998年11月。
[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44 "Data Compression Procedures", November 2000.
[V44] ITU電気通信標準化部門（ITU-T）勧告V.44 "データ圧縮手順"、2000年11月。
Jeff Heath Hughes Network Systems 10450 Pacific Center Ct. San Diego, CA 92121
ジェフ・ヒース・ヒューズネットワークシステム10450パシフィックセンターのCt。サンディエゴ、CA 92121
Phone: 858-452-4826 Fax: 858-597-8979 EMail: jheath@hns.com
電話：858-452-4826ファックス：858-597-8979 Eメール：jheath@hns.com
John Border Hughes Network Systems 11717 Exploration Lane Germantown, MD 20876
ジョン・ボーダー・ヒューズネットワークシステムズ11717探査レーンジャーマンタウン、MD 20876
Phone: 301-601-4099 Fax: 301-601-4275 EMail: border@hns.com
電話：301-601-4099ファックス：301-601-4275 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。