ネットワークワーキンググループ
Request for Comments: 3051
分類: 情報提供
J. Heath
J. Border
Hughes Network Systems
2001 年 1 月

 

ITU-T V.44 パケット方式を用いた IP ペイロード圧縮
(IP Payload Compression Using ITU-T V.44 Packet Method)

このメモの位置付け 
このメモは、インターネットコミュニティに対して情報を提供するものである。
このメモは、何らインターネットの標準を規定するものではない。
このメモの配布に制限はない。
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
要旨 
この文書では、国際電気通信連合(ITU-T)V.44 勧告に記述されたデータ圧縮アルゴリズムに基づいた圧縮方式について記述する。
V.44 勧告はモデム標準であるが、勧告の付録 B の B.1 節では、パケットネットワークへの V.44 の実装(V.44 パケット方式)について記述している。
この文書では、インターネットプロトコル(IP)ペイロード圧縮プロトコル(RFC 2393)への V.44 パケット方式の適用について定義する。
RFC 2393 では、IP データグラムのペイロード部分に無損失圧縮を適用する方法を定義している。

V.44 パケット方式は、LZJH データ圧縮アルゴリズムに基づいている。
この文書の残りの部分では、V.44 パケット方式という用語と LZJH という用語は同意語である。

目次 
1. はじめに
1.1 一般
1.2 LZJH データ圧縮の背景
1.3 知的財産権
1.4 要求仕様
2. 圧縮処理
2.1 エンコーダ辞書
2.2 エンコーダ出力
2.3 パディング
3. 復元処理
3.1 圧縮されたデータグラム
3.2 オリジナルの未圧縮データグラム
4. IPComp アソシエーション(IPCA)パラメータ
4.1 トランスフォーム ID
4.2 セキュリティアソシエーション属性
4.3 手動設定
4.4 最小パケットサイズスレッショルド
4.5 圧縮可能性試験

5. セキュリティに関する考慮事項

6. IANA に関する考慮事項

7. 謝辞

8. 参考文献

9. 著者の連絡先

10. 著作権表示全文

1. はじめに 
1.1 一般 
この文書では、無損失データ圧縮アルゴリズムである LZJH データ圧縮の IP データグラムペイロードへの適用について定義する。
LZJH データ圧縮は、IP ペイロード圧縮プロトコル(IPComp)[RFC2393] と共に使用することができる。
この文書は、読者が IPComp プロトコルについて理解しているという仮定で書かれている。
1.2 LZJH データ圧縮の背景 
LZJH は、[LZ78] に記述されているアルゴリズムに似ているが、[LZ77] に記述されているアルゴリズムにも似ている面を持っている。
そのため、[LZ78] の実行速度および少ないメモリ要件において、[LZ77] よりよい圧縮比を提供する。
LZJH は、もともとは衛星分野において、IP データグラムを独立して圧縮するために開発されたものであり、IPComp への適用には理想的である。
LZJH アルゴリズムは、モデム環境における連続的なデータの流れを圧縮するために改良され、この改良版が V.44 勧告の基礎となっている。 LZJH は、適応性があり、一般的な目的で利用可能な、無損失圧縮アルゴリズムである。
LZJH は、ITU-T により、様々な種類のデータ(特に Web の HTML)における性能や、使用されている MIP およびメモリ毎の圧縮比特性に基づいて(他の候補アルゴリズムと比較して)V.44 勧告の基礎として選択された。
そのエンコーダは非常に効率的で、2 キャラクタの文字列がデータの中で 2 回目に出現した場合に、3 ビットにエンコードすることが可能である。

V.42bis のような典型的な [LZ78] 圧縮アルゴリズムは、辞書を構築するのに非常に時間がかかり、IP データグラムを個別に圧縮する場合に圧縮比が悪くなるため、IPComp への適用にはふさわしくない。
さらに、それは、実行時間に悪影響を及ぼすデータグラム間における [LZ78] 辞書のリセットを何回も必要とする。

同様に、典型的な [LZ77] 圧縮アルゴリズムは実行時間がかかるため、IPComp への適用は難しい。
連続したデータを圧縮する場合に実行時間を減らすことを可能とするハッシュテーブルは、各データグラム間で初期状態にリセットしなければならないため、IPComp への適用において実行時間の悪化を引き起こす可能性がある。

