RFC 3096 - Requirements for robust IP/UDP/RTP header compression 日本語訳

URL : https://tools.ietf.org/html/rfc3096
タイトル : RFC 3096 - 堅牢なIP / UDP / RTPヘッダー圧縮のための要件
翻訳編集 : 自動生成

Network Working Group                               M. Degermark, Editor
Request for Comments: 3096                         University of Arizona
Category: Informational                                        July 2001

         Requirements for robust IP/UDP/RTP header compression

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.

このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2001）。全著作権所有。

Abstract

抽象

This document contains requirements for robust IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression) WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP.

この文書では、ROHC（ロバストヘッダ圧縮）WGによって開発される堅牢なIP / UDP / RTP（インターネット・プロトコル/ユーザ・データグラム・プロトコル/リアルタイムトランスポートプロトコル）ヘッダー圧縮のための要件が含まれています。これは、ROHC憲章、WGでの議論、3GPP文書「3GPP TR 23.922」、1999年10月のバージョン1.0.0と同様に、3G.IP.からの貢献に基づいています

1. Introduction

1. はじめに

The goal of the ROHC WG is to develop header compression schemes that perform well over links with high error rates and long link round trip times. The schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes should also be applicable to other future link technologies with high loss and long round trip times.

ROHC WGの目標は、高いエラー率と長いリンク往復時間とのリンクの上にも行うヘッダ圧縮スキームを開発することです。スキームは、WCDMA、EDGE、およびCDMA-2000などの技術を使用して構築された携帯リンクのためによく実行する必要があります。しかし、方式も高い損失と長い往復時間とその他の将来のリンク技術に適用可能であるべきです。

The following requirements have, more or less arbitrarily, been divided into three groups. The first group deals with requirements concerning the impact of an header compression scheme on the rest of the Internet infrastructure. The second group concerns what kind of headers that must be compressed efficiently. The final group concerns efficiency requirements and requirements which stem from the properties of the anticipated link technologies.

次の要件は、多かれ少なかれ任意に、3つのグループに分けられています。最初のグループは、インターネットインフラストラクチャの残りの部分にヘッダ圧縮スキームの影響に関する要件を扱います。第2のグループは効率的に圧縮しなければならないヘッダの種類に関係します。最後のグループは、予想されるリンク技術の性質から生じる効率要件と要件に関するものです。

2. Header compression requirements

2.ヘッダ圧縮の要件

Several current standardization efforts in the cellular arena aim at supporting voice over IP and other real-time services over IP, e.g., GERAN (specified by the ETSI SMG2 standards group), and UTRAN (specified by the 3GPP standards organization). It is critical for these standardization efforts that a suitable header compression scheme is developed before completion of the Release 2000 standards. Therefore, it is imperative that the ROHC WG keeps its schedule.

IP上でIPおよび他のリアルタイムサービスを介して音声をサポートするのセルラーアリーナ目的のいくつかの現在の標準化活動は、例えば、GERAN（ETSI SMG2規格グループで指定）、およびUTRAN（3GPPの標準化団体で指定します）。これは、適切なヘッダ圧縮方式はリリース2000規格の完了前に開発されたこれらの標準化の努力のために重要です。したがって、ROHC WGは、そのスケジュールを保つことが不可欠です。

2.1 Impact on Internet infrastructure

インターネットインフラストラクチャ上の2.1インパクト

1. Transparency: When a header is compressed and then decompressed, the resulting header must be semantically identical to the original header. If this cannot be achieved, the packet containing the erroneous header must be discarded.

1.透明性：ヘッダを圧縮し、その後解凍された場合、結果として得られるヘッダはオリジナルヘッダと意味的に同じでなければなりません。これが達成できない場合、誤ったヘッダを含むパケットを廃棄しなければなりません。

Justification: The header compression process must not produce headers that might cause problems for any current or future part of the Internet infrastructure.

正当化：ヘッダ圧縮プロセスは、インターネットインフラの現在または将来の一部のために問題を引き起こす可能性があるヘッダを生成してはなりません。

