[要約] 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
堅牢なIP/UDP/RTPヘッダー圧縮の要件
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 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からの寄付に基づいています。
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.
次の要件は、多かれ少なかれarbitrarily意的に、3つのグループに分けられています。最初のグループは、インターネットインフラストラクチャの残りの部分に対するヘッダー圧縮スキームの影響に関する要件を扱います。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.
Cellular Arenaのいくつかの現在の標準化の取り組みは、IP上の音声およびIPを介したその他のリアルタイムサービス、例えばGeran（ETSI SMG2 Standards Groupによって指定）およびUtran（3GPP標準組織によって指定）をサポートすることを目指しています。これらの標準化の取り組みにとって、リリース2000標準の完了前に適切なヘッダー圧縮スキームが開発されることが重要です。したがって、ROHC WGがスケジュールを維持することが不可欠です。
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はそのような推奨事項に頼ることはできません。
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ヘッダーの暗号化データを圧縮することはできません。
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.
3a。ハンドオーバー損失イベント：長さ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.
6. 複数のリンク：エンドツーエンドパスに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ストリームにコンプレッサーに到達する誤ったパケットがある場合、スキームは圧縮できるはずです。コンプレッサーと分解器の間のリンクには、誤った注文は予想されません。
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.
正当化：Interactive Voiceまたはビデオのデータを伝える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がヘッダーの前に受信されることを要求するスキームは、再圧縮される可能性があります。
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は損傷の伝播を防ぐためにエラー検出メカニズムが必要です。これらのメカニズムはいくつかの残留エラーをキャッチしますが、捕まえられないメカニズムは損傷の伝播を引き起こす可能性があります。この要件は、エラー検出メカニズムによる損傷率の低下は、損傷の伝播によるエラー率の増加よりも少なくてはならないことを示しています。
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の関与を必要としません。
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ヘッダーを含むパケットを圧縮できる必要があります。このようなプロトコルで考慮すべき他のセキュリティの側面があるかもしれません。ただし、このドキュメント自体は、セキュリティリスクを追加しません。
Mikael Degermark Dept. of Computer Science University of Arizona P.O. Box 210077 Tucson, AZ 85721-0077 USA
アリゾナP.O.のコンピューターサイエンス大学のミカエル・デガルク部Box 210077 Tucson、AZ 85721-0077 USA
Phone: (May-July): +46 70 833-8933
Phone: +1 520 621-3489
Fax: +1 520 621-4246
EMail: micke@cs.arizona.edu
[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] TS 22.101バージョン3.6.0：サービス原則
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144] Jacobson、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. Jacobson、「低速シリアルリンクのIP/UDP/RTPヘッダーの圧縮」、RFC 2508、1999年2月。
[OHC] Bormann, C., Editor, "Robust Header Compression (ROHC)", RFC 3095, June 2001.
[OHC] Bormann、C.、編集者、「Robust Header Compression（ROHC）」、RFC 3095、2001年6月。
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エディター機能の資金は現在、インターネット協会によって提供されています。