LZJH は、パケットデータをエンコードおよびデコードする際の実行時間が少ないだけでなく、IP データグラム間の辞書のリセットも大したことがない。
デコーダは、ひと握りの変数の初期化のみを必要とする一方、エンコーダは、256 の単語配列とひと握りの変数の初期化のみを必要とする。

LZJH アルゴリズムは、IPComp への適用では、1525 エントリの辞書を使用し、合計で 16K の辞書メモリしか使用しない。
エンコード処理では、一致しない文字は序数として符号化され、一致した冗長な文字列は、冗長な文字列を表わすコードワードあるいは拡張文字列長として符号化される。
デコード処理では、序数、コードワードおよび拡張文字列長は、オリジナルのデータグラムペイロードを正確に再生できるように解釈される。

LZJH データ圧縮の詳細は、[V44] で見つけることができる。

1.3 知的財産権 
IETF は、この文書に含まれている仕様のいくつかあるいはすべてに関して要求される知的財産権について通知を受けている。
詳細については、要求された権利のオンラインリストを調べること。
1.4 要求仕様 
この文書における "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" というキーワードは、[RFC-2119] に記述されているように解釈されるものとする。
2. 圧縮処理 
データグラムの圧縮は、エンコーダと呼ばれる関数によって行われる。
2.1 エンコーダ辞書 
[V44] の 7.5.1 節において指定されているように、送信者は、各データグラムのペイロード処理の前にエンコーダ辞書をリセットしなければならない (MUST)
これは、他のデータグラムと独立して正確に各データグラムのペイロードを復元することができることを保証するものであり、データグラムが破棄されたり、異なる順番で受信される環境の中で必要となるものである。

送信者は、圧縮されたデータグラムを 1 つのまとまりとして送信できるように、データグラムの最後のバイトがエンコーダに渡された後に、まだ処理されていないエンコーダデータをフラッシュしなければならない (MUST)
フラッシュは、すべてのデータが処理され、出力に含まれていること、つまり、圧縮されたデータグラムが完全であり、現在のデータグラムからのデータは、次のデータグラムでは処理されないことを保証する。

2.2 エンコーダ出力 
ペイロード圧縮アルゴリズムへの入力は、IP データグラムのペイロードとなる。
アルゴリズムの出力は新しい(そして、できればより小さい)ペイロードとなる。
出力ペイロードには、圧縮された形式か圧縮されていない形式のどちらかで入力ペイロードのデータが含まれる。
入力ペイロードおよび出力ペイロードは、それぞれ整数バイト長である。

圧縮されていない形式が使用される場合は、出力ペイロードは入力ペイロードと同一であり、IPComp ヘッダは省略される。
圧縮された形式が使用される場合は、出力ペイロードの前に IPComp ヘッダが付与され、[V44] の 6.3 節において定義されているように符号化される。

2.3 パディング 
LZJH を使用して圧縮されたデータグラムペイロードは、常に、最後の 1, 2 個の圧縮されたデータバイト中に含まれる FLUSH コードワードで終了する。
FLUSH コードワードは、圧縮された最後から 2 番目のデータバイトから始まり、圧縮された最後のデータバイトで終わっても良いし、すべてが最後のデータバイト内に存在しても良い。
FLUSH コードワードは、圧縮されたデータの終了を示し、かつ、圧縮されたデータとパディングを区別するために使用される。
圧縮されたペイロード内の FLUSH コードワードの後のどのようなビットおよびバイトも、パディングと見なされる。

圧縮されたペイロードのサイズは、ちょうどオクテット単位でなければならない (MUST)

