Network Working Group L-E. Jonsson
Request for Comments: 3243 Ericsson
Category: Informational April 2002
RObust Header Compression (ROHC):
Requirements and Assumptions for 0-byte IP/UDP/RTP 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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document contains requirements for the 0-byte IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) header compression scheme to be developed by the Robust Header Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general.
この文書では、ロバストヘッダ圧縮（ROHC）ワーキンググループによって開発される0バイトのIP / UDP / RTP（インターネット・プロトコル/ユーザ・データグラム・プロトコル/リアルタイムトランスポートプロトコル）のヘッダ圧縮方式のための要件が含まれています。それはまた、一般的にその使用についての基本的な0バイトの圧縮を実施することができる上に、典型的なリンク層のための前提条件、および仮定を含みます。
The goal of the Robust Header Compression (ROHC) Working Group is to develop header compression schemes that perform well over links with high error rates and long link roundtrip times. The schemes must perform well for cellular links, 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 roundtrip times.
ロバストヘッダ圧縮（ROHC）ワーキンググループの目標は、高いエラー率と長いリンク往復の回とのリンクの上にも行うヘッダ圧縮スキームを開発することです。スキームは、WCDMA、EDGE、およびCDMA-2000などの技術を使用して、携帯のリンクのためによく実行する必要があります。しかし、方式も高い損失と長い往復の時間と他の将来のリンク技術に適用可能であるべきです。
ROHC RTP has become a very efficient, robust and capable compression scheme, able to compress the IP/UDP/RTP headers down to a total size of only one octet. This makes ROHC RTP an excellent solution for future cellular environments with new air interfaces, such as WCDMA, making even speech services possible over IP with an insignificantly lower spectrum efficiency compared to existing circuit switched solutions.
ROHC RTPは、1オクテットの合計サイズまでIP / UDP / RTPヘッダを圧縮することができ、非常に効率的で堅牢かつ可能な圧縮方式となっています。この回路は、既存に比べてわずかに低いスペクトル効率でソリューションをIP上の可能な音声サービス交換も行う、ROHC RTPを例えばWCDMAなどの新しいエアインタフェースと将来細胞環境のための優れたソリューションを作ります。
However, all-IP cellular networks will also be built with already existing air interfaces such as GSM and IS-95, which are less flexible using radio bearers optimized for specific frame sizes matching the speech codecs used. This means that not a single octet of header can be added without switching to the next higher fixed packet size supported by the link, something which is obviously very costly. In the long term, this drawback should of course be eliminated with new, more flexible air interfaces, but in the short term it would be desirable if an efficiency comparable to the circuit switched case could also be achieved for already deployed speech codecs when used over the existing air interfaces. To achieve that, it must be possible to completely eliminate the headers for a majority of the packets during normal operation, and this is the purpose of 0-byte header compression. All functionality normally provided by the 1-octet header must then be provided by some other means, typically by utilizing functionality from the lower layer. It is important to remember that the purpose of 0-byte header compression is to provide optimal efficiency for applications matching the link layer characteristics, not efficiency in general.
しかし、全IPセルラネットワークはまた、GSMのような既存のエアインタフェースを使用して構築され、IS-95、使用する音声コーデックと一致する特定のフレームサイズに最適化された無線ベアラを使用して、より少ない柔軟です。これは、ヘッダのない単一オクテットがリンクによってサポートされる次に高い固定パケットサイズ、明らかに非常にコストがかかるものに切り替えることなく加えることができることを意味します。長期的には、この欠点は、もちろん、新しい、より柔軟なエアインタフェースを用いて除去されなければならないが、回路に匹敵する効率が上使用される場合、ケースは、既に展開音声コーデックにも達成することができる切り替えた場合、短期的には望ましいであろう既存のエアインタフェース。それを達成するために、完全に正常動作時のパケットの大部分のためのヘッダを排除することが可能でなければならず、これは0バイト・ヘッダ圧縮の目的です。通常、1オクテットのヘッダによって提供されるすべての機能は、次いで、典型的には、下位層からの機能を利用することによって、いくつかの他の手段によって提供されなければなりません。 0バイトのヘッダ圧縮の目的は、リンク層の特性ではなく、一般に効率と一致するアプリケーションに最適な効率を提供することであることを覚えておくことが重要です。
As a starting point for these requirements, the well-established requirements base developed in the ROHC WG has been used. From that, the requirements have evolved through input from the 3GPP2 community and from discussions within the WG.
これらの要件のための出発点として、ROHC WGで開発十分に確立された要件ベースが使用されてきました。それからは、要件は、3GPP2コミュニティからの入力を通って、WG内での議論から発展してきました。
The purpose of 0-byte header compression is to provide optimal usage of certain links when the traffic pattern of a packet stream completely matches the characteristics of that link. There are no assumptions that only packet streams complying with that pattern will occur, but optimal efficiency cannot of course be provided when this is not the case.
0バイト・ヘッダ圧縮の目的は、パケット・ストリームのトラフィック・パターンは完全にそのリンクの特性と一致したとき、特定のリンクの最適な使用方法を提供することです。そこそのパターンに従うだけパケットストリームが発生するという前提はありませんが、そうでないときに最適な効率はもちろん、提供することはできません。
To make 0-byte header compression feasible, it is assumed that lower layers can provide the necessary functionality needed to replace the 1-octet headers and fulfill the requirements defined in section 3. An example is the synchronized nature of most cellular links, which can provide sequencing and timing information and make packet loss detection possible.
0バイトのヘッダー圧縮を可能にするために、下層部3の例で定義された要件を1オクテットヘッダーを交換し、満たすために必要な必要な機能を提供できることであると仮定されているほとんどの細胞リンクの同期性質、缶シーケンシングおよびタイミング情報を提供し、パケットロス検出を可能にします。
Since 0-byte header compression for ROHC IP/UDP/RTP is a variant of regular ROHC RTP compression [ROHC], these requirements are described as deltas to those defined in the regular RTP requirements [RTP-REQ]. For simplicity, this section is also separated into the same three subsections as the requirements in [RTP-REQ], where the first deals
ROHC IP / UDP / RTP 0バイトのヘッダー圧縮は、通常のROHC RTP圧縮[ROHC]の変異体であるため、これらの要件は、通常のRTP要件[RTP-REQ]で定義されたものにデルタとして記載されています。簡単にするため、このセクションでは、[RTP-REQ]、最初のディールにおける要件と同じ3つのサブセクションに分離され
with the impact of header compression on the rest of the Internet infrastructure, the second concerns the headers to be compressed, and the third covers efficiency and link technology related issues.
インターネットインフラストラクチャの残りの部分にヘッダ圧縮の影響で、第二の懸念ヘッダは圧縮される、及び第三の効率とリンク技術に関連する問題をカバーします。
The meaning of header compression is in no way changed by the introduction of 0-byte header compression. No additional impact on the Internet infrastructure is thus allowed. The "Transparency" and "Ubiquity" requirements of [RTP-REQ, section 2.1] therefore also apply to 0-byte RTP compression without any modifications.
ヘッダ圧縮の意味は、0バイトのヘッダー圧縮の導入により変更は決してありません。インターネットインフラストラクチャ上の追加の影響は、このように許可されていません。 「透明」と[RTP-REQ、セクション2.1]の「ユビキタス」の要件は、従って、任意の変更なし0バイトのRTP圧縮を適用します。
The 0-byte RTP compression scheme in general imposes the same requirements on supported headers and RTP streams as regular ROHC RTP [RTP-REQ, section 2.2]. However, there are some aspects regarding the "Genericity" and IPSEC requirements that should be noted.
一般的には0バイトのRTP圧縮方式がサポートされているヘッダーに同じ要件を課し、RTPは、通常のROHC RTP [RTP-REQ、セクション2.2]のようにストリーム。しかし、注意すべきである「ジェネリック」とIPSEC要件に関するいくつかの側面があります。
The "Genericity" requirement of [RTP-REQ] states that compression of headers of arbitrary RTP streams must be supported, and this is also true for the 0-byte compression scheme to the extent that it is not allowed to assume certain RTP behavior. However, as also stated in [RTP-REQ], this does not preclude optimizations for certain media types where the traffic pattern is known. For 0-byte RTP, this means that the scheme must be able to handle arbitrary RTP streams in order to fulfill the requirements of section 3.1. However, due to the typical characteristics of 0-byte compression, by requiring a traffic pattern that suits the link over which it is implemented to be able to compress down to 0-byte headers, it becomes optimized for applications with link-suited traffic patterns. For traffic that does not comply with the link properties, the scheme must automatically and immediately fall back to non-0-byte RTP compression and must not have any impact on the packet stream.
[RTP-REQ]の「汎用性」の要件は、任意のRTPストリームのヘッダの圧縮がサポートされなければならないと述べ、これは、特定のRTP動作を想定することができない程度に0バイトの圧縮方式についても同様です。また、[RTP-REQ]に記載されているようしかし、これは、トラフィックパターンが知られている特定のメディアタイプのための最適化を排除するものではありません。 0バイトのRTPの場合、これはスキームは、任意のRTPは、セクション3.1の要件を満たすためにストリームを扱うことができなければならないことを意味します。ただし、0バイトの圧縮の典型的な特性に起因し、0バイトヘッダまで圧縮することができるように実装される上リンクに合ったトラフィックパターンを必要とすることによって、それがリンク適しトラフィックパターンを持つアプリケーション向けに最適化となります。リンクプロパティに準拠していないトラフィックの場合、スキームは、自動的に、すぐに非0バイトのRTP圧縮にフォールバックしなければならないとパケットの流れに影響があってはなりません。
Regarding IPSEC, it should be noted that 0-byte compression cannot be achieved if parts of the original headers are encrypted or carry randomly changing fields. IPSEC and 0-byte RTP header compression therefore do not go well together. If IPSEC is used and prevents 0- byte compression, the scheme must fall back to a less efficient compression that can handle all present header fields. Of course, this applies not only to IPSEC but to all cases where headers cannot be compressed down to 0-byte.
IPSECに関しては、元のヘッダの部分が暗号化またはランダムに変化するフィールドを搬送している場合は0バイトの圧縮を達成することができないことに留意すべきです。 IPSECと0バイトのRTPヘッダー圧縮は、したがって、一緒にうまく行っていません。 IPSECが使用され、0-バイトの圧縮を防止する場合、スキームは、バック全て本ヘッダーフィールドを扱うことができるより少ない効率的な圧縮に入らなければなりません。もちろん、これはIPSECではなく、ヘッダーが0バイトに圧縮することができないすべてのケースに限らず適用されます。
All the performance requirements of [RTP-REQ] also apply to 0-byte RTP header compression, with the following additions and exceptions:
[RTP-REQ]の全ての性能要件は、以下の追加及び例外を除いて、0バイトのRTPヘッダ圧縮に適用されます。
- Performance/Spectral Efficiency: For packet streams with traffic patterns that match the characteristics of the link over which 0- byte header compression is implemented, the performance should be such that 0-byte header packets are generated during normal operation, most of the time. 0-byte headers would then replace most of the 1-octet headers used by regular ROHC RTP [ROHC].
- パフォーマンス/スペクトル効率：パケットが0-バイト・ヘッダ圧縮が実施される上リンクの特性に一致するトラフィックパターンとストリームに対して、性能は、0バイトのヘッダーパケットは、通常の動作中に生成されるようなものでなければならないほとんどの時間。 0バイトのヘッダは、その後、通常のROHC RTP [ROHC]で使用される1オクテットのヘッダのほとんどを置き換えます。
Justification: Spectrum efficiency is a primary goal. Studies have shown that for certain applications and link technologies, even a single octet of header may result in a significant decrease in spectrum efficiency, compared to existing circuit switched solutions.
正当化：スペクトル効率が第一の目標です。研究は、特定のアプリケーションとリンク技術のために、ヘッダの1つでもオクテット回路は、溶液交換既存に比べて、スペクトル効率の著しい低下をもたらすことができることを示しています。
- Header Compression Coexistence: The scheme must fit into the ROHC framework together with other ROHC profiles.
- ヘッダー圧縮共存：他のROHCプロファイルと一緒にROHC枠組みに適合しなければならない仕組み。
Justification: Implementation simplicity is an important issue and the 0-byte RTP compression scheme should therefore have as much as possible in common with the regular IP/UDP/RTP profile.
正当化：実装のシンプルさは重要な問題であり、0バイトのRTP圧縮方式は、したがって、通常のIP / UDP / RTPプロファイルと共通のできるだけ多くを持っている必要があります。
- Unidirectional links: It is of less importance that the 0-byte header compression scheme be able to also work over unidirectional links.
- 単一方向リンク：それは0バイトのヘッダー圧縮方式はまた、単一方向リンク上で動作することができるあまり重要ではありません。
Justification: 0-byte header compression targets links that typically are bi-directional.
正当化：0バイトのヘッダー圧縮は、一般的に双方向のあるリンクを対象としています。
A protocol which meets these requirements, e.g., [LLA], will require the IANA to assign various numbers. This document by itself, however, does not require any IANA involvement.
これらの要件を満たしているプロトコル、例えば、[LLA]は、様々な数を割り当てることIANAを必要とします。それ自体でこのドキュメントでは、しかし、任意のIANAの関与を必要としません。
A protocol specified to meet these requirements, e.g., [LLA], may have a number of security aspects that need to be considered. This document by itself, however, does not add any security risks.
例えば、これらの要件を満たすために指定されたプロトコル、[LLA]は、考慮する必要があるセキュリティ面の数を有していてもよいです。この文書では、それ自体で、しかし、セキュリティ上のリスクを追加しません。
[RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RTP-REQ] Degermark、M.、 "ロバストIP / UDP / RTPヘッダ圧縮のための要件"、RFC 3096、2001年7月。
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust Header Compression (ROHC)", RFC 3095, July 2001.
[ROHC]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.とH.鄭、 "ロバストヘッダ圧縮（ROHC）"、RFC 3095、2001年7月。
[LLA] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
【LLA]ジョンソン、L-E。そして、G.ペルティエ、 "ロバストヘッダ圧縮（ROHC）：IP / UDP / RTPのためのリンク層補助プロファイル"、RFC 3242、2002年4月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
ラース・エリックジョンソン、エリクソンABボックス920 SE-971 28ルーレオスウェーデン
Phone: +46 (920) 20 21 07 Fax: +46 (920) 20 20 99 EMail: lars-erik.jonsson@ericsson.com
電話：+46（920）20 21 07ファックス：+46（920）20 20 99 Eメール：lars-erik.jonsson@ericsson.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。