2. Ubiquity: Must not require modifications to existing IP (v4 or v6), UDP, or RTP implementations.

2.ユビキタス：既存のIP（V4またはV6）、UDP、またはRTP実装への変更を要求してはなりません。

Justification: Ease of deployment.

正当化：展開のしやすさ。

Note: The ROHC WG may recommend changes that would increase the compression efficiency for the RTP streams emitted by implementations. However, ROHC cannot rely on such recommendations being followed.

注：ROHC WGは、実装によって放出されたRTPストリームの圧縮効率を増加させる変更を勧告することができます。しかし、ROHCは守られて、このような勧告に頼ることはできません。

2.2 Supported headers and kinds of RTP streams

RTPストリームの2.2サポートされるヘッダおよび種類

1. IPv4 and IPv6: Must support both IPv4 and IPv6.

1. IPv4とIPv6は：IPv4とIPv6の両方をサポートしている必要があります。

Justification: IPv4 and IPv6 will both be around during the foreseeable future.

正当化：IPv4とIPv6の両方が当面の間、前後になるだろう。

2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} should be compressed efficiently. For IPv4 these include headers of tunneled packets. For IPv6 these include headers containing the Routing Header, the Binding Update Destination Option, and the Home Address option.

2.モバイルIP：モバイルIPによって使用されるヘッダーの種類{V4が、V6}効率的に圧縮されなければなりません。 IPv4の場合、これらは、トンネルパケットのヘッダが含まれています。 IPv6の場合、これらのルーティングヘッダ、バインディング更新先オプション、およびホームアドレスオプションを含むヘッダが含まれます。

Justification: It is very likely that Mobile IP will be used by cellular devices.

正当化：それは、モバイルIPは、携帯機器で使用される可能性が非常に高いです。

3. Genericity: Must support compression of headers of arbitrary RTP streams.

3.ジェネリック：任意のRTPストリームのヘッダの圧縮をサポートしている必要があります。

Justification: There must be a generic scheme which can compress reasonably well for any payload type and traffic pattern. This does not preclude optimizations for certain media types where the traffic pattern is known, e.g., for low-bandwidth voice and low-bandwidth video.

正当化：任意のペイロードタイプとトラフィックパターンのために合理的に圧縮することができ、一般的なスキームが存在する必要があります。これは、低帯域幅の音声と低帯域幅のビデオのために、例えば、トラフィックパターンが知られている特定のメディアタイプのための最適化を妨げるものではありません。

Note: This applies to the RTP stream before as well as after it has passed through an internet.

注意：これは、前と同様に、それはインターネットを通過した後にRTPストリームに適用されます。

4. IPSEC: ROHC should be able to compress headers containing IPSEC subheaders.

4. IPSEC：ROHCはIPSECのサブヘッダーを含むヘッダを圧縮することができるはずです。

Note: It is of course not possible to compress the encrypted part of an ESP header, nor the cryptographic data in an AH header.

注意：ESPヘッダの暗号化された部分、またAHヘッダ内の暗号化データを圧縮することはもちろんできません。

2.3 Efficiency

2.3効率性

1. Performance/Spectral Efficiency: Must provide low relative overhead under expected operating conditions; compression efficiency should be better than for RFC 2508 under equivalent operating conditions. The error rate should only marginally increase the overhead under expected operating conditions.

1.パフォーマンス/スペクトル効率：予想される動作条件の下で、低い相対的オーバーヘッドを提供しなければなりません。圧縮効率は同等の動作条件の下で、RFC 2508のためのより良いはずです。エラー率はわずかに予想される動作条件の下でオーバーヘッドを増やす必要があります。

Justification: Spectrum efficiency is a primary goal. RFC 2508 does not perform well enough.

正当化：スペクトル効率が第一の目標です。 RFC 2508には、十分に実行されません。

Note: The relative overhead is the average header overhead relative to the payload. Any auxiliary (e.g., control or feedback) channels used by the scheme should be taken into account when calculating the header overhead.

