[要約] RFC 3243は、0バイトのIP/UDP/RTP圧縮のための要件と前提条件を定義しています。その目的は、ネットワーク上のデータ転送を効率化し、帯域幅を節約することです。
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
堅牢なヘッダー圧縮（ROHC）：0バイト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 (2002). All Rights Reserved.
Copyright（c）The Internet Society（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.
このドキュメントには、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は、非常に効率的で堅牢で能動的な圧縮スキームになり、IP/UDP/RTPヘッダーを1オクテットの合計サイズに圧縮できます。これにより、ROHC RTPは、WCDMAなどの新しい空気インターフェイスを備えた将来のセルラー環境にとって優れたソリューションになり、既存の回路スイッチ付き溶液と比較して、スペクトル効率がわずかに低いIPで音声サービスさえ可能になります。
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.
ただし、GSMやIS-95などの既存の空気インターフェイスでは、All-IPセルラーネットワークも構築されます。これは、使用した音声コーデックに一致する特定のフレームサイズに最適化されたラジオベアラーを使用して柔軟性が低くなります。これは、リンクでサポートされている次の高い固定パケットサイズに切り替えることなく、ヘッダーの1つのオクテットを追加できないことを意味します。これは明らかに非常にコストがかかります。長期的には、この欠点はもちろん、より柔軟なエアインターフェイスでは新しいものを排除する必要がありますが、短期的には、回路スイッチケースに匹敵する効率が、使用された場合に既に展開された音声コーデックでも達成できる場合は望ましいでしょう。既存の空気インターフェイス。それを達成するには、通常の操作中にパケットの大部分のヘッダーを完全に排除することが可能である必要があります。これが0バイトヘッダー圧縮の目的です。通常、1-OCTETヘッダーによって提供されるすべての機能は、通常、下層から機能を利用することにより、他の手段によって提供される必要があります。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バイトヘッダー圧縮を実行可能にするために、下層が1-OCTETヘッダーを交換し、セクション3で定義された要件を満たすために必要な機能を提供できると想定されています。例は、ほとんどのセルラーリンクの同期された性質です。シーケンスとタイミング情報を提供し、パケット損失の検出を可能にします。
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 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.
ROHC IP/UDP/RTPの0バイトヘッダー圧縮は、通常のROHC RTP圧縮[ROHC]のバリアントであるため、これらの要件は、通常のRTP要件[RTP-Req]で定義されたもののデルタとして説明されています。簡単にするために、このセクションは[RTP-REQ]の要件と同じ3つのサブセクションに分離されます。最初のものは、ヘッダー圧縮の残りのインターネットインフラストラクチャへの影響を扱っています。3番目は効率性とリンクテクノロジー関連の問題をカバーしています。
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圧縮スキームは、通常のROHC RTP [RTP-REQ、セクション2.2]と同じヘッダーとRTPストリームに同じ要件を課しています。ただし、「ジェネリティ」と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の場合、これは、セクション3.1の要件を満たすために、スキームが任意のRTPストリームを処理できる必要があることを意味します。ただし、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.
正当化：スペクトル効率が主な目標です。調査によると、特定のアプリケーションとリンクテクノロジーでは、ヘッダーの単一のオクテットでさえ、既存の回路スイッチ付きソリューションと比較して、スペクトル効率が大幅に低下する可能性があることが示されています。
- 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] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K。、Liu、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T。、およびH. Zheng、「堅牢なヘッダー圧縮（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] Jonsson、L-e。G. Pelletier、「堅牢なヘッダー圧縮（ROHC）：IP/UDP/RTPのリンク層アシストプロファイル」、RFC 3242、2002年4月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Phone: +46 (920) 20 21 07
Fax: +46 (920) 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。