Network Working Group G. Pelletier
Request for Comments: 4224 L-E. Jonsson
Category: Informational K. Sandlund
Ericsson
January 2006
RObust Header Compression (ROHC):
ROHC over Channels That Can Reorder Packets
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles.
ロバストヘッダ圧縮（ROHC）、RFC 3095は、圧縮プロトコル（プロファイル）の数と共に、ヘッダ圧縮のためのフレームワークを定義します。 RFC 3095で定義されたプロファイルの一つの動作仮定は、コンプレッサとデコンプレッサとの間のチャネルがパケットの順序を維持するために必要とされることです。この文書では、パケットの順序を変更することができますチャネルを介してROHCを使用しての側面を説明します。これは、既存の、このようなチャネル上のプロファイルと同様に、新しいプロファイルの設計のための提案を実装する方法のガイドラインを提供します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Applicability of This Document to ROHC Profiles .................5
3.1. Profiles within Scope ......................................5
3.2. Profiles with Special Considerations .......................5
3.3. Profiles Incompatible with Reordering ......................6
4. Background ......................................................6
4.1. Reordering Channels ........................................6
4.2. Robustness Principles of ROHC ..............................6
4.2.1. Optimistic Approach (U/O-mode) ......................7
4.2.2. Secure Reference Principle (R-mode) .................7
5. Problem Description .............................................7
5.1. ROHC and Reordering Channels ...............................7
5.1.1. LSB Interpretation Interval and Reordering ..........7
5.1.2. Reordering of Packets in R-mode .....................9
5.1.2.1. Updating Packets ...........................9
5.1.2.2. Non-Updating Packets ......................10
5.1.3. Reordering of Packets in U/O-mode ..................10
5.1.4. Reordering on the Feedback Channel .................11
5.1.5. List Compression ...................................11
5.1.6. Reordering and Mode Transitions ....................12
5.2. Consequences of Reordering ................................13
5.2.1. Functionality Incompatible with Reordering .........13
5.2.2. Context Damage (Loss of Synchronization) ...........13
5.2.3. Detected Decompression Failures (U/O/R-mode) .......13
5.2.4. Undetected Decompression Failures (R-mode only) ....14
6. Making ROHC Tolerant against Reordering ........................14
6.1. Properties of ROHC Implementations ........................14
6.1.1. Compressing Headers with Robustness against
Reordering .........................................14
6.1.1.1. Reordering and the Optimistic Approach ....15
6.1.1.2. Reordering and the Secure
Reference Principle .......................15
6.1.1.3. Robust Selection of Compressed Header .....15
6.1.2. Implementing a Reordering-Tolerant Decompressor ....16
6.1.2.1. Decompressor Feedback Considerations ......16
6.1.2.2. Considerations for Local Repair
Mechanisms ................................17
6.2. Specifying ROHC Profiles with Robustness against
Reordering ................................................17
6.2.1. Profiles with Interpretation Interval
Offset p = -1 ......................................17
6.2.2. Modifying the Interpretation Interval Offset .......18
6.2.2.1. Example Profile for Handling Reordering ...18
6.2.2.2. Defining the Values of p for New
Profiles ..................................18
7. Security Considerations ........................................19
8. Acknowledgements ...............................................19
9. Informative References .........................................19
RObust Header Compression (ROHC), RFC 3095 [1], defines a framework for header compression, along with a number of compression protocols (profiles). One operating assumption for the profiles defined in RFC 3095 is that the channel between compressor and decompressor is required to maintain packet ordering for each compressed flow. The motivation behind this assumption was that the primary candidate channels considered did guarantee in-order delivery of header-compressed packets. This assumption made it possible to meet the design objectives that were on top of the requirements list at the time when ROHC was being designed, namely to improve the compression efficiency and the tolerance to packet losses.
ロバストヘッダ圧縮（ROHC）、RFC 3095 [1]は、圧縮プロトコル（プロファイル）の数と共に、ヘッダ圧縮のためのフレームワークを定義します。 RFC 3095で定義されたプロファイルの一つの動作仮定は、コンプレッサとデコンプレッサとの間のチャネルは各圧縮フローのパケット順序を維持するために必要とされることです。この仮定の背後にある動機は考え次候補チャネルがヘッダ圧縮パケットの順序配信の保証をしたということでした。この仮定は、ROHCは、圧縮効率およびパケット損失に対する耐性を向上させるために、すなわち、設計された時点で要件リストの一番上にあった設計目標を達成することが可能となりました。
Since the publication of RFC 3095 in 2001, the question about ROHC operation over channels that do not guarantee in-order delivery has surfaced several times; arguments that ROHC cannot perform adequately over such channels have been heard. Specifically, this has been raised as a weakness when compared to other header compression alternatives, as RFC 3095 explicitly states its inability to operate if in-order delivery is not guaranteed. For those familiar with the details of ROHC and of other header compression schemes, it is clear that this is a misconception, but it can also be easily understood that the wording used in RFC 3095 can lead to such interpretation.
2001年にRFC 3095の出版以来、中に次の配信保証するものではありませんチャネルを介してROHCの操作に関する質問は何度か浮上しています。 ROHCは、このようなチャネルを介して適切に行うことができない引数が聞こえてきました。他のヘッダ圧縮代替案と比較した場合、具体的には、これは明示的に順序どおりの配信が保証されない場合に動作することができないことを述べているRFC 3095のように、弱点として提起されてきました。 ROHCの及びその他のヘッダ圧縮スキームの詳細に精通した者にとっては、これは誤解であることは明らかであるが、それはまた、容易にRFC 3095で使用される表現は、このような解釈につながることを理解することができます。
This document discusses the various aspects of implementing ROHC over channels that can reorder header-compressed packets. It explains different ways of implementing the profiles found in RFC 3095, as well as other profiles based on those profiles, over reordering channels. This can be achieved either by ensuring that compressor implementations use compressed headers that are sufficiently robust to the expected possible reordering and/or by modifying decompressor implementations to tolerate reordered packets. Ideas regarding how existing profiles could be updated and how new profiles can be defined to cope efficiently with reordering are also discussed.
この文書は、ヘッダ圧縮パケットを並べ替えることができるチャネルを介してROHCを実装する様々な態様を論じています。これは、並べ替えのチャネルを介して、これらのプロファイルに基づいて、RFC 3095で見つけたプロファイルだけでなく、他のプロファイルを実装するためのさまざまな方法を説明します。これは、圧縮機の実装および/または並べ替えのパケットを許容する減圧装置の実装を変更することにより、予想可能な並べ替えに十分に頑強である圧縮ヘッダを使用することを確実にすることのいずれかによって達成することができます。並べ替えを効率的に対処するように定義することができますどのように既存のプロファイルを更新することができ、どのように新しいプロファイルに関するアイデアも議論されています。
In some scenarios, there might be external means (such as a sequence number) to detect and potentially correct reordering. That is, for example, the case when running compression over an IPsec Encapsulating Security Payload (ESP) tunnel. With such external means to detect reordering, the decompressor can be modified to make use of the external information provided, and reordering can then be handled. How to make use of external means to address reordering is, however, out of scope for this document.
いくつかのシナリオでは、検出する（例えばシーケンス番号のような）外部の手段と、潜在的に正しい並べ替えがあるかもしれません。 IPsecのカプセル化セキュリティペイロード（ESP）トンネルを介して圧縮を実行する場合には、例えば、場合です。並べ替えを検出するために、外部手段と、減圧装置が設けられた外部情報を利用するように変更することができ、および並べ替えは、次に処理することができます。どのように並べ替えに対処するための外部手段を利用するためには、このドキュメントのための範囲の外に、しかし、です。
This document uses terminology consistent with RFC 3759 [2], and is in itself only informative. Although it does discuss technical aspects of implementing the ROHC specifications in particular environments, it does not specify any new technology.
この文書は、RFC 3759 [2]と一致する用語を使用し、それ自体にのみ有益です。それは、特定の環境でROHC仕様を実装するための技術的側面を議論していますが、それはどんな新しい技術が指定されていません。
ROHC
ROHC
The term "ROHC" herein refers to the following profiles:
用語「ROHC」は、本明細書中以下のプロファイルを参照します。
- 0x0001, 0x0002, and 0x0003 defined in RFC 3095 [1];
- 0x0004 for compression of IP-only headers [3];
- 0x0007 and 0x0008 for compression of UDP-Lite headers [4].
The term "ROHC" excludes the following profiles, which are either not affected by reordering or have the assumption of in-order delivery as a fundamental requirement for their proper operation:
用語「ROHC」は、いずれかの並べ替えの影響を受け、またはそれらの適切な動作のための基本的な要件としてにおける順序配信の仮定を持っていない次のプロファイルを除外する。
- 0x0000 (uncompressed) [1];
- 0x0005 (Link-Layer Assisted (LLA)) [5] and 0x0105
(R-mode extension to LLA) [6];
Reordering
並べ替え
A type of transmission taking place between compressor and decompressor where in-order delivery of header-compressed packets is not guaranteed.
ヘッダ圧縮パケットの順序配信が保証されないコンプレッサーと減圧装置との間で起こる送信のタイプ。
Reordering channel
並べ替えチャンネル
A connection over which reordering, as defined above, can occur.
その並べ替えを介した接続は、上記で定義され、起こり得ます。
Sequentially early packet
順次早期パケット
A packet that reaches the decompressor before one or several packets of the same context identifier (CID) that were delayed on the link. At the time of the arrival of a sequentially early packet, the packet(s) delayed on the link cannot be differentiated from lost packet(s).
リンクに遅れた同じコンテキスト識別子（CID）の1つのまたはいくつかのパケットの前にデコンプレッサに到達するパケット。順次早期パケットの到着時には、リンクに遅れたパケット（複数可）失われたパケット（複数可）と区別することはできません。
Sequentially late packet
順次後半パケット
A packet is late within its sequence if it reaches the decompressor after one or several other packets belonging to the same CID have been received, although the sequentially late packet was sent from the compressor before the other packet(s).
同じCIDに属する1つまたはいくつかの他のパケットが受信された後、順次遅いパケットは他のパケット（単数または複数）の前に圧縮機から送信されたが、それは、デコンプレッサに到達した場合、パケットは遅く、その配列内です。
Updating packet
アップデートパケット
A packet that updates the context of the decompressor, e.g., all packets except R-0 and R-1* in RFC 3095 [1].
RFC 3095にR-0、R-1 *を除くすべてのパケット[1]、例えば、逆圧縮器のコンテキストを更新パケット。
Non-updating packet
非更新パケット
A packet that does not update the context of the decompressor, e.g., only R-0 and R-1* in RFC 3095 [1].
RFC 3095に、例えば、逆圧縮器のコンテキストを更新のみR-0、R-1 *ないパケット[1]。
Change packet
変更パケット
A packet that updates one or more fields of the context other than the fields pertaining to the functions established with respect to the sequence number (SN). Specifically, it is a packet that updates fields other than the SN, the IPv4 identifier (IP-ID), the sequence number of an extension header or the RTP timestamp (TS).
シーケンス番号（SN）に対して確立された機能に関連する分野以外のコンテキストの1つまたは複数のフィールドを更新パケット。具体的には、SN、IPv4の識別子（IP-ID）、拡張ヘッダのシーケンス番号またはRTPタイムスタンプ（TS）以外のフィールドを更新パケットです。
This document addresses general reordering issues for ROHC profiles. The foremost objectives are to ensure that ROHC implementations do not forward packets with incorrectly decompressed headers to upper layers, as well as to limit the possible increase in the rate of decompression failures or in events leading to context damage, when compression is applied over reordering channels.
この文書では、ROHCプロファイルの一般的な並べ替えの問題について説明します。最も重要な目的は、圧縮が並べ替えチャネルを介して印加されたときROHC実装は、上位層に誤って解凍ヘッダを持つパケットを転送しない、ならびに解凍失敗の率でまたはコンテキストの損傷につながる事象の可能な増加を制限することを確実にするためであります。
The following sections outline solutions that are generally applicable to profiles 0x0001 (RTP), 0x0002 (UDP), and 0x0003 (ESP) defined in RFC 3095 [1]. Profile 0x0000 (uncompressed) is not affected by reordering, as the headers are sent uncompressed. The solutions also apply to profiles for IP-only (0x0004) [3] and for UDP-Lite (0x0007 and 0x0008) [4]. These profiles are based on the profiles of RFC 3095 [1] and inherently make the same in-order delivery assumption.
以下のセクションでは、プロファイルは0x0001（RTP）、0×0002（UDP）に一般的に適用されているソリューションを概説し、0x0003は（ESP）RFC 3095で定義された[1]。プロファイル0000（非圧縮）のヘッダが圧縮されていない送信されるように、並べ替えによって影響されません。溶液はまた、IP-のみ（0x0004は）のプロファイルに適用される[3]、UDP-Liteの（0x0007と0x0008で）[4]。これらのプロファイルは、[1] RFC 3095のプロファイルに基づいており、本質的に同じで順序どおりの配信の仮定をしています。
Special considerations are needed to make some of the implementation solutions of sections 6.1 and 6.2 applicable to profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4]. For these profiles, the SN is generated at the compressor, as it is not present in headers being compressed. For the least significant bit (LSB) encoding method, the interpretation interval offset (p) is always p = -1 (see section 5.1.1) when interpreting the SN. The SN is thus
特別な考慮事項は、セクション6.1の実装ソリューションの一部とプロファイル0×0002（UDP）に適用される6.2を作るために必要とされている[1]、0x0004は（IP-のみ）[3]、および0x0008で（UDP-Liteは）[4]。それが圧縮されるヘッダ内に存在しないようにこれらのプロファイルのために、SNは、圧縮機で生成されます。最下位ビット（LSB）符号化方式のため、解釈インターバルオフセット（P）は、常に、P = -1 SNを解釈するとき（セクション5.1.1を参照します）。 SNは、このようにあります
required to increase for each packet received at the decompressor, which means that reordered packets cannot be decompressed.
並べ替えパケットを解凍することができないことを意味する減圧装置で受信された各パケットのために大きくする必要。
The ROHC LLA profiles defined in RFC 3242 [5] and RFC 3408 [6] have been explicitly designed with in-order delivery as a fundamental requirement to their proper operation. Profiles 0x0005 and 0x0105 can therefore not be implemented over channels where reordering can occur; this document therefore does not apply to these profiles.
RFC 3242で定義されたROHCのLLAプロファイル[5]及びRFC 3408 [6]明示それらの適切な動作の基本要件として、順序配信に設計されています。 0x0005プロファイルと0x0105したがって並べ替えが発生する可能性チャネルを介して実現することができません。この文書では、したがって、これらのプロファイルには適用されません。
ROHC was designed with the assumption that packets are delivered in order from compressor to decompressor. This was considered as a reasonable working assumption for links where it was expected that ROHC would be used. However, many have expressed that it would be desirable to use ROHC also over connections where in-order delivery is not guaranteed [7].
ROHCは、パケットが圧縮器から解凍器に順に配信される前提で設計しました。これは、それがROHCが使用されることが期待されたリンクのための合理的な作業仮説として考えられていました。しかし、多くは、インオーダー配信が保証されない接続[7]上にも、ROHCを使用することが望ましいことを表明しています。
The reordering channels that are potential candidates to use ROHC are single-hop channels and multi-hop virtual channels.
ROHCを使用する可能性のある候補である並べ替えのチャンネルはシングルホップチャネルおよびマルチホップバーチャルチャネルです。
A single-hop channel is a point-to-point link that constitutes a single IP hop. Note that one IP hop could be one or multiple physical links. For example, a single-hop reordering channel could be a wireless link that applies error detection and performs retransmissions to guarantee error-free delivery of all data. Another example could be a wireless connection that performs bicasting of data during a handoff procedure.
シングルホップチャネルは、単一のIPホップを構成するポイントツーポイントリンクです。 1つのIPホップは、1つのまたは複数の物理リンクすることができることに注意してください。例えば、シングルホップの並べ替えチャネルは、エラー検出を適用すると、すべてのデータのエラーのない配信を保証するために、再送信を行う無線リンクである可能性があります。別の例では、ハンドオフ手順中にデータのバイキャストを行う無線接続であってもよいです。
A multi-hop virtual channel is a virtual point-to-point link that traverses multiple IP hops. A multi-hop virtual channel would typically be an IP tunnel, where compression is applied over the tunnel by the endpoints of the tunnel (not to be confused with single link compression of tunneled packets).
マルチホップ仮想チャネルは、複数のIPホップを横切る仮想ポイントツーポイントリンクです。マルチホップ仮想チャネルは、典型的には、圧縮は、トンネルのエンドポイントによってトンネル上に適用されるIPトンネル（トンネルパケットの単一のリンク圧縮と混同しない）であろう。
Robustness is based on the optimistic approach in the unidirectional and optimistic modes of operation (U/O-mode), and on the secure reference principle in the bidirectional reliable mode (R-mode). Both approaches have different characteristics in the presence of reordering between compressor and decompressor. However, in any mode, decompression of sequentially early packets will generally be handled quite well since they will be perceived and treated by the decompressor as if there had been one or more packet losses.
ロバスト性は、操作の一方向と楽観モードで楽観的アプローチ（U / Oモード）で、双方向信頼モード（Rモード）でセキュアリファレンス原理に基づいています。両方のアプローチは、コンプレッサとデコンプレッサとの間に再配列の存在下で異なる特性を有します。彼らは、知覚と1つ以上のパケットロスがあったかのように減圧器によって処理されますので、任意のモードでは、順次初期のパケットの減圧は、一般的に非常によく処理されます。
A ROHC compressor uses the optimistic approach to reduce header overhead when performing context updates in U/O-mode. The compressor normally repeats the same update until it is fairly confident that the decompressor has successfully received the information. The number of consecutive packets needed to obtain this confidence is open to implementations, and this number is normally related to the packet loss characteristics of the link where header compression is used (see also [1], section 5.3.1.1.1).
ROHC圧縮器は、U / Oモードでは、コンテキストの更新を行う際に、ヘッダーオーバーヘッドを減らすために楽観的アプローチを使用します。減圧装置が情報を正常に受信したことをかなり確信するまで圧縮機は、通常、同一の更新を繰り返します。この信頼を得るために必要な連続したパケットの数（セクション5.3.1.1.1、[1]も参照）の実装に開放され、この数は、通常、ヘッダ圧縮が使用されているリンクのパケット損失特性に関連しています。
All packet types used in U/O-mode are context updating.
U / Oモードで使用されるすべてのパケットタイプは、コンテキスト更新されています。
A ROHC compressor uses the secure reference principle in R-mode to ensure that context synchronization between ROHC peers cannot be lost due to packet losses. The compressor obtains its confidence that the decompressor has successfully updated the context from a packet carrying a 7- or 8-bit Cyclic Redundancy Check (CRC) based on acknowledgements received from the decompressor (see also [1], section 5.5.1.2).
ROHC圧縮器は、ROHCピアとの間のコンテキスト同期がパケット損失に起因して失われることができない保証するために、R-モードでセキュアリファレンス原理を使用します。コンプレッサーが減圧装置が正常に解凍器から受信した肯定応答に基づいて、7-または8ビット巡回冗長検査（CRC）を有するパケットからコンテキストを更新したことを、その信頼を取得する（また、[1]に、セクション5.5.1.2を参照）。
The secure reference principle makes it possible for a compressor to use packets that do not update the context (i.e., R-0 and R-1* [1]).
セキュアリファレンス原理は、圧縮コンテキストを更新しないパケットを使用することができる（すなわち、R-0、R-1 * [1]）。
This section reviews different aspects of ROHC susceptible of being impacted by reordering of compressed packets between ROHC peers.
このセクションでは、ROHCピア間圧縮されたパケットの並べ替えによって影響を受けての影響を受けやすいROHCのさまざまな側面をレビュー。
The least significant bit (LSB) encoding method defined in RFC 3095 ([1], section 5.7) specifies the interpretation interval offset, called p, as follows:
次のようにRFC 3095（[1]、セクション5.7）で定義された最下位ビット（LSB）符号化方法は、Pと呼ばれるオフセット解釈インターバルを指定します。
For profiles 0x0001, 0x0003, and 0x0007:
プロファイルは0x0001、0x0003、および0x0007の場合：
p = 1, when bits(SN) <= 4; p = 2^(bits(SN)-5) - 1 otherwise.
P = 1のときビット（SN）<= 4。 P = 2 ^（ビット（SN）-5） - 1、さもなければ。
The resulting table describing the interpretation interval is as follows:
次のように解釈間隔を記述し、得られたテーブルです。
+-----------+--------------+--------------+
| bits (SN) | Offset p | (2^k-1) - p |
| k | (reordering) | (losses) |
+-----------+--------------+--------------+
| 4 | 1 | 14 |
| 5 | 0 | 31 |
| 6 | 1 | 62 |
| 7 | 3 | 124 |
| 8 | 7 | 248 |
| 9 | 15 | 496 |
+-----------+--------------+--------------+
As shown in the table above, the ability for ROHC to handle sequentially late packets depends on the number of bits sent in each packet. For example, a sequentially late packet of type 0 (with either 4 or 6 bits of SN) sets the limit to one packet out of sequence for successful decompression to be possible.
上記表に示すように、ROHCを順次遅延パケットを処理するための能力は、各パケットで送信されるビット数に依存します。例えば、（SNの4つの又は6ビットのいずれかでの）タイプ0の順次遅いパケットが可能であることが成功した解凍するためのシーケンスのうち一つのパケットに制限を設定します。
For profiles 0x0002, 0x0004, and 0x0008:
プロファイル0×0002、0x0004は、と0x0008での場合：
p = - 1, independently of bits(SN).
P = - 1、独立ビット（SN）の。
A value of p = -1 means that the interpretation interval offset can only take positive values and that no sequentially late packet can be decompressed if reordering occurs over the link.
pの値は= -1オフセット解釈インターバルは正の値のみを取ると、並べ替えがリンク上で発生した場合に何を順次遅いパケットが伸張することができないことができることを意味します。
The trade-off between reordering and robustness
並べ替えと堅牢性とのトレードオフ
The ability of ROHC to handle sequentially late packets is limited by the interpretation interval offset of the sliding window used for LSB encoding. This offset has a very small value for packets with a small number of sequence number (SN) bits, but grows with the number of SN bits transmitted.
順次遅いパケットを処理するためにROHCの能力は、LSB符号化のために使用さスライディングウィンドウのオフセット解釈間隔によって制限されます。このオフセットは、シーケンス番号（SN）のビット数が少ないパケットに対して非常に小さな値を有するが、送信されたSNビットの数で成長します。
For channels where both packet losses and reordering can occur, modifications to the interpretation interval face a trade-off between the amount of reordering and the number of consecutive packet losses that can be handled by the decompressor. If the negative offset (i.e., p) is increased to handle a larger amount of reordering, the value of the positive offset of the interpretation interval must be decreased. This may impact the compression efficiency when the channel has a high loss rate.
両方のパケット損失及び並べ替えが発生する可能性がチャネルの場合、解釈インターバルの変更はトレードオフの並べ替えの量及びデコンプレッサによって処理することができる連続したパケット損失の数との間に直面します。 （即ち、P）負のオフセットは、並べ替えのより大きな量を処理するために増加される場合、解釈インターバルのオフセットが正の値を小さくしなければなりません。チャネルは高い損失率を有する場合、これは、圧縮効率に影響を与えることができます。
This is shown in the figure:
これを図に示します。
<--- interpretation interval (size is 2^k) ---->
|------------------+---------------------------|
Lower v_ref Upper
Bound Bound
<--- reordering --> <--------- losses --------->
max delta(SN) = p max delta(SN) = (2^k-1) - p
where v_ref is the reference value as per [1], section 4.5.1.
V_REF [1]は、セクション4.5.1の通りの基準値です。
In practice, the maximum variation in SN value (max delta(SN)) due to reordering that can be handled will normally correspond to the maximum number of packets that can be reordered. The same applies to the maximum number of consecutive packet losses covered by the robustness interval.
実際には、扱うことができるによる並べ替えにSN値の最大変動（最大デルタ（SN））は正常に並べ替えることができるパケットの最大数に対応します。同じことは、堅牢間隔によってカバーされ、連続するパケットロスの最大数に適用されます。
Timer-based compression of RTP TS (see [1], section 4.5.4) provides means to reduce the number of timestamp bits needed in compressed headers after longer gaps in the packet stream (e.g., for an audio stream, this is typically due to silence suppression). To use timer-based compression, an upper limit on the inter-arrival jitter must be reliably estimated by the compressor. It should be noted that although the risk of reordering of course means there is a more significant jitter on the path between the compressor and the decompressor, there are no special reordering considerations for timer-based compression. It all still boils down to the task of estimating the jitter, requiring channel characteristics knowledge at the compressor, and/or jitter estimation figures received from the decompressor.
RTP TSのタイマベースの圧縮は、パケットストリーム内のより長いギャップ（後に圧縮されたヘッダーに必要なタイムスタンプのビットの数を減少させるための手段を提供する（[1]、セクション4.5.4を参照）例えば、オーディオストリームに対して、これは典型的に起因しています）の抑制を沈黙します。タイマベースの圧縮を使用するように、到着間ジッタの上限を確実に圧縮機によって推定されなければなりません。もちろんの並べ替えのリスクは、コンプレッサとデコンプレッサとの間のパス上のより重要なジッタがあることを意味しますが、タイマーベースの圧縮のための特別な並べ替えの考慮事項が存在しないことに留意すべきです。それはすべて依然として、ジッタを推定する圧縮機にチャネル特性の知識を必要とするタスクに帰着、及び/又はジッタ推定数字は、解凍器から受信しました。
The compressor always adds references in the sliding window for all updating packets sent. The compressor removes values older than values for which it has received an acknowledgement to shrink the window and thereby increase the compression efficiency.
コンプレッサーは常に送信されたすべての更新パケットのためのスライディングウィンドウ内の参照を追加します。圧縮機は、ウィンドウを縮小することにより、圧縮効率を高めるために肯定応答を受信したの値よりも古い値を除去します。
The decompressor always updates the context when receiving an updating packet and uses the new reference for decompression. Acknowledgements are sent to allow the compressor to shrink its sliding window.
デコンプレッサは、常に更新パケットを受信したときにコンテキストを更新し、解凍のための新しい参照を使用しています。肯定応答は、圧縮機がそのスライディングウィンドウを縮小できるようにするために送られます。
Reordering between updating packets
更新パケット間の並べ替え
The decompressor can update its context from the reception of a sequentially late updating packet. The decompressor reference is then updated with a value that is no longer in the sliding window of the compressor. This "missing reference" can be caused by reordering when operating in R-mode.
デコンプレッサは順次遅れて更新パケットを受信してからそのコンテキストを更新できます。デコンプレッサ基準は、次に圧縮機のスライディングウィンドウでなくなった値で更新されます。この「不足している参照は、」R-モードで動作しているとき並べ替えによって引き起こされる場合があります。
The result is that the compressor and the decompressor lose synchronization with each other. When the decompressor acknowledges the sequentially late packet, the compressor might already have discarded the reference to this sequence number, and continue to compress packets based on more recent references (in packet arrival time). Decompression will then be attempted using the wrong reference.
結果は、コンプレッサとデコンプレッサが互いに同期を失うことです。解凍器は順次遅れてパケットを承認すると、コンプレッサーはすでにこのシーケンス番号への参照を破棄し、（パケットの到着時間の）より最近の参照に基づいてパケットを圧縮し続けている場合があります。解凍は、間違った参照を使用して試行されます。
Reordering between non-updating packets only
唯一の非更新パケット間の並べ替え
A non-updating packet that reaches the decompressor out of sequence only with respect to other non-updating packets can always be decompressed properly.
唯一の他の非更新パケットに対するシーケンスのうち解凍器に到達する非更新パケットは常に正しく解凍することができます。
Reordering between non-updating packets and updating packets
非更新パケットと更新パケット間の並べ替え
When a non-updating packet is reordered and becomes sequentially late with respect to an updating packet, the decompressor may have already updated the context with a new reference when the late packet is received. It is thus possible for a non-updating packet to be decompressed based on the wrong reference because of reordering when operating in R-mode.
非更新パケットが並べ替えおよび後期更新パケットに対して順番になると遅いパケットを受信した場合、デコンプレッサは、既に新しい参照してコンテキストを更新してもよいです。非更新パケットはR-モードで動作しているときので、並べ替えの間違った基準で解凍されることがことが可能です。
Since decompression of non-updating packets cannot be verified, this can lead to a packet erroneously decompressed to be forwarded to upper layers.
非更新パケットの解凍を検証することができないので、これは誤って上位層に転送すべきパケット伸張をもたらすことができます。
Reordering between non-change packets only
唯一の非変更パケット間の並べ替え
When only non-change packets are reordered with respect to each other, decompression of sequentially late packets is limited by the offset p of the interpretation interval (see section 5.1.1). Decompression of a sequentially late packet with SN = x is possible if the value of the SN of the packet that last updated the context was less than or equal to x + p.
唯一の非変更パケットが互いに対して並べ替えされた場合、順次遅いパケットの復元が解釈インターバルのオフセットPによって制限される（セクション5.1.1を参照）。コンテキストを更新し、最後のパケットのSNの値が以下のx + Pに等しかった場合、SN = Xで順次遅いパケットの復元が可能です。
Problems occur if context(SN) has increased by more than p with respect to field(SN) carried within the packet to decompress.
コンテキスト（SN）を解凍するためにパケット内で運ばフィールド（SN）に対してPを超えて増加した場合に問題が発生します。
This means that for a well-behaved stream with a constant unit increase in the RTP SN, a packet can arrive up to p packets out of sequence and still be correctly decompressed. Otherwise, it cannot be properly decompressed. It also means that if the compressor sends two consecutive packets with SN(packet1)=100 and SN(packet2)=108 when p=7, packet1 cannot be decompressed if it arrives even one packet late due to reordering.
これは、RTP SNにおける一定の単位増加と行儀ストリームのために、パケットがシーケンス外のpパケットまで到着することができ、まだ正常に解凍されることを意味しています。それ以外の場合は、適切に解凍することができません。また、圧縮機は、2つの連続するSNを有するパケット（パケット1）= 100とSN（packet2）= 108、P = 7を送信した場合、それが原因並べ替えに遅くても一つのパケットを到着した場合、パケット1が伸張することができない。意味します
Reordering involving change packets
関連する変更パケットの並べ替え
When a packet is reordered and becomes sequentially late with respect to a change packet, decompression of the late packet may eventually fail, as the context information required for successful decompression may not be available anymore.
パケットが並べ替えや変更パケットに関して順次遅くなると解凍の成功のために必要なコンテキスト情報はもう利用できない場合がありますように、後半パケットの解凍は結局、失敗することがあります。
Decompression can always be verified since all U/O-mode packet types are context updating. Consequently, a failure to decompress a packet that is caused by reordering can be detected, and context invalidation due to reordering can thus be avoided. The risk of forwarding incorrectly decompressed packets to upper layers is therefore small when operating in U/O-mode. For channels known to reorder packets, U/O-mode should therefore be the preferred mode of operation. The additional risk of losing context synchronization, or for erroneous packet to be delivered to upper layers, is limited.
すべてのU / Oモードのパケットタイプは、コンテキスト更新しているので、解凍は常に確認することができます。従って、並べ替えによって引き起こされるパケットを解凍の失敗を検出することができ、並べ替えによるコンテキスト無効化は、このように回避することができます。 U / Oモードで動作するとき上位層に誤って減圧パケットを転送するの危険性が小さいためです。パケットの順序を変更することが知られているチャネルの場合、U / Oモードは、したがって、好ましい動作モードであるべきです。コンテキスト同期化、または誤ったパケットのために失うの追加のリスクは、限定されて上位層に配信されます。
For R-mode, upon reception of an acknowledgement, the compressor searches the sliding window to locate an updating packet with the corresponding SN; if it is not found, the acknowledgement is invalid and is discarded ([1], section 5.5.1.2). In other words, feedback received out of order either is still useful or is discarded.
Rモードでは、肯定応答の受信時に、圧縮機は、対応するSNで更新パケットを検索するためにスライディングウィンドウを検索します。それが見つからない場合、肯定応答は無効であり、廃棄される（[1]、セクション5.5.1.2）。換言すれば、フィードバックは順依然として有用であるか、または廃棄されるかから受け取りました。
In U/O-mode, if the compressor updates its context based on feedback, the same logic as for R-mode applies in practice.
圧縮機は、フィードバックに基づいてそのコンテキストを更新した場合U / Oモードでは、Rモードの場合と同じ論理が実際に適用されます。
Reordering on the feedback channel has thus no impact in either mode.
フィードバックチャネル上で並べ替えと、このようにどちらのモードに影響を与えません。
ROHC list compression is an additional compression scheme for RTP contributing source (CSRC) lists and IP extension header chains. The base is called table-based item compression, and it is almost completely independent from the rest of the ROHC compression logic. Therefore, this part of the scheme does not exhibit any special vulnerabilities when it comes to reordering, assuming a reasonable optimistic approach is used in U/O-mode. Specifically, it does not suffer significantly from the "missing reference" problem when operating in R-mode.
ROHCリスト圧縮は、RTP貢献ソース（CSRC）リストとIP拡張ヘッダチェーンのための追加の圧縮方式です。塩基は、テーブルベースの項目圧縮と呼ばれ、それはROHC圧縮ロジックの残りの部分からほぼ完全に独立しています。それは並べ替えに来るときしたがって、スキームのこの部分は、合理的な楽観的なアプローチは、U / Oモードで使用されていると仮定すると、特別な脆弱性を示しません。 R-モードで動作しているとき具体的には、「行方不明参照」問題から大幅に低下していません。
On top of the table-based item compression mechanism, an additional compression technique may be used, called reference based list compression. Reference based list compression however has a logic that is similar to the rest of the ROHC compression logic, and therefore it suffers from similar reordering vulnerabilities, especially the "missing reference" problem of R-mode. Note, however, that the generation identifier used in U/O-mode makes that scheme more robust to reordering.
テーブルベースの項目圧縮機構の上に、追加の圧縮技術は、使用される基準ベースのリスト圧縮と呼ばれてもよいです。参照ベースのリスト圧縮しかしROHC圧縮ロジックの残りの部分と類似しているロジックを有しており、したがって、同様の並べ替えの脆弱性、Rモードの特に「欠落基準」の問題に苦しんでいます。 U / Oモードで使用される世代識別子がそのスキームよりロバスト並べ替えすることができることは、注意してください。
When using list encoding type 1, 2, or 3, which makes use of reference lists, decompression will succeed only if all individual items are known by the decompressor, along with the correct reference list required to properly decompress the packet. List compression using the "Generic scheme", also known as "Encoding type 0", is not using reference based list compression, and type 0 decompression will thus succeed as long as all individual items are known by the decompressor. Because of this, type 0 list compression should be the preferred method used when operating over reordering channels.
参照リストを利用するリスト符号化タイプ1、2、または3を使用する場合、減圧は正しくパケットを解凍するために必要な正確な参照リストと共に、全ての個々の項目は減圧装置によって知られている場合にのみ成功します。また、「エンコーディングタイプ0」として知られている「一般的なスキームを」、使用してリスト圧縮は、参照ベースのリスト圧縮を使用していない、とタイプ0解凍は、このように限り、すべての個々の項目は、デコンプレッサによって知られているとして成功します。このため、タイプ0リスト圧縮は、並べ替えチャネル上で動作しているときに使用される好ましい方法であるべきです。
Transition from U/O-mode to R-mode
RモードにU / Oモードから遷移
This transition can be affected by reordering if a packet type 0 (UO-0) is reordered and delayed by at least one round-trip time (RTT). If the decompressor initiates a mode change request to R-mode in the meantime, the reordered UO-0 packet may be handled as an R-0 packet; it can be erroneously decompressed and forwarded to upper layers. This is because the decompressor can switch to R-mode as soon as it sends the acknowledgement Ack(SN, R) to the compressor (see also [1], section 5.6).
この遷移は、パケットタイプ0（UO-0）並べ替えおよび少なくとも一つのラウンドトリップ時間（RTT）だけ遅延された場合に再順序付けすることによって影響を受ける可能性があります。減圧装置がその間にR-モードへの変更要求を開始する場合、並べ替えUO-0パケットがR-0パケットとして扱うことができます。それは誤って解凍し、上位層に転送することができます。解凍装置は（セクション5.6、[1]も参照）とすぐに、それは圧縮機に肯定応答ACK（SN、R）を送信するようにR-モードに切り替えることができるためです。
Transition from R-mode to U/O-mode
U / OモードにR-モードから遷移
A similar situation as above can occur during this transition. However, because the outcome of the decompression is always verified using a CRC verification in U/O-mode, the reordered packet will most likely fail decompression and will be discarded.
上記と同様の状況は、この移行時に発生することができます。解凍の結果は常にU / OモードでのCRC検証を使用して検証されているのでしかし、並べ替えパケットは、最も可能性の高い解凍を失敗し、破棄されます。
The above situation, although it is not deemed to occur frequently, is still possible; thus, mode transitions from U/O-mode to R-mode should be avoided when reordering can occur.
それが頻繁に発生するものではないが、上記の状況は、依然として可能です。並べ替えが起こり得る場合従って、R-モードにU / Oモードからのモード遷移は回避されるべきです。
The context updating properties of the packets exchanged between ROHC peers are the most important factors to consider when deriving the impacts of reordering. For this reason, the robustness properties of the U/O-mode and of the R-mode are affected differently.
ROHCピア間で交換されるパケットのコンテキスト更新プロパティは、並べ替えの影響を導出する際に考慮すべき最も重要な要因です。このため、U / Oモード及びRモードのロバスト性特性が異なる影響を受けます。
The effects of reordering on ROHC can be summarized as follows:
次のようにROHCに並べ替えの影響を要約することができます。
- Functionality incompatible with reordering;
- Increased probability of context damage (loss of synchronization);
- Increased number of decompression failures - Detected (U/O/R-mode);
- Increased number of decompression failures - Undetected (R-mode).
There is one optional ROHC function that cannot work in the presence of reordering between ROHC peers.
ROHCピア間の並べ替えの存在下で働くことができない1つのオプションのROHCの機能があります。
The ROHC segmentation scheme (see [1], section 5.2.5) relies entirely on the in-order delivery of each segment, as there is no sequencing information in the segments. A segmented packet for which one (or more) segment is received out of order cannot be decompressed, and it is discarded by the decompressor. Therefore, segmentation should not be used if there can be reordering between the ROHC peers.
セグメントにはシーケンシング情報が存在しないようにROHC分割方式は、各セグメントの順序配信に完全に依存している（[1]、セクション5.2.5を参照します）。セグメントは順序が狂って受信された1つ（または複数）のためのセグメント化されたパケットを解凍することができない、それは減圧装置によって破棄されます。 ROHCピア間での並べ替えが存在し得る場合従って、セグメンテーションを使用すべきではありません。
The use of this optional feature is open to implementations and is local to the compressor only; it does not impact the decompressor.
このオプション機能の使用は、実装に開放されている唯一の圧縮機にローカルです。それは、デコンプレッサには影響しません。
Reordering of packets between ROHC peers can impact the robustness properties of the optimistic approach (U/O-mode) as well as the reliability of the secure reference principle (R-mode).
ROHCピア間のパケットの並べ替えは、楽観的アプローチ（U / Oモード）のロバストネス特性ならびにセキュアリファレンス原理（Rモード）の信頼性に影響を与えることができます。
The successful decompression of a sequentially late change packet (U/O-mode) and/or updating packet (R-mode) can update the context of the decompressor in a manner unexpected by the compressor. This can lead to a loss of context synchronization between the ROHC peers.
順次遅い変化パケット（U / Oモード）及び/又は更新パケット（Rモード）の成功した減圧は、圧縮機によって予期しない方法で、デコンプレッサのコンテキストを更新することができます。これは、ROHCピア間のコンテキスト同期の損失につながることができます。
Reordering of packets between ROHC peers can lead to an increase in the number of decompression failures for context updating packets (see sections 5.1.2.1 and 5.1.3). Fortunately, as the outcome of the decompression of updating packets can be verified, the decompressor can reliably detect decompression failures, including those caused by reordering, and discard the packet. Note that local repairs, subject to the limitations stated in [1] section 5.3.2.2.3, can still be performed.
ROHCピア間のパケットの並べ替えは、（セクション5.1.2.1および5.1.3を参照）コンテキスト更新パケットに対する解凍失敗の数の増加をもたらすことができます。更新パケットの解凍の結果を検証することができるように幸い、デコンプレッサは、確実に再順序付けすることによって引き起こされるものを含む、解凍の失敗を検出し、パケットを廃棄することができます。 [1]のセクション5.3.2.2.3に記載されている制限を受けるローカル修復は、依然として行うことができることに留意されたいです。
Reordering of packets between ROHC peers can lead to an increase in the number of decompression errors for non-updating packets. For R-mode, decompression of R-0 and R-1* packets cannot be verified. If reordering occurs and decompression is performed using the wrong secure reference (see section 5.1.2.1 and 5.1.2.2), the decompressor cannot reliably detect such errors. As a result, erroneous packets may be forwarded to upper layers.
ROHCピア間のパケットの並べ替えは、非更新パケットに対する解凍エラーの数の増加につながることができます。 Rモードのために、R-0、R-1の減圧*パケットを検証することができません。並べ替えが発生し、減圧が間違った安全な参照を使用して行われる場合、デコンプレッサは、確実にそのようなエラーを検出することができない（セクション5.1.2.1と5.1.2.2を参照）。結果として、誤ったパケットを上位層に転送されてもよいです。
This section describes different approaches that can improve the performance of ROHC when used over reordering channels and minimize the effects of reordering. Examples are provided to guide implementers and designers of new profiles. The solutions target either the properties of ROHC implementations or the specification of profiles. This is covered by sections 6.1 and 6.2, respectively.
このセクションでは、並べ替えのチャネル上で使用さROHCのパフォーマンスを向上させ、並べ替えの影響を最小限に抑えることができます異なるアプローチを説明しています。例としては、新しいプロファイルの実装と設計者をガイドするために設けられています。溶液は、ROHC実装の特性またはプロファイルの指定のいずれかを標的とします。これは、それぞれのセクション6.1および6.2、で覆われています。
Existing ROHC profiles can be implemented with the capability to properly handle packet reordering. The methods described in this section conform with, and thus do not require any modifications to, the ROHC specifications within scope of this document (see section 3). Specifically, the methods presented in this section can be implemented without any impairment to interoperability with other ROHC implementations that do not use these methods.
既存のROHCプロファイルは、適切にパケットの並べ替えを処理するための機能で実現することができます。このセクションで説明する方法は、この文書の範囲内のROHC仕様（セクション3を参照）への変更を必要としないこのように準拠し、そして。具体的には、ここで説明する方法は、これらのメソッドを使用していない他のROHCの実装との相互運用性を減損することなく実施することができます。
The methods suggested here may, however, lower the compression efficiency, and these modifications should not be used when reordering is known not to occur. Some of these methods aim to increase the decompression success rate at the decompressor, while others aim to avoid context damage that would cause a loss of context synchronization between compressor and decompressor.
ここで提案する方法は、しかしながら、圧縮効率が低下すること、および並べ替えが発生しないことが知られている場合、これらの修正は使用すべきではありません。他の人が、コンプレッサとデコンプレッサとの間にコンテキストの同期の損失の原因となるコンテキストの損傷を避けることを目的としながら、これらの方法のうちのいくつかは、デコンプレッサで圧縮解除の成功率を高めることを目指しています。
The methods proposed are each addressing specific issues listed in section 5 and can be combined to achieve better robustness against reordering.
提案された方法は、セクション5に記載されている各アドレッシング特定の問題であり、リオーダリングに対してより良いロバスト性を達成するために組み合わせることができます。
The methods described in this section are methods local only to the compressor implementation. They can be used without modifications or impact to the decompressor.
このセクションで説明する方法は、圧縮機の実装にローカル方法です。これらは、修飾または伸長器に影響を与えることなく使用することができます。
The optimistic approach is affected by the reordering characteristics of the channel when operating over a reordering channel. Compressor implementations should therefore adjust their optimistic approach strategy to match both packet loss and reordering characteristics.
並べ替えチャネル上で動作しているときに楽観的アプローチは、チャネルの並べ替え特性によって影響されます。圧縮機の実装は、したがって、パケット損失および再順序付け特性の両方に一致するそれらの楽観的アプローチ戦略を調整しなければなりません。
For example, the number of repetitions for each context update can be increased. The compressor should ensure that each update is repeated until it is reasonably confident that at least one change packet in the sequence of repetitions has reached the decompressor before the first packet sent after this sequence.
例えば、各コンテキストの更新のための繰り返し回数を増加させることができます。圧縮機は、反復の配列中の少なくとも1つの変更パケットがこのシーケンスの後に送信される最初のパケットの前にデコンプレッサに到達したことを合理的に確信するまで、各更新が繰り返されることを確実にすべきです。
Fundamental to the secure reference principle is that only values acknowledged by the decompressor can be used as reference for compression. In addition, some of the packet types used in R-mode do not include a CRC over the original uncompressed header, and the decompressor has no means to verify the outcome of the decompression.
セキュアリファレンス原理に基本的には、減圧装置によって承認値のみを圧縮するための基準として使用することができるということです。加えて、R・モードで使用されるパケットタイプのいくつかは、元の非圧縮ヘッダ上にCRCを含まない、及び減圧装置は、減圧の結果を検証する手段を持ちません。
Decompression of non-updating packet types thus entirely relies on the cumulative effect of previous updates to the secure reference, and the compressed data is based on the current value of the reference. This reference must be synchronized between ROHC peers. For R-0 and R-1* packets, the reception of the encoded bits applied to the secure reference is sufficient for correct decompression, but only when in-order delivery between ROHC peers is guaranteed.
非更新パケットタイプの減圧は、このように完全にセキュアリファレンスを更新前の累積的効果に依存し、そして圧縮されたデータは、基準の電流値に基づいています。このリファレンスは、ROHCピア間で同期させる必要があります。 R-0、R-1 *パケットのために、安全な基準に適用される符号化ビットの受信がなく、ROHCピア間における順序配信が保証されている場合にのみ、正しい解凍に十分です。
Avoiding the "missing reference" problem (section 5.1.2.1)
「行方不明参照」問題の回避（セクション5.1.2.1）
A compressor implementation can delay the advance in the sliding window to a reference acknowledged by the decompressor, until it has confidence that no acknowledgement for any of the values that could be discarded can be received. This confidence can be based on the maximum delay that reordering can introduce over the channel.
それは廃棄することができる値のいずれかのための肯定応答が受信できないという確信を持つまで、コンプレッサの実装では、減圧装置によって承認基準にスライディングウィンドウにおける進歩を遅らせることができます。この自信は、チャネルを介して導入することができます並べ替え最大遅延に基づくことができます。
Packet formats can be chosen with an interpretation interval for the LSB encoded sequence number that allows for larger negative offsets (see section 5.1.1). This provides the capability to decompress sequentially late packets with a greater amount of reordering.
パケットフォーマットは、より大きな負のオフセット（セクション5.1.1を参照）を可能にするLSB符号化されたシーケンス番号の解釈間隔で選択することができます。これは、並べ替え、より多くの量で順次遅延パケットを解凍する機能を提供します。
To achieve this, the compressor should be implemented conservatively in terms of the choice of packet types to send, by transmitting packets with more sequence number bits. As shown in the table in
これを達成するために、コンプレッサーは、より多くのシーケンス番号ビットのパケットを送信することで、送信するパケットの種類の選択の面で保守的に実施されるべきです。表中に示されているように
section 5.1.1, using 8 bits of SN allows a packet to be decompressed when the reordering leads to up to 7 units in sequence number variation (i.e., delta(SN)). Increasing the number of SN bits (i.e., using a larger SN_k [1]) transmitted will make ROHC even more tolerant to reordering.
SNの8ビットを使用してセクション5.1.1は、並べ替えシーケンス番号変動（すなわち、デルタ（SN））に最大7台につながる場合、パケットが解凍されることを可能にします。 SNビットの数を増加させること（すなわち、より大きなSN_k [1]を使用して）送信すると、並べ替えにROHCをより寛容になります。
For example, a conservative compressor implementation could use the packet types as shown in the table below:
以下の表に示すように、例えば、保存的な圧縮の実装では、パケット・タイプを使用することができます。
+----------------------+-------------------------+
| Optimal Packet Type | Alternative Packet Type |
| (without reordering) | (reordering possible) |
+----------------------+-------------------------+
| UO-0 | UOR-2*-ext0 |
| R-0 | R-1*-ext0 |
| R-0-CRC | UOR-2*-ext0 |
| R-1* | R-1*-ext0 |
| UO-1 | UOR-2-ext0 |
| UO-1-TS | UOR-2-TS-ext0 |
| UO-1-ID | UO-1-ID-ext3 (with S=1) |
| | UOR-2-ID-ext0 |
| UOR-2* | UOR-2*-ext0 |
+----------------------+-------------------------+
Such a compressor implementation would thus always be sending at least 3 octets (R-mode) or 4 octets (U/O-mode). This is a trade-off when compared to the 1 octet that can be sent by a more aggressive implementation operating on a channel with no reordering.
そのような圧縮機の実装は、このように、常に、少なくとも3つのオクテット（Rモード）または4つのオクテット（U / Oモード）を送信することになります。これは、トレードオフのない並べ替えとチャネル上で動作し、より積極的な実装によって送信することができる1つのオクテットと比較されます。
Note that since the interpretation interval for profiles 0x0002, 0x0004, and 0x0008 is always p = -1 independently of bits(SN), the methods suggested in this section will not work for these profiles unless this value is modified (section 6.2.1).
この値は変更されない限り、0x0004は、プロファイル0×0002のための解釈インターバルため、及び0x0008では常にpは独立して=ビット（SN）の、このセクションで提案する方法は、これらのプロファイルのために動作しません-1ことに注意してください（セクション6.2.1） 。
The methods described in this section are methods local only to the decompressor implementation. They can be used without modifications or impact to the compressor.
このセクションで説明する方法は、解凍器の実装にローカル方法です。彼らは、圧縮機への変更または影響を与えることなく使用することができます。
Reducing the feedback rate when the flow behaves linearly
流れが直線的に動作したときに、フィードバック率を減らします
The decompressor should reduce its feedback rate when a large number of UOR-2 packets with extensions are received, when the flow behaves linearly (i.e., when only fields pertaining to the functions established with respect to the sequence number are changing).
拡張子を持つUOR-2パケットの多数が受信された場合、フロー（すなわち、シーケンス番号に対して確立された機能に関連するフィールドのみが変更されたとき）直線的に動作した場合にデコンプレッサは、そのフィードバック・レートを低減すべきです。
In particular, if the compressor implementation makes a more conservative selection of packet types (section 6.1.1.3) in order to handle reordering, the decompressor should try to avoid sending more feedback than it would for the case where the more optimal packet types are used. This can be useful to minimize the usage of the feedback channel, thereby improving efficiency of the link.
圧縮機の実装は、パケットタイプ（セクション6.1.1.3）並べ替えを処理するために、より保守的な選択を行う場合、特に、デコンプレッサは、それがより最適なパケットタイプが使用される場合の場合と比べてより多くのフィードバックを送信しないようにしてください。これにより、リンクの効率を向上させる、フィードバックチャネルの使用を最小限に抑えるために有用であり得ます。
Note that even if the decompressor does not make this adjustment to its feedback rate, packet losses or context damages will not increase.
解凍器は、そのフィードバック・レートにこの調整を行わない場合でも、パケットロスやコンテキスト被害が増加しないことに注意してください。
Acknowledgements and sequentially late packets
謝辞順次遅延パケット
Reordered feedback (or feedback for packets received out of order) will not cause problems (see section 5.1.4). However, the decompressor should not send acknowledging feedback for a packet that can be identified as being sequentially late (e.g., based on the sequence number of the packet), as the current state of the context will better reflect the compressor context than the content of the reordered packet.
並べ替えフィードバック（または順不同で受信されたパケットのためのフィードバックは）問題を（セクション5.1.4を参照）を引き起こすことはありません。コンテキストの現在の状態が良好の含有量よりも圧縮コンテキストを反映するようにしかし、減圧装置は、（例えば、パケットのシーケンス番号に基づいて）遅い順番であると同定することができるパケットのためのフィードバックを認める送るべきではありません並べ替えパケット。
When decompression fails, and if reordering can be assumed to be the cause of this failure, subsequent decompressions may be attempted for sequentially late packets by going backward in the interpretation interval (as opposed to moving forward for local repair). If one of the decompression attempts is successful, the late packet may be passed on to upper layers with or without updating the decompressor context. If the subsequent decompression attempt fails, the packet should be handled according to [1] section 5.3.2.2.3.
解凍に失敗した場合、および並べ替えは、この障害の原因であると想定することができるならば、その後の圧縮解除は、（地元の修理のために前進ではなく）解釈間隔で後方に行くことによって順次遅延パケットに対して試行することができます。減圧試みの一つが成功した場合、遅いパケットまたはデコンプレッサ・コンテキストを更新せずに上位層に渡されてもよいです。その後の伸長に失敗した場合、パケットは、[1]セクション5.3.2.2.3に従って処理されなければなりません。
New revisions of profiles 0x0002 (UDP) [1], 0x0004 (IP-only) [3], and 0x0008 (UDP-Lite) [4] should redefine how the value of the offset p is determined, and use the same algorithm as in profile 0x0001 [1] instead of p = -1 independently of bits(SN) (section 5.1.1).
プロファイル0×0002（UDP）の新しい改訂[1]、0x0004は（IP-のみ）[3]、及び0x0008で（UDP-Liteの）[4]オフセットpの値が決定される方法を再定義し、かつ同じアルゴリズムを使用する必要がありますプロファイルは0x0001 [1]の代わりに、P = -1の独立ビット（SN）（セクション5.1.1）。
While such a change would make these updated profiles slightly less robust to packet losses, they would still be no less robust than profile 0x0001.
そのような変更はわずかに少ない堅牢なパケットロスにこれらの更新されたプロファイルを作るだろうが、彼らはまだ、プロファイルは0x0001よりも小さい堅牢なないだろう。
The interpretation interval offset p could be modified for existing profiles to handle reordering while improving the compression efficiency when compared to the solution in section 6.1.1.3.
解釈インターバルオフセットpはセクション6.1.1.3で溶液と比較した場合、圧縮効率を向上させながら並べ替え処理するために、既存のプロファイルを修正することができます。
The value of the interpretation interval offset p can be adjusted to achieve a robustness against reordering similar to the effect of selecting packet types as suggested in section 6.1.1.3.
解釈インターバルオフセットPの値は、セクション6.1.1.3に示唆されるようにパケットタイプを選択する効果と同様の並べ替えに対するロバスト性を達成するように調整することができます。
Consider a scenario where robustness against packet losses is kept a priority, and for which of a value p=7 is deemed enough. In this case, a ratio where the positive offset is about twice as large as the negative offset can be used. This leaves a value of p = 2^k/ 3.
パケット損失に対するロバスト性が優先保たれ、値pのれる= 7が十分であると考えられるシナリオを考えます。この場合、正のオフセット、負のオフセットとして約2倍の大きさの比率を使用することができます。これは、p = 2 ^ K / 3の値を残します。
The resulting values are shown in the following table:
得られた値を以下の表に示します：
+-----------+--------------+----------------+
| bits (SN) | Offset p | Positive range |
| k | (reordering) | (losses) |
+-----------+--------------+----------------+
| 4 | 5 | 10 |
| 5 | 10 | 21 |
| 6 | 21 | 42 |
| 7 | 42 | 85 |
| 8 | 85 | 170 |
| 9 | 170 | 341 |
+-----------+--------------+----------------+
Using this value for p, a fair amount of reordering can be handled without having to send UOR-2 packets most of the time. The trade-off is that this is at the expense of robustness against packet losses.
pのこの値を使用して、並べ替えのかなりの量は、ほとんどの時間UOR-2パケットを送信することなく処理することができます。トレードオフは、これは、パケット損失に対するロバスト性を犠牲にしているということです。
As described in RFC 3095 [1], the interpretation interval when sending k bits of SN is defined as follows:
RFC 3095に記載されているように、以下のように[1]、SNのkビットを送信解釈間隔が定義されます。
f(v_ref, k) = [v_ref - p, v_ref + (2^k - 1) - p]
F（V_REF、K）= [V_REF - P、V_REF +（2 ^ K - 1） - P]
The negative bound (v_ref - p) limits the ability to handle reordering, and the positive bound (v_ref + (2^k - 1) - p) limits the ability to handle packet losses.
負バウンド（V_REF - p）は並べ替えを処理する能力を制限し、正結合した（V_REF +（2 ^ K - 1） - p）は、パケット損失を処理する能力を制限します。
Adjusting p will increase one of these ranges, while the other range will decrease. This trade-off between the capability to handle reordering and packet losses, including how these correlate with each other, should be considered in a ROHC profile that is meant to handle reordering.
他の範囲が減少する一方、Pを調整することで、これらの範囲の1増加します。このトレードオフの損失を並べ替えて、パケット処理する能力の間に、これらは互いに相関方法などは、並べ替えを処理するために意図されたROHCプロファイルで考慮されるべきです。
For example, if it is desirable for a profile to be as robust against reordering (negative range) and against packet losses (positive range), this range can be made equal by setting p near (2^k / 2).
例えば、プロファイルは（負の範囲）を並べ替えに対するとして堅牢であるために、それが望ましい場合は、パケット損失（正の範囲）に対して、この範囲は（2 ^ K / 2）の近傍Pを設定することにより等しくすることができます。
This document does not include additional security risks to [1]. In addition, it may lower risks related to context damage in R-mode with injected packets when sequentially late packets do not update the context (section 6.1.2.1).
この文書では、[1]に追加のセキュリティリスクが含まれていません。また、順次遅いパケットがコンテキスト（セクション6.1.2.1）を更新しない注入パケットとRモードでは、コンテキストの損傷に関連するリスクを低下させることができます。
Thanks to the committed WG document reviewers, Carl Knutsson and Mark West, for their review efforts. Thanks also to Aniruddha Kulkarni, Ramin Rezaiifar, and Gorry Fairhurst for their constructive comments.
その審査の努力のためのコミットWGドキュメントの校閲、カールKnutssonとマーク・ウェストに感謝します。彼らの建設的なコメントにもAniruddha Kulkarniさん、ラミンRezaiifar、およびGorry Fairhurstに感謝します。
[1] 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): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[1]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTP、UDP、 ESP、および非圧縮」、RFC 3095、2001年7月。
[2] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[2]ジョンソン、L-E、 "ロバストヘッダ圧縮（ROHC）：用語とチャンネルマッピングの例"。、RFC 3759、2004年4月。
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[3]ジョンソン、L-E。そして、G.ペルティエ、 "ロバストヘッダ圧縮（ROHC）：IPの圧縮プロファイル"、RFC 3843、2004年6月。
[4] Pelletier, G., "RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite", RFC 4019, April 2005.
[4]ペルティエ、G.、 "ロバストヘッダ圧縮（ROHC）：ユーザーデータグラムプロトコル（UDP）Liteのプロファイル"、RFC 4019、2005年4月を。
[5] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[5]ジョンソン、L-E。そして、G.ペルティエ、 "ロバストヘッダ圧縮（ROHC）：IP / UDP / RTPのためのリンク層補助プロファイル"、RFC 3242、2002年4月。
[6] Liu, Z. and K. Le, "Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile", RFC 3408, December 2002.
[6]劉、Z.およびK.ル、RFC 3408、2002年12月「拡張リンク層における双方向信頼モード（Rモード）のためのゼロバイトのサポートは、ロバストヘッダ圧縮（ROHC）プロフィールを支援」。
[7] Ash, J., Goode, B., Hand, J., and R. Zhang, "Requirements for Header Compression over MPLS", RFC 4247, November 2005.
[7]アッシュ、J.、グッド、B.、手、J.、およびR.張、 "MPLSオーバーヘッダー圧縮のための要件"、RFC 4247、2005年11月。
Authors' Addresses
著者のアドレス
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
GhyslainペルティエエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン
Phone: +46 8 404 29 43 Fax: +46 920 996 21 EMail: ghyslain.pelletier@ericsson.com
電話：+46 8 404 29 43ファックス：+46 920 996 21 Eメール：ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden
ラース・エリックジョンソン、エリクソンABボックス920 SE-971 28ルーレオ、スウェーデン
Phone: +46 8 404 29 61 Fax: +46 920 996 21 EMail: lars-erik.jonsson@ericsson.com
電話：+46 8 404 29 61ファックス：+46 920 996 21 Eメール：lars-erik.jonsson@ericsson.com
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden
クリストファーSandlundエリクソンABボックス920 SE-971 28ルーレオ、スウェーデン
Phone: +46 8 404 41 58 Fax: +46 920 996 21 EMail: kristofer.sandlund@ericsson.com
電話：+46 8 404 41 58ファックス：+46 920 996 21 Eメール：kristofer.sandlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。