注：相対オーバーヘッドはペイロードに対する平均ヘッダーオーバーヘッドです。ヘッダーオーバーヘッドを計算するときに任意の補助（例えば、制御またはフィードバック）方式で使用されるチャネルは考慮されるべきです。

2. Error propagation: Error propagation due to header compression should be kept at an absolute minimum. Error propagation is defined as the loss or damage of headers subsequent to headers lost or damaged by the link, even if those subsequent headers are not lost or damaged.

2.エラー伝播：圧縮ヘッダによるエラー伝播が最小限に保たれるべきです。エラー伝播は、それらのその後のヘッダが紛失または破損していない場合でも、リンクによって紛失または破損ヘッダに後続のヘッダーの滅失又は損傷として定義されます。

Justification: Error propagation reduces spectral efficiency and reduces quality. CRTP suffers severely from error propagation.

正当化：エラー伝播は、スペクトル効率を低減し、品質を低減します。 CRTPは、エラー伝播からひどく苦しんでいます。

Note: There are at least two kinds of error propagation; loss propagation, where an error causes subsequent headers to be lost, and damage propagation, where an error causes subsequent headers to be damaged.

注：エラーの伝播の少なくとも2種類があります。エラーは、後続のヘッダが失われ損失伝播、およびエラーは、後続のヘッダが破損する原因となる損傷の伝播、。

3a. Handover loss events: There must be a way to run ROHC where loss events of length 150 milliseconds are handled efficiently and where loss or damage propagation is not introduced by ROHC during such events.

図3（a）。ハンドオーバ損失イベント：長さ150ミリ秒の損失事象が効率的に処理され、紛失や破損の伝播は、このようなイベント中にROHCによって導入されていないところROHCを実行するための方法があるに違いありません

Justification: Such loss events can be introduced by handover operations in a (radio) network between compressor and decompressor. Handover operations can be frequent in cellular systems. Failure to handle handover well can adversely impact spectrum efficiency and quality.

正当化：このような損失事象は、コンプレッサとデコンプレッサとの間の（無線）ネットワークにおいてハンドオーバ動作により導入することができます。ハンドオーバ動作は、セルラーシステムに頻繁にすることができます。うまくハンドオーバを処理するために失敗すると、悪影響スペクトル効率と品質に影響を与えることができます。

3b. Handover context recreation: There must be a way to run ROHC that deals well with events where the route of an RTP conversation changes such that either the compressor or the decompressor of the conversation is relocated to another node, where the context needs to be recreated. ROHC must not introduce erroneous headers during such events, and should not introduce packet loss during such events.

図3b。ハンドオーバコンテキストレクリエーション：RTPの会話のルートは、コンプレッサや会話の解凍器のいずれかがコンテキストを再作成する必要が別のノードに再配置されるように変更したイベントとよく扱うROHCを実行するための方法があるに違いありません。 ROHCは、このようなイベント中に誤ったヘッダを導入してはならない、とこのようなイベントの際にパケットロスを導入してはなりません。

Justification: Such events can be frequent in cellular systems where the compressor/decompressor on the network side is close to the radio base stations.

正当化：このようなイベントは、ネットワーク側のコンプレッサ/デコンプレッサは、無線基地局の近くに位置していセルラシステムで頻繁にすることができます。

Note: In order to aid developers of context recreation schemes where context is transfered to the new node, the specification shall outline what parts of the context is to be transfered, as well as conditions for its use. Procedures for context recreation (and discard) without such context transfer will also be provided.

注意：コンテキストが新しいノードに転送されるコンテキストレクリエーションスキームの開発者を支援するために、仕様は、コンテキストの部分は、その使用のための条件としてだけでなく、転送されるべきものを概説するものとします。そのようなコンテキスト転送せずにコンテキストレクリエーション（および破棄）する手順も提供します。

4. Link delay: Must operate under all expected link delay conditions.

4.リンクの遅延：すべての予想リンク遅延条件の下で動作しなければなりません。

5. Processing delay: The scheme must not contribute significantly to system delay budget.

5.処理遅延：スキームは、システムの遅延バジェットに大きく寄与していなければなりません。