3. 復元処理 
データグラムの復元は、デコーダと呼ばれる関数によって行われる。
3.1 圧縮されたデータグラム 
受信したデータグラムが圧縮されている場合は、受信者は、データグラムを処理する前にデコーダ辞書をリセットしなければならない (MUST)
これは、データグラムが破棄されたり、異なる順番で受信された際に、他のデータグラムと独立して各データグラムをデコードできることを保証する。
[V44] の 7.5.2 節において指定されているように、初期状態のデコーダ辞書から始めて、受信者は [V44] の 6.4 節において指定されている手続きに従ってデータグラムのペイロードデータフィールドをデコードする。
3.2 オリジナルの未圧縮データグラム 
受信したデータグラムが圧縮されていない場合は、受信者は圧縮の復元を行わずに、次のプロトコル層に変更されていない状態のデータグラムのペイロードデータフィールドを渡す。
4. IPComp アソシエーション(IPCA)パラメータ 
[RFC2393] で定義されているように、IPCA を確立するために、IKE [RFC2409] を使用して LZJH 圧縮アルゴリズムの使用を折衝しても良い (MAY)
4.1 トランスフォーム ID 
LZJH トランスフォーム ID の値は、IPCOMP_LZJH である。
この値は、IKE を利用して LZJH データ圧縮アルゴリズムの使用を折衝するために使用される。
4.2 セキュリティアソシエーション属性 
IKE を利用して LZJH 圧縮アルゴリズムの折衝を行うために必要となる他のパラメータは存在しない。
4.3 手動設定 
CPI 値 IPCOMP_LZJH は、手動で設定された IPComp 圧縮アソシエーションのために使用される。
4.4 最小パケットサイズスレッショルド 
[RFC2393] で述べられているように、小さいパケットは効率よく圧縮できない可能性がある。
インターネットウェブページおよび電子メールファイルにおいて LZJH アルゴリズムを使用した非公式のテストでは、典型的にデータが増加する平均ペイロードサイズは、およそ 50 バイトであることを示している。
したがって、実装は、およそ 50 バイト以下のペイロードを圧縮することを試みない方が良いかもしれない。
4.5 圧縮可能性試験 
LZJH アルゴリズムは、[V44] に記述されているように、[RFC2393] で参照される適応性のある圧縮可能性試験を組込むように容易に修正可能である。
[V44] の付録 B では、LZJH にそのような試験を追加するための仕組みを定義している。
5. セキュリティに関する考慮事項 
この文書では、[RFC2393] において述べられているセキュリティに関する考慮事項に対して、さらなる事項を追加しない。
6. IANA に関する考慮事項 
この文書では、新たな名前空間を導入しない。
IPCOMP_LZJH の値は、[RFC2407] に定義された IPsec IPCOMP トランスフォーム ID の空間から割り当てられる。
IANA は、このために値 4 を割り当てている。
7. 謝辞 
この文書は、[RFC2395] に基づいて作られている。
8. 参考文献 
[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.

[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.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2393] Shacham, A., "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998.

[RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998.

[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November, 1998.

[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998.

[V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44 "Data Compression Procedures", November 2000.

9. 著者の連絡先 
Jeff Heath
Hughes Network Systems
10450 Pacific Center Ct.
San Diego, CA 92121

Phone: 858-452-4826
Fax: 858-597-8979
EMail: jheath@hns.com
 

John Border
Hughes Network Systems
11717 Exploration Lane
Germantown, MD 20876

Phone: 301-601-4099
Fax: 301-601-4275
EMail: border@hns.com
 

翻訳者

東京都中央区新川1-21-2 茅場町タワー
株式会社 NTTデータ
技術開発本部
馬場 達也

EMail: babatt@nttdata.co.jp

10. 著作権表示全文 
Copyright (C) The Internet Society (2001). All Rights Reserved.

本文書とその翻訳は、複製および他に提供することができる。
また、この文書に論評や説明を加えたり、その実装を補助するものは、上記の著作権表示およびこの節を付加していれば、全体あるいは一部であっても一切の制約を課されることなく作成、複製、発表、配布できる。
ただし、この文書自体に対して、著作権表示やインターネットソサエティもしくは他のインターネット関連団体への参照を取り除くなどの変更を加えてはならない。
インターネット標準化過程で定義されている著作権のための手続きに従って、インターネット標準を開発するために必要な場合や、RFC を英語以外の言語に翻訳する必要がある場合はそのかぎりでない。

上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはない。

本文書とここに含まれた情報は「無保証」で提供され、インターネットソサエティおよび IETF はすべての保証を明示的にも暗黙的にもおこなわない。
その中には、この情報がいかなる権利も侵害していないという保証や、商用利用および特定目的における適合性への保証が含まれる。

謝辞 
現在、RFC エディタの機能に対する資金は、インターネットソサエティによって提供されている。