Network Working Group K. Svanbro
Request for Comments: 3409 Ericsson
Category: Informational December 2002
Lower Layer Guidelines for Robust RTP/UDP/IP 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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document.
この文書では、ロバストヘッダ圧縮（ROHC）およびROHCは、下層の上に置い要件については、下位層のガイドラインが記載されています。そのような第三世代パートナーシッププロジェクト（3GPP）、3GPPプロジェクト2（3GPP2）、ヨーロッパの技術基準によって指定されたもののような異なるシステムに、ROHCワーキンググループに指定され、この文書の目的は、ロバストヘッダ圧縮アルゴリズムの組み込みをサポートすることです研究所（ETSI）、等。このドキュメントは[RFC3095]で指定されるようにRTP / UDP / IPおよびUDP / IPヘッダの圧縮のためだけ下層ガイドラインを覆っています。どちらも一般的なガイドラインとセルラーシステムのための具体的なガイドラインは、このドキュメントで説明されています。
Table of Contents
目次
1. Introduction.................................................. 2
2. General guidelines............................................ 2
2.1. Error detection....................................... 2
2.2. Inferred header field information..................... 3
2.3. Handling of header size variation..................... 3
2.4. Negotiation of header compression parameters.......... 5
2.5. Demultiplexing of flows onto logical channels......... 5
2.6. Packet type identification............................ 5
2.7. Packet duplication.................................... 6
2.8. Packet reordering..................................... 6
2.9. Feedback packets...................................... 6
3. Cellular system specific guidelines........................... 7
3.1. Handover procedures................................... 7
3.2. Unequal error detection (UED)......................... 8
3.3. Unequal error protection (UEP)........................ 9
4. IANA Considerations........................................... 9
5. Security Considerations....................................... 9
6. References.................................................... 9
7. Author's Address..............................................10
8. Full Copyright Statement......................................11
Almost all header compression algorithms [RFC1144, RFC2507, RFC2508] rely on some functionality from the underlying link layer. Headers (compressed or not) are expected to be delivered without any residual bit errors. IP length fields are inferred from link layer length fields. Packet type identification may be separated from the header compression scheme and performed at the underlying link layer. [RFC2509], for example, elaborates on how to incorporate IP header compression [RFC2507] in PPP [RFC1661].
ほとんどすべてのヘッダ圧縮アルゴリズム[RFC1144、RFC2507、RFC2508]下地リンク層からのいくつかの機能に依存しています。ヘッダ（圧縮されたかどうか）は、任意の残留ビットエラーなしに送達されることが期待されます。 IP長フィールドは、リンク層の長さのフィールドから推測されています。パケットタイプ識別は、ヘッダ圧縮スキームから分離し、下層のリンク層で実行されてもよいです。 [RFC2509]は、例えば、PPP [RFC1661]にIPヘッダー圧縮[RFC2507]を組み込む方法について詳しく説明します。
It is important to be aware of such assumptions on required functionality from underlying layers when incorporating a header compression scheme into a system. The functionality required by a specific header compression scheme from lower layers may also be needed if incorporation of a header compression scheme is to be prepared without knowing the exact details of the final scheme.
システムにヘッダ圧縮スキームを組み込む場合下地層から必要な機能上のような仮定を認識することが重要です。ヘッダ圧縮スキームの組み込みが最終スキームの正確な詳細を知らなくても調製する場合、下位層から特定のヘッダ圧縮方式で必要な機能も必要とされ得ます。
This document describes lower layer guidelines for robust RTP/UDP/IP header compression [RFC3095] as specified by the ROHC working group. [RFC3095] will from this point be referenced to as ROHC. These guidelines should simplify incorporation of the robust header compression algorithms into cellular systems like those standardized by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer protocols such as PPP. The document should also enable preparation of this incorporation without requiring detailed knowledge about the final header compression scheme. Relevant standardization groups standardizing link layers should, aided by this document, include required functionality in "their" link layers to support robust header compression.
この文書は、ROHCワーキンググループによって指定されたロバストRTP / UDP / IPヘッダー圧縮[RFC3095]のために下位レイヤのガイドラインが記載されています。 [RFC3095]は、この点からROHCのように参照されます。これらのガイドラインは、等、3GPP、3GPP2によって標準化されたもののようなセルラシステムにETSIをロバストヘッダ圧縮アルゴリズムの組み込みを簡素化し、また、PPPのような特定のリンク層プロトコルにすべきです。文書はまた、最終的なヘッダ圧縮スキームについての詳細な知識を必要とせずに、この組み込みの調製を可能にするべきです。リンク層の標準化関連標準化団体は、本文書によって助けなければならない、堅牢なヘッダ圧縮をサポートするために、「彼ら」のリンク層に必要な機能が含まれています。
Hence, this document clarifies the requirements ROHC put on lower layers, while the requirements on ROHC may be found in [RFC3096].
ROHC上の要件は[RFC3096]に見出すことができるが故に、この文書は、ROHCは、下位層の上に置くの要件を明確にしています。
All current header compression schemes [RFC1144, RFC2507, RFC2508] rely on lower layers to detect errors in (compressed) headers. This is usually done with link layer checksums covering at least the compressed header. However, any error detecting mechanism may fail to detect some bit errors, which are usually called residual bit errors.
現在のすべてのヘッダ圧縮方式[RFC1144、RFC2507、RFC2508]は（圧縮）ヘッダでエラーを検出するために下位層に依存しています。これは、通常、少なくとも圧縮ヘッダを覆うリンク層のチェックサムを用いて行われます。しかし、検出機構エラーは、通常、残留ビットエラーと呼ばれるいくつかのビット誤りを検出できない場合があります。
As for non-compressed IP packets, lower layers must provide similar error detection, at least for ROHC headers. ROHC has been designed not to increase the residual bit error rate (for reasonable residual error rates) compared to the case when no header compression is used. Headers passed up to the header decompressor should, however, have a residual bit error probability close to zero.
非圧縮IPパケットのように、下位層は、少なくともROHCヘッダのため、同様のエラー検出を提供しなければなりません。 ROHCにはヘッダ圧縮を用いない場合と比較し（妥当残留誤り率のために）残留ビット誤り率が増加しないように設計されています。ヘッダ復元に渡さヘッダは、しかし、ゼロに近い残留ビット誤り確率を有するべきです。
A ROHC decompressor might make use of packets with erroneous headers, even if they must be discarded. It is therefore recommended that such invalid packets are passed up to the decompressor instead of being discarded by lower layers, but the packet must then be accompanied with an error indication.
ROHCデコンプレッサは、それらが廃棄しなければならない場合でも、誤ったヘッダを持つパケットを利用するかもしれません。したがって、このような不正なパケットではなく、下位層によって廃棄されるの解凍器に渡されることが推奨されるが、パケットは、エラー表示を伴うされなければなりません。
Some fields of the RTP/UDP/IP headers may be classified as inferred, that is their values are to be inferred from other values or from an underlying link layer. A ROHC decompressor requires that at least the following information can be inferred from any underlying link layer:
RTP / UDP / IPヘッダの一部のフィールドは、それが、その値は他の値から、または下層のリンク層から推測されるべきであり、推論として分類することができます。 ROHCデコンプレッサは、少なくとも以下の情報は、任意の下層のリンク層から推測することができることを必要とします。
Packet Length (IPv4) / Payload Length (IPv6)
パケット長（IPv4）の/ペイロード長（IPv6）の
The received packet (with compressed header) length.
（圧縮されたヘッダ付き）、受信したパケット長。
Length (UDP)
長さ（UDP）
This field is redundant with the Packet Length (IPv4) or the Payload Length (IPv6) field.
このフィールドは、パケット長（IPv4）の又はペイロード長（IPv6）のフィールドと重複しています。
In summary, all these fields relate to the length of the packet the compressed header is included in. These fields may thus be inferred by the decompressor if one packet length value is signaled from the link layer to the decompressor on a per packet basis. This packet length value should be the length of the received packet including the (compressed) header.
要約すると、これらすべてのフィールドは圧縮されたヘッダーがに含まれているパケットの長さに関係する。一つのパケット長値をパケット単位でデコンプレッサへのリンクレイヤからシグナリングされる場合、これらのフィールドは、このように減圧装置によって推測することができます。このパケット長値（圧縮）ヘッダを含む受信パケットの長さであるべきです。
It is desirable for many cellular link layer technologies that bit rate variations and thus packet size variations are minimized. However, there will always be some variation in compressed header sizes since there is a trade-off between header size variations and compression efficiency, and also due to events in the header flow and on the channel. Variations in header sizes cause variations in packet sizes depending on variations of payload size. The following will only treat header size variations caused by ROHC and not packet size variations due to variations of payload size.
これは速度の変化をビット、従って、パケットサイズの変化が最小化される多くの細胞リンク層技術のために望ましいです。 、またによるヘッダ流およびチャンネル上のイベントのヘッダサイズの変化と圧縮効率との間のトレードオフが存在するので、常に圧縮されたヘッダサイズのいくつかのバリエーションが存在することになります。ヘッダサイズの変化は、ペイロードサイズの変動に応じてパケットサイズの変動を引き起こします。以下は、ペイロードサイズの変動によるROHCとしないパケットサイズの変動に起因するヘッダサイズの変化を扱います。
The link layer must in some manner support varying header sizes from 40 bytes (full RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6) down to 1 byte for the minimal compressed header. It is likely that the small compressed headers dominate the flow of headers, and that the largest headers are sent rarely, e.g., only a few times in the initialization phase of the header compression scheme.
リンク層は、いくつかの方法をサポートするために40バイト（完全なRTP / UDP / IPv4ヘッダ）または最小圧縮ヘッダの1バイトまでの60バイト（完全なRTP / UDP / IPv6）のからのヘッダサイズを変化させる必要があります。例えば、ヘッダ圧縮スキームの初期段階で、わずか数回の小さな圧縮ヘッダは、ヘッダの流れを支配する可能性があり、そして最大のヘッダはほとんど送信されないこと。
Header size variations and thus packet size variations depend on numerous factors. Unpredictable changes in the RTP, UDP or IP headers may cause compressed headers to momentarily increase in size, and header sizes may depend on packet loss rate at lower layers. Header size distributions depend also on the mode ROHC operates in. However, for e.g., a voice application, carried by RTP/UDP/IPv4, with a constant speech frame size and silence suppression, the following basic header size changes may be considered as typical:
ヘッダサイズの変化、従って、パケットサイズの変動は、多数の要因に依存します。 RTP、UDP、又はIPヘッダの予測不可能な変化は、圧縮ヘッダは瞬間的にサイズが増加する可能性があり、かつ、ヘッダサイズは下位レイヤでのパケットロス率に依存してもよいです。ヘッダサイズ分布は、ROHCがで動作モードにも依存する。しかし、一定の音声フレームのサイズと無音抑制と、RTP / UDP / IPv4のによって運ば例えば、音声アプリケーションのために、以下の基本的なヘッダサイズの変化が一般的と考えることができます：
In the very beginning of the speech session, the ROHC scheme is initialized by sending full headers called IR/DYN. These are the largest headers, with sizes depending basically on the IP-version. For IPv4 the size is approximately 40 bytes, and for IPv6 approximately 60 bytes. The IR/DYN headers are used typically during one round trip time, possible interleaved with compressed headers. After that, usually only compressed headers are sent. Compressed headers may vary in size from 1 byte up to several bytes. The smallest compressed headers are used when there is no unpredictable changes in header fields, typically during a talk spurt. In the beginning of a talk spurt, compressed header sizes may increase by one or a few bytes momentarily. Apart from increases due to new talk spurts, compressed headers may increase in size momentarily due to unpredictable changes in header fields.
音声セッションの冒頭では、ROHCスキームはIR / DYNと呼ばれる完全なヘッダを送信することで初期化されます。これらは、サイズはIP-バージョンに基本的に依存して、最大のヘッダです。 IPv4のサイズは約40バイトであり、IPv6の約60バイト。 IR / DYNヘッダーは、圧縮ヘッダを持つ可能インターリーブ、1往復時間の間に典型的に使用されます。その後、通常は圧縮されたヘッダが送信されます。圧縮されたヘッダは、いくつかのバイトに1バイトまでのサイズで変化してもよいです。典型的には、トーク時に、ヘッダフィールドには予測できない変化が存在しない場合に最小の圧縮ヘッダが使用されます。トーク・スパートの始めに、圧縮ヘッダのサイズは、瞬間的に1つまたは少数のバイトによって増大させることができます。離れによる新たなトークスパートの増加から、圧縮されたヘッダーが原因ヘッダフィールドの予測不能な変化に瞬間的にサイズが増加することができます。
ROHC provides some means to limit the amount of produced header sizes. In some cases a larger header than needed may be used to limit the number of header sizes used. Padding octets may also be used to fill up to a desired size. Chapter 6.3 (Implementation parameters) in [RFC3095] provides optional implementation parameters that make it possible to mandate how a ROHC implementation should operate, for instance to mandate how many header sizes that may be used.
ROHCは、生成ヘッダサイズの量を制限するいくつかの手段を提供します。いくつかの場合には必要以上に大きなヘッダは、使用されるヘッダのサイズの数を制限するために使用されてもよいです。パディングオクテットはまた、所望のサイズまで埋めるために使用することができます。 [RFC3095]の章6.3（実装パラメータ）ROHCの実装が使用されてもよいこと何ヘッダサイズ強制するために、例えば、動作すべき方法を強制することを可能にするオプションの実装パラメータを提供します。
ROHC has some parameters that need to be configured in an initial setup phase. Which header compression profiles are allowed may have to be determined and also what kind of context identification (CID) mechanism to use.
ROHCは、初期設定の段階で設定する必要があるいくつかのパラメータがあります。どのヘッダ圧縮プロファイルが許可されているコンテキスト識別（CID）機構の種類を使用することも決定しなければならないかもしれません。
The lower layers supporting ROHC should thus include mechanisms for negotiation of header compression parameters such as CID usage and header compression profile support. In certain environments, it might also be desirable to have mechanisms for re-negotiation of these parameters.
ROHCをサポートする下位層は、従って、そのようなCIDの使用とヘッダ圧縮プロファイルのサポートなどのヘッダ圧縮パラメータのネゴシエーションのためのメカニズムを含むべきです。特定の環境では、また、これらのパラメータの再交渉のためのメカニズムを有することが望ましいかもしれません。
The negotiation must also make sure that compressor and decompressor use exactly the same profile, i.e. that the set of profiles available after negotiation must not include two profile identifiers with the same 8-bit LSB value.
交渉はまた、コンプレッサとデコンプレッサは、交渉後の使用可能なプロファイルのセットは同じ8ビットのLSB値を持つ2つのプロファイル識別子を含めることはできませんつまりことをまったく同じプロファイルを使用することを確認する必要があります。
For unidirectional links, this configuration might have to be performed out-of-band or a priori, and similar methods could of course also be used for bi-directional links if direct negotiation is not possible.
単方向リンクの場合、この構成では、帯域外または演繹的に実行する必要があるかもしれない、との直接交渉が不可能な場合にも、同様の方法はもちろん、双方向リンクを使用することができます。
In some cellular technologies flows are demultiplexed onto radio bearers suitable to the particular flows, i.e., onto logically separated channels. For instance, real-time flows such as voice and video may be carried on logically separated bearers. It is recommended that this kind of demultiplexing is done in the lower layers supporting robust header compression. By doing so, the need for context identification in the header compression scheme is reduced. If there is a one to one mapping between flow and logical channel, there is no need at all for context identification at the header compression level.
いくつかのセルラー技術においてフローは、論理的に分離チャネルに、特定のフローに対する適切な無線ベアラ、すなわち上に逆多重化されます。音声及びビデオは論理的に分離ベアラ上で実施することができるように、例えば、リアルタイムは、流れます。逆多重化のこの種は、ロバストヘッダ圧縮をサポートする下位層で行われることが推奨されます。そうすることにより、ヘッダ圧縮スキームのコンテキスト識別の必要性が低減されます。フローと論理チャネルとの間の1対1のマッピングに存在する場合、ヘッダ圧縮レベルでのコンテキストの識別のためにすべての必要はありません。
Header compression schemes like [RFC2507, RFC2508] have relied on the underlying link layer to identify different kinds of headers by means of packet type identifiers on link layers. This kind of mechanism is not necessarily needed for ROHC since a ROHC packet type identifier is included in all compressed ROHC headers. Only if ROHC packets are to be mixed with other packets, such as packets compressed by other header compression schemes, must the link layer provide a packet type identifier. In such cases, or if ROHC is used on top of link layers already providing packet type identification, one (1) packet type identifier must be reserved for identification of ROHC packets. Thus, only one ROHC packet type is needed to mix ROHC and e.g., RFC 2507 flows, or to support ROHC on links where packet type identifiers are already present.
[RFC2507、RFC2508]のようなヘッダ圧縮方式は、リンク層のパケットタイプ識別子により、ヘッダーの種類を識別するために、下層のリンク層に頼ってきました。 ROHCパケットタイプ識別子は、全ての圧縮ROHCヘッダーに含まれているので、機構のこの種類は、必ずしもROHCのために必要とされません。 ROHCパケットは、他のヘッダ圧縮方式で圧縮されたパケットのような他のパケットと混合される場合にのみ、リンク層は、パケットタイプ識別子を提供しなければなりません。 ROHCは、既にパケットタイプの識別を提供するリンク層の上で使用される場合、そのような場合、又は、一方（1）パケットタイプ識別子は、ROHCパケットの識別のために確保されなければなりません。したがって、唯一のROHCパケットタイプは、ROHCを混合するために必要とされ、例えば、RFC 2507に流れ、又はパケットタイプ識別子が既に存在しているリンクにROHCをサポートします。
Exact duplications of one and the same packet may waste transmission resources and is in contradiction to compression. Even so, packet duplication may occur for various reasons. Packet duplication may also occur in different places along the path for a packet.
一つの同じパケットの正確な複製は、送信リソースを浪費し、圧縮に矛盾することができます。そうであっても、パケットの重複は様々な理由で発生する可能性があります。パケット複製は、パケットのための経路に沿った異なる場所で生じ得ます。
ROHC can handle packet duplication before the compressor but such packet duplications should be avoided for optimal compression efficiency. For correct ROHC operation, lower layers are not allowed to duplicate packets on the ROHC compressor-decompressor path.
ROHCはコンプレッサーの前に、パケットの重複を扱うことができるが、このようなパケットの重複が最適な圧縮効率のために避けるべきです。正しいROHCの動作のために、下位層はROHC圧縮伸長経路上のパケットを複製することはできません。
Lower layers between compressor and decompressor are assumed not to reorder packets, i.e., the decompressor must receive packets in the same order as the compressor sends them. ROHC handles, however, reordering before the compression point. That is, there is no assumption that the compressor will only receive packets in sequence.
コンプレッサとデコンプレッサとの間の下位層は、圧縮機がそれらを送信するように、すなわち、デコンプレッサは、同じ順序でパケットを受信する必要があり、パケットの順序を変更しないと仮定されます。 ROHCは、圧縮ポイントの前に並べ替え、しかし、処理します。つまり、圧縮機の配列のみでパケットを受信することは前提はありません。
ROHC may operate in three different modes; Unidirectional mode (U-mode), bidirectional optimistic mode (O-mode) and bidirectional reliable mode (R-mode). A brief description of the modes can be found in chapter 4.4 of [RFC3095].
ROHCは、3つの異なるモードで動作することができます。単方向モード（Uモード）、双方向楽観モード（Oモード）と双方向信頼モード（Rモード）。モードの簡単な説明は、[RFC3095]の4.4章に見出すことができます。
In U-mode it is not necessary to send any feedback from the decompressor to the compressor. O-mode and R-mode requires however that feedback messages from the decompressor to the compressor be sent. Feedback messages consist of small ROHC internal packets without any application payload. It is possible in ROHC to piggy-back feedback packets onto regular packets with ROHC compressed headers and payload, if there is ROHC type of compression in both the forward and reverse direction. However, this piggy-backing may not be desired or possible in some cases.
Uモードでは、圧縮機の解凍装置からのフィードバックを送信する必要はありません。 Oモード及びRモードは、圧縮機への解凍器からのフィードバックメッセージを送信することが必要です。フィードバック・メッセージは、任意のアプリケーションペイロードなし小ROHC内部パケットから成ります。なお、ROHCは、ピギーバックするためにフィードバックパケットをROHC圧縮ヘッダとペイロードとの定期的なパケットに、両方の順方向および逆方向の圧縮のROHCのタイプがある場合に可能です。しかし、このピギーバッキングは、いくつかのケースでは所望の、またはできない場合があります。
To support ROHC O-mode or R-mode operation, lower layers must provide transport of feedback packets from decompressor to compressor. If piggybacking of feedback packets is not used, lower layers must be able to handle feedback as small stand-alone packets. For optimal compression efficiency, feedback packets from the decompressor should be delivered as soon as possible to the compressor.
ROHC Oモード又はRモード動作をサポートするために、下位層は、圧縮機への解凍器からのフィードバックパケットの輸送を提供しなければなりません。フィードバックパケットのピギーバックを使用しない場合は、下の層は、小さなスタンドアロンのパケットとしてフィードバックを処理できなければなりません。最適な圧縮効率のために、解凍器からのフィードバックパケットが圧縮機にできるだけ早く送達されるべきです。
An important group of link layer technologies where robust header compression will be needed are future cellular systems, which may have a very large number of users in some years. The need for header compression is large in these kinds of systems to achieve spectrum efficiency. Hence, it is important that future cellular systems can efficiently incorporate the robust header compression scheme.
堅牢なヘッダ圧縮が必要となるリンク層技術の重要なグループは、いくつかの年でのユーザーの非常に大きな数を有していてもよく、将来のセルラーシステムです。ヘッダ圧縮の必要性は、スペクトル効率を達成するために、システムのこれらの種類に大きくなります。したがって、将来のセルラシステムを効率的にロバストヘッダ圧縮スキームを組み込むことができることが重要です。
One cellular specific property that may affect header compression is mobility and thus, handover (i.e., change of serving base station or radio network controller).
ヘッダ圧縮に影響を与える可能性があるつの細胞特異性は、モビリティ、したがって、ハンドオーバ（基地局または無線ネットワーク制御装置にサービスを提供する、すなわち、変化）です。
The main characteristics of handovers relevant for robust header compression are: the length of the longest packet loss event due to handover (i.e., the number of consecutive packet losses), and relocation of header compression context when necessary.
ロバストヘッダ圧縮に関連するハンドオーバの主な特徴は次のとおりハンドオーバによる最長のパケット損失イベントの長さ（すなわち、連続したパケット損失の数）、およびヘッダ圧縮コンテキストの再配置に必要。
Depending on the location of the header compressor/decompressor in the radio access network and the type of handover, handover may or may not cause disruptions or packet loss events in the (compressed) header flow relevant for the header compression scheme. For instance, if soft handover is used and if the header compressor/decompressor reside above the combining point for soft handover, there will be no extra packet losses visible to the decompressor due to handover. In hard handovers, where packet loss events due to handover is introduced, the length of the longest consecutive packet loss is most relevant and thus should be minimized.
無線アクセスネットワークにおいてヘッダ圧縮/伸張し、ハンドオーバの種類の位置に応じて、ハンドオーバまたはヘッダ圧縮スキームに関連する（圧縮された）ヘッダフローの中断またはパケット損失イベントを引き起こしてもしなくてもよいです。例えば、ソフトハンドオーバが使用される場合、ヘッダ圧縮は/デコンプレッサソフトハンドオーバーのための結合点以上存在する場合、ハンドオーバによる解凍器に可視余分なパケット損失は存在しないであろう。ハンドオーバによるパケット損失イベントが導入されているハードハンドオーバでは、最長の連続したパケット損失の長さは、最も関連性があるので、最小にすべきです。
To maintain efficient ROHC operation, it should be ensured that handover events do not cause significant long events of consecutive packet loss. The term "significant" in this context relates to the kind of loss tolerable for the carried real-time application.
効率的なROHC操作を維持するためには、ハンドオーバーイベントが連続したパケット損失の大幅な長いイベントを引き起こさないことを保証しなければなりません。この文脈における用語「重要なのは、」実行リアルタイム・アプリケーションのための許容損失の種類に関係します。
If hard handovers are performed, which may cause significant long events of consecutive packet loss, the radio access network should notify the compressor when such a handover has started and completed. The compressor could then be implemented to take proper actions and prevent consequences from such long loss events.
ハードハンドオーバが実行されている場合は、連続したパケット損失の大幅な長い事象を引き起こす可能性がある、そのようなハンドオーバが開始され、完了したときの圧縮機に通知しなければならない無線アクセスネットワーク。コンプレッサーは、その後、適切な行動を取ると、このような長い損失イベントからの影響を防ぐために実施することができます。
Cellular systems supporting robust header compression may have internal mechanisms for transferring the header compression context between nodes where contexts may reside, at or before handover. If no such mechanism for transferring header compression context between nodes is available, the contexts may be resynchronized by the header compression scheme itself by means of a context refresh. The header compressor will then perform a new header compression initialization, e.g., by sending full headers. This will, however, introduce an increase in the average header size dependent on how often a transfer of context is needed. To reinitialize the context in such cases, the lower layers must indicate to the header compressor when a handover has occurred, so that it knows when to refresh the context. Chapter 6.3 (Implementation parameters) in [RFC3095] provides optional implementation parameters that make it possible to trigger e.g., a complete context refresh.
ロバストヘッダ圧縮をサポートしているセルラシステムは、ハンドオーバ時又は前に、コンテキストが存在することができるノード間のヘッダ圧縮コンテキストを転送するための内部機構を有していてもよいです。ノード間のヘッダ圧縮コンテキストを転送するためのそのような機構が利用可能でない場合、コンテキストは、コンテキストの更新により、ヘッダ圧縮スキーム自体によって再同期することができます。ヘッダ圧縮器は、その後、完全なヘッダを送信することによって、例えば、新たなヘッダ圧縮初期化を実行します。これは、しかし、コンテキストの転送が必要とされる頻度に依存して平均ヘッダサイズの増加を紹介します。ハンドオーバが発生したときにコンテキストを更新するときに知っているように、このような場合にコンテキストを再初期化するために、下位層は、ヘッダ圧縮機に指示しなければなりません。 [RFC3095]の章6.3（実装パラメータ）は、例えばトリガすることを可能にする任意の実装パラメータ、完全なコンテキストの更新を提供します。
Section 3.1 states that ROHC requires error detection from lower layers for at least the compressed header. However, some cellular technologies may differentiate the amount of error detection for different parts of a packet. For instance, it could be possible to have a stronger error detection for the header part of a packet, if the application payload part of the packet is less sensitive to errors, e.g., some cellular types of speech codes.
セクションROHCは、少なくとも圧縮ヘッダの下位レイヤから誤り検出を必要と3.1の状態。しかし、いくつかの携帯電話技術は、パケットの異なる部分に対するエラー検出量を区別することができます。パケットのアプリケーションペイロード部分は、例えば、音声コードのいくつかの細胞タイプの誤差に対して敏感である場合、例えば、パケットのヘッダ部分のための強力なエラー検出を有することが可能であってもよいです。
ROHC does not require UED from lower layers, ROHC requires only an error detection mechanism that detects errors in at least the header part of the packet. Thus there is no requirement on lower layers to provide separate error detection for the header and payload part of a packet. However, overall performance may be increased if UED is used.
ROHCは、ROHCパケットの少なくともヘッダ部にエラーを検出するだけのエラー検出機構を必要とし、下位層からのUEDを必要としません。したがって、パケットのヘッダとペイロード部分に対して別々のエラー検出を提供するために、下層に必要はありません。 UEDが使用されている場合しかし、全体的なパフォーマンスを向上させることができます。
For example, if equal error detection is used in the form of one link layer checksum covering the entire packet including both header and payload part, any bit error will cause the packet to be discarded at the ROHC decompressor. It is not possible to distinguish between errors in the header and the payload part of the packet with this error detection mechanism and the ROHC decompressor must assume that the header is damaged, even if the bit error hit the payload part of the packet. If the header is assumed to be damaged, it is not possible to ensure correct decompression and that packet will thus be discarded. If the application is such that it tolerates some errors in the payload, it could have been better to deliver that packet to the application and let the application judge whether the payload was usable or not. Hence, with an unequal error detection scheme where it is possible to separate detection of errors in the header and payload part of a packet, more packets may be delivered to applications in some cases for the same lower layer error rates. The final benefit depends of course on the cost of UED for the radio interface and related protocols.
同じエラー検出は、ヘッダとペイロード部分の両方を含むパケット全体をカバーする一つのリンクレイヤチェックサムの形で使用される場合、例えば、任意のビット誤りは、パケットがROHCデコンプレッサで破棄されます。ビット誤りは、パケットのペイロード部分を打つ場合でも、ヘッダが破損していると仮定しなければならないヘッダと、このエラー検出機構とROHCデコンプレッサとのパケットのペイロード部にエラーを区別することは不可能です。ヘッダが損傷されると仮定される場合、正しい解凍を確保することができないと、そのパケットは、このように廃棄されます。アプリケーションは、それがペイロードに多少の誤差を許容するようなものであるならば、アプリケーションにそのパケットを提供し、ペイロードが使用可能であったか否かのアプリケーションの裁判官をできるように改善の余地があります。したがって、パケットのヘッダとペイロード部分内のエラーの検出を分離することが可能である不均一誤り検出方式と、より多くのパケットが同じ下層エラー率のためにいくつかのケースではアプリケーションに送達することができます。最終利益は、無線インタフェースと関連プロトコルのためのUEDのコストにもちろん依存します。
Some cellular technologies can provide different error probabilities for different parts of a packet, unequal error protection (UEP). For instance, the lower layers may provide a stronger error protection for the header part of a packet compared to the payload part of the packet.
一部の携帯電話技術は、パケット、不均一誤り保護（UEP）の異なる部分に対して異なるエラー確率を提供することができます。例えば、下層は、パケットのペイロード部分に比べてパケットのヘッダ部分のための強力なエラー保護を提供することができます。
ROHC does not require UEP. UEP may be beneficial in some cases to reduce the error rate in ROHC headers, but only if it is possible to distinguish between errors in header and payload parts of a packet, i.e., only if unequal error detection (UED) is used. The benefit of UEP depends of course on the cost of UEP for the radio interface and related protocols.
ROHCは、UEPを必要としません。不均一誤り検出（UED）が使用されている場合にのみ、すなわち、UEPはROHCヘッダにエラー率を減少させるためにいくつかのケースで有益であり得るが、パケットのヘッダとペイロード部にエラーを区別することが可能である場合のみ。 UEPの利点は、無線インタフェースと関連プロトコルのためのUEPのコストにもちろん依存します。
A protocol which follows these guidelines, e.g., [RFC3095], will require the IANA to assign various numbers. This document by itself, however, does not require IANA involvement.
例えば、これらのガイドラインに従うプロトコル、[RFC3095]は、様々な数を割り当てることIANAを必要とします。それ自体でこのドキュメントでは、しかし、IANAの関与を必要としません。
A protocol which follows these guidelines, e.g., [RFC3095], must be able to compress packets containing IPSEC headers according to [RFC3096]. There may be other security aspects to consider in such protocols. This document by itself, however, does not add security risks.
例えば、これらのガイドラインに従うプロトコル、[RFC3095]は、[RFC3096]に記載IPSECヘッダを含むパケットを圧縮することができなければなりません。そのようなプロトコルでは、考慮すべき他のセキュリティ面があるかもしれません。それ自体でこのドキュメントでは、しかし、セキュリティ上のリスクを追加しません。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]ジェーコブソン、V.、 "圧縮TCP /低速シリアルリンクのIPヘッダ"、RFC 1144、1990年2月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、エド。、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B.とS.ピンク、 "IPヘッダー圧縮"、RFC 2507、1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508] Casner、S.とV. Jacobson氏、 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"、RFC 2508、1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509] Engan、M.、Casner、S.とC.ボルマン、 "PPP上のIPヘッダー圧縮"、RFC 2509、1999年2月。
[RFC3095] Borman, 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.
[RFC3095]ボーマン、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月。
[RFC3096] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RFC3096] Degermark、M.、 "ロバストIP / UDP / RTPヘッダ圧縮のための要件"、RFC 3096、2001年7月。
Krister Svanbro Box 920 Ericsson AB SE-971 28 Lulea, Sweden
クリスターSvanbroボックス920エリクソンAB、SE-971 28ルーレオ、スウェーデン
Phone: +46 920 20 20 77 Fax: +46 920 20 20 99 EMail: krister.svanbro@ericsson.com
電話：+46 920 20 20 77ファックス：+46 920 20 20 99 Eメール：krister.svanbro@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機能のための基金は現在、インターネット協会によって提供されます。