6. Multiple links: The scheme must perform well when there are two or more cellular links in the end-to-end path.

前記複数のリンク：エンドツーエンドパスにおいて2つの以上の細胞のリンクがある場合方式がうまく機能しなければなりません。

Justification: Such paths will occur.

正当化：そのようなパスが発生します。

Note: loss on previous links will cause irregularities in the RTP stream reaching the compressor. Such irregularities should only marginally affect performance.

注意：以前のリンク上の損失は、コンプレッサに到達したRTPストリームでムラの原因となります。このような不規則性はわずかにパフォーマンスに影響を与える必要があります。

7a. Packet Misordering: The scheme should be able to compress when there are misordered packets in the RTP stream reaching the compressor. No misordering is expected on the link between compressor and decompressor.

図7a。パケットの誤った順序：スキームは、圧縮機に到達するRTPストリーム内misorderedパケットがあるときに圧縮することができなければなりません。いかなる誤った順序は、コンプレッサとデコンプレッサとの間のリンク上で予想されていません。

Justification: Misordering happens regularly in the Internet. However, since the Internet is engineered to run TCP reasonably well, excessive misordering will not be common and need not be handled with optimum efficiently.

正当化：誤った順序は、インターネットで定期的に起こります。インターネットが合理的にTCPを実行するように設計されているのでしかし、過剰な誤った順序は共通ではありませんし、効率的に最適で処理する必要はありません。

7b. Moderate Packet Misordering: The scheme should efficiently handle moderate misordering (2-3 packets) in the packet stream reaching the compressor.

図7b。適度パケット誤った順序：スキームを効率的に圧縮機に到達するパケットストリームの中程度の誤った順序（2-3パケット）を処理します。

Note: This kind of reordering is common.

注意：並べ替えのこの種のが一般的です。

8. Unidirectional links/multicast: Must operate (possibly with less efficiency) over links where there is no feedback channel or where there are several receivers.

8.単方向リンク/マルチキャスト（おそらくはより少ない効率で）動作しなければならないリンク上のフィードバックチャネルまたはここでいくつかの受信機が存在していません。

9. Configurable frame size fluctuation: It should be possible to restrict the number of different frame sizes used by the scheme.

9.設定可能なフレームサイズ変動：これは、スキームによって使用される異なるフレームサイズの数を制限することが可能であるべきです。

Justification: Some radio technologies support only a limited number of frame sizes efficiently.

正当化：いくつかの無線技術は、効率的なフレームサイズの限られた数をサポート。

Note: Somewhat degraded performance is to be expected when such restrictions are applied.

注意：やや性能の低下は、このような制限が適用されると予想されます。

Note: This implies that a list of "good" frame sizes must be made available and that ROHC may pick a suitable header format to utilize available space as well as possible.

注：これは、「良好な」フレームサイズのリストが利用可能にする必要があり、そのROHCは、利用可能なスペース、並びに可能を利用する適切なヘッダフォーマットを選ぶことができることを意味します。

10. Delay: ROHC should not noticeably add to the end-to-end delay.

10.遅延：ROHCは著しく、エンドツーエンド遅延に追加するべきではありません。

Justification: RTP packets carrying data for interactive voice or video have a limited end-to-end delay budget.

正当化：対話型音声やビデオのデータを運ぶRTPパケットが制限されたエンドツーエンド遅延の予算を持っています。

Note: This requirement is intended to prevent schemes that achieve robustness at the expense of delay, for example schemes that require that header i+x, x>0, is received before header i can be decompressed.

注：この要件は、そのヘッダを必要例方式のため、遅延を犠牲にして堅牢性を達成するスキームを防止することを意図しているI + X、X> 0、iを解凍することができるヘッダの前に受信されます。

Note: Together with 2.3.5, this requirement implies that ROHC will not noticeably add to the jitter of the RTP stream, other than what is caused by variations in header size.

注：一緒2.3.5で、この要件は、ROHCが顕著ヘッダサイズの変化によって引き起こされているもの以外のRTPストリームのジッタに追加しないであろうことを意味します。

