[要約] RFC 3409は、ロバストなRTP/UDP/IPヘッダ圧縮のための下位レイヤーガイドラインを提供しています。このRFCの目的は、ネットワークの効率性を向上させ、帯域幅の節約を実現するために、RTP/UDP/IPヘッダの圧縮方法を提案することです。
Network Working Group K. Svanbro
Request for Comments: 3409 Ericsson
Category: Informational December 2002
Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
堅牢なRTP/UDP/IPヘッダー圧縮のための下層ガイドライン
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 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が下層層に置く要件に関する下層ガイドラインについて説明します。このドキュメントの目的は、ROHCワーキンググループで指定されているように、堅牢なヘッダー圧縮アルゴリズムの組み込みをサポートすることです。Institute（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が下位層に置く要件を明確にしますが、ROHCの要件は[RFC3096]に記載されている可能性があります。
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.
要約すると、これらのすべてのフィールドは、圧縮ヘッダーが含まれているパケットの長さに関連しています。したがって、これらのフィールドは、1つのパケット長値がパケットごとに1つのパケット長値が分解器に合図される場合、減圧器によって推測される場合があります。このパケットの長さの値は、（圧縮）ヘッダーを含む受信パケットの長さでなければなりません。
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ヘッダー）または60バイト（フルRTP/UDP/IPv6）から1バイトまでのさまざまなヘッダーサイズをサポートして、最小圧縮ヘッダーを1バイトまでサポートする必要があります。小さな圧縮ヘッダーがヘッダーの流れを支配し、最大のヘッダーがヘッダー圧縮スキームの初期化フェーズで数回しか送られない可能性があります。
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.
一部の細胞技術では、流れは特定のフロー、つまり論理的に分離されたチャネルに適したラジオベアラーに逆流します。たとえば、音声やビデオなどのリアルタイムのフローは、論理的に分離されたベアラーで運ばれる場合があります。この種の非gultiplexingは、堅牢なヘッダー圧縮をサポートする下層で行われることをお勧めします。そうすることで、ヘッダー圧縮スキームでのコンテキスト識別の必要性が削減されます。フローと論理チャネルの間に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が使用されている場合、ROHCパケットの識別のために1つのパケットタイプ識別子を予約する必要があります。したがって、ROHCとたとえばRFC 2507フローを混合したり、パケットタイプの識別子が既に存在しているリンクでROHCをサポートするには、1つの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).
ヘッダー圧縮に影響を与える可能性のある細胞固有の特性の1つは、移動性、したがってハンドオーバー（つまり、ベースステーションまたは無線ネットワークコントローラーの変更）です。
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.
セクション3.1は、ROHCには少なくとも圧縮ヘッダーのために下層からのエラー検出が必要であると述べています。ただし、一部のセルラーテクノロジーでは、パケットのさまざまな部分のエラー検出量を区別する場合があります。たとえば、パケットのアプリケーションペイロード部分がエラーに敏感ではない場合、たとえば一部の音声コードに敏感でない場合、パケットのヘッダー部分に対してより強いエラー検出を行うことが可能です。
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は下位層からのUEDを必要としません。ROHCは、少なくともパケットのヘッダー部分でエラーを検出するエラー検出メカニズムのみを必要とします。したがって、パケットのヘッダーとペイロード部分に個別のエラー検出を提供するための下層には要件はありません。ただし、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.
たとえば、ヘッダーパーツとペイロードパーツの両方を含むパケット全体をカバーする1つのリンクレイヤーチェックサムの形で等しいエラー検出が使用される場合、ビットエラーは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を必要としません。UEPは、ROHCヘッダーのエラー率を減らすために有益な場合がありますが、パケットのヘッダーパーツとペイロードパーツのエラーを区別できる場合のみ、つまり、不均等なエラー検出（UED）が使用される場合のみです。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] Jacobson、V。、「低速シリアルリンクのTCP/IPヘッダーの圧縮」、RFC 1144、1990年2月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661] Simpson、W.、ed。、「ポイントツーポイントプロトコル（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. Pink、「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. Bormann、「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] Borman、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月。
[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
Krister Svanbro Box 920 Ericsson AB SE-971 28 Lulea、Sweden
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@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エディター機能の資金は現在、インターネット協会によって提供されています。