Note: This requirement does not prevent a queue from forming upstream a bottleneck link. Nor does it prevent a compressor from utilizing information from more than one header in such a queue.

注：この要件は、ボトルネックリンクを上流の形成からキューを防ぐことはできません。またそれは、キュー内の複数のヘッダからの情報を利用してから圧縮を防ぐありません。

11. Residual errors: For a residual bit-error rate of at most 1e-5, the ROHC scheme must not increase the error rate.

11.残留誤差：最も1E-5での残留ビット誤り率について、ROHC方式は誤り率を増加させなければなりません。

Justification: Some target links have a residual error rate, i.e, rate of undetected errors, of this magnitude.

正当化：いくつかのターゲットリンクは、この大きさの残留誤り率、すなわち、検出されないエラーの割合を、持っています。

Note: In the presence of residual bit-errors, ROHC will need error detection mechanisms to prevent damage propagation. These mechanisms will catch some residual errors, but those not caught might cause damage propagation. This requirement states that the reduction of the damage rate due to the error detection mechanisms must not be less than the increase in error rate due to damage propagation.

注：残留ビットエラーの存在下で、ROHCは、損傷の伝播を防止するために、エラー検出メカニズムが必要になります。これらのメカニズムは、いくつかの残留エラーをキャッチしますが、キャッチされていないものは、被害の伝播を引き起こす可能性があります。この要件は、エラーの検出メカニズムへの損害率の減少はダメージの伝播によるエラー率の増加未満であってはならないと述べています。

3. IANA Considerations

3. IANAの考慮事項

A protocol which meets these requirements, e.g., [ROHC], will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.

これらの要件を満たしているプロトコル、例えば、[ROHC]は、様々な数を割り当てることIANAを必要とします。それ自体でこのドキュメントでは、しかし、任意のIANAの関与を必要としません。

4. Security Considerations

4.セキュリティについての考慮事項

A protocol specified to meet these requirements, e.g., [ROHC], must be able to compress packets containing IPSEC headers according to the IPSEC requirement, 2.2.4. There may be other security aspects to consider in such protocols. This document by itself, however, does not add any security risks.

例えば、これらの要件を満たすために指定されたプロトコル、[ROHC]は、IPSEC要件、2.2.4に従ってIPSECヘッダを含むパケットを圧縮することができなければなりません。そのようなプロトコルでは、考慮すべき他のセキュリティ面があるかもしれません。この文書では、それ自体で、しかし、セキュリティ上のリスクを追加しません。

5. Editor's Address

5.編集者の住所

Mikael Degermark Dept. of Computer Science University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077 USA

マイケルDegermark部門アリゾナ、P. O.のコンピュータサイエンス大学の私書箱210077ツーソン、AZ 85721から0077米国

Phone: (May-July): +46 70 833-8933 Phone: +1 520 621-3489 Fax: +1 520 621-4246 EMail: micke@cs.arizona.edu

電話番号：（月・7月）：+46 70 833から8933まで電話：+1 520 621から3489ファックス：+1 520 621から4246 Eメール：micke@cs.arizona.edu

6. References

6.参照

[TR] 3GPP TR 23.922 version 1.0.0, 3rd Generation partnership Project; Technical Specification Group Services and Systems Aspects; Architecture for an All IP network.

[TR] 3GPP TR 23.922バージョン1.0.0、第3世代パートナーシッププロジェクト。技術仕様グループサービスとシステム的側面。すべてのIPネットワークのためのアーキテクチャ。

[TS] TS 22.101 version 3.6.0: Service Principles

サービスの原則：[TS]は22.101バージョン3.6.0をTS

[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.

[RFC768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。

[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.

[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。

[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.

[CRTP] Casner、S.とV.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。

[OHC] Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC 3095, June 2001.

[OHC]ボルマン、C.、エディタ、 "ロバストヘッダ圧縮（ROHC）"、RFC 3095、2001年6月。

7. Full Copyright Statement

7.完全な著作権声明

著作権（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機能のための基金は現在、インターネット協会によって提供されます。