[要約] RFC 4224は、パケットの順序を変更できるチャネル上でのROHC（RObust Header Compression）の実装に関するものです。このRFCの目的は、ROHCを使用してネットワーク上で効果的なヘッダ圧縮を実現するためのガイドラインを提供することです。
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
堅牢なヘッダー圧縮（ROHC）：パケットを再注文できるチャネル上のROHC
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).
Copyright（c）The Internet Society（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で定義されているプロファイルの1つの動作仮定は、コンプレッサーと分解器の間のチャネルがパケットの順序を維持するために必要であることです。このドキュメントでは、パケットを並べ替えることができるチャネル上で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で定義されているプロファイルの1つの動作仮定は、コンプレッサーと分解器の間のチャネルが、各圧縮フローのパケット順序を維持するために必要であることです。この仮定の背後にある動機は、考慮される主要な候補チャネルがヘッダー圧縮パケットの注文の配信を保証したことでした。この仮定により、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がそのようなチャネルで適切に実行できないという議論が聞こえました。具体的には、これは他のヘッダー圧縮の代替品と比較すると弱点として提起されています。RFC3095は、次の配信が保証されていない場合に動作できないことを明示的に述べているためです。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.
いくつかのシナリオでは、並べ替えを検出し、潜在的に修正するための外部平均（シーケンス番号など）がある場合があります。つまり、たとえば、セキュリティペイロード（ESP）トンネルをカプセル化するIPSECを介して圧縮を実行する場合です。並べ替えを検出するこのような外部手段では、減圧装置を変更して提供された外部情報を利用し、並べ替えを処理できます。ただし、並べ替えに対処するために外部手段を使用する方法は、このドキュメントの範囲外です。
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].
- RFC 3095 [1]で定義されている0x0001、0x0002、および0x0003;-IPのみのヘッダーの圧縮のための0x0004 [3];-udp-liteヘッダーの圧縮のための0x0007および0x0008 [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];
- 0x0000（非圧縮）[1];-0x0005（Link-Layer Assisted（LLA））[5]および0x0105（r-Mode拡張子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] [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）、0x0002（UDP）、および0x0003（ESP）に適用されるソリューションの概要概要3095 [1]で定義されています。プロファイル0x0000（非圧縮）は、ヘッダーが非圧縮されていないため、並べ替えの影響を受けません。ソリューションは、IPのみ（0x0004）[3]およびUDP-Lite（0x0007および0x0008）[4]のプロファイルにも適用されます。これらのプロファイルは、RFC 3095 [1]のプロファイルに基づいており、本質的に同じ注文内配信の仮定を作成します。
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 required to increase for each packet received at the decompressor, which means that reordered packets cannot be decompressed.
プロファイル0x0002（udp）[1]、0x0004（ip-only）[3]、および0x0008（udp-lite）[4]に適用可能なセクション6.1および6.2の実装ソリューションの一部を作成するには、特別な考慮事項が必要です。これらのプロファイルでは、SNは圧縮されているヘッダーには存在しないため、コンプレッサーで生成されます。SNを解釈するときは、最小有意なビット（LSB）エンコーディング方法の場合、解釈間隔オフセット（P）は常にP = -1（セクション5.1.1を参照）です。したがって、SNは、減圧器で受信した各パケットの増加に必要です。つまり、並べ替えられたパケットを解凍できません。
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 [5]およびRFC 3408 [6]で定義されているROHC LLAプロファイルは、適切な操作の基本的要件として、注文内配信で明示的に設計されています。したがって、プロファイル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が使用されることが予想されるリンクの合理的な作業仮定と見なされました。しかし、多くの人は、注文内配信が保証されていない接続を介してROHCを使用することが望ましいと表明しています[7]。
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モードでコンテキストの更新を実行するときにヘッダーオーバーヘッドを削減します。コンプレッサーは通常、減圧器が情報を正常に受信したとかなり確信するまで、同じアップデートを繰り返します。この信頼性を得るために必要な連続したパケットの数は実装に対して開かれており、この数は通常、ヘッダー圧縮が使用されるリンクのパケット損失特性に関連しています（[1]、セクション5.3.1.1.1も参照）。
All packet types used in U/O-mode are context updating.
u/o-modeで使用されるすべてのパケットタイプは、コンテキストの更新です。
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コンプレッサーは、Rモードで安全な参照原理を使用して、ROHCピア間のコンテキスト同期がパケットの損失のために失われないようにします。コンプレッサーは、減圧剤から受信された謝辞に基づいて、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と呼ばれる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^（bits（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が順次後期パケットを処理する機能は、各パケットに送信されるビットの数に依存します。たとえば、タイプ0（4ビットまたは6ビットのSN）の連続的に遅いパケットは、シーケンスから1つのパケットを設定して、減圧を成功させることができるようになります。
For profiles 0x0002, 0x0004, and 0x0008:
プロファイルの場合0x0002、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.
その結果、コンプレッサーと減圧器は互いに同期を失います。Decompressorが順次後期パケットを認めると、コンプレッサーはこのシーケンス番号への参照を既に破棄し、より最近の参照（パケット到着時刻）に基づいてパケットを圧縮し続けている可能性があります。その後、誤った参照を使用して減圧が試みられます。
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パケットまで到着し、それでも正しく非圧縮される可能性があることを意味します。それ以外の場合、適切に解凍できません。また、コンプレッサーがSN（packet1）= 100およびsn（packet2）= 108で2つの連続したパケットを送信した場合、p = 7の場合、並べ替えにより遅れて1つのパケットさえも到着した場合、packet1を減圧できないことを意味します。
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-Modeと同じロジックが実際に適用されます。
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
U/OモードからRモードへの移行
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).
この遷移は、少なくとも1回の往復時間（RTT）によってパケットタイプ0（UO-0）が再注文され、遅延している場合、並べ替えによって影響を受ける可能性があります。DecompressorがR-Modeへのモード変更要求を開始すると、R-0パケットとして順序付けられたUO-0パケットが処理される場合があります。それは誤って減圧され、上層に転送される可能性があります。これは、Decompressorがコンプレッサーに確認ACK（SN、R）を送信するとすぐにRモードに切り替えることができるためです（[1]、セクション5.6も参照）。
Transition from R-mode to U/O-mode
RモードからU/Oモードへの移行
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.
上記の状況は、頻繁に発生するとはみなされませんが、まだ可能です。したがって、並べ替えが発生する可能性がある場合、u/oモードからRモードへのモードの遷移を避ける必要があります。
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).
- 並べ替えと互換性のない機能。 - コンテキスト損傷の確率の増加（同期の喪失）; - 減圧障害の数の増加 - 検出された（U/O/Rモード）; - 減圧障害の数の増加 - 検出されない（Rモード）。
There is one optional ROHC function that cannot work in the presence of reordering between ROHC peers.
ROHCピア間の並べ替えの存在下では機能しないオプションのROHC関数が1つあります。
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.
パケット形式は、より大きな負のオフセットを可能にするLSBエンコードされたシーケンス番号の解釈間隔で選択できます（セクション5.1.1を参照）。これにより、順序的に遅いパケットをより多くの並べ替えで減圧する機能が提供されます。
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.
これを達成するには、コンプレッサーを、より多くのシーケンス番号ビットでパケットを送信することにより、送信するパケットタイプの選択に関して保守的に実装する必要があります。セクション5.1.1の表に示されているように、8ビットのSNを使用すると、並べ替えがシーケンス数の変動（つまり、デルタ（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).
プロファイルの解釈間隔0x0002、0x0004、および0x0008は常にP = -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つが成功した場合、抑制器のコンテキストを更新するか、または更新せずに上層層に渡される場合があります。後続の減圧試行が失敗した場合、[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).
プロファイルの新しい改訂0x0002（udp）[1]、0x0004（ip-only）[3]、および0x0008（udp-lite）[4]は、オフセットPの値の決定方法を再定義し、同じアルゴリズムを使用する必要があります。プロファイル0x0001 [1]では、ビット（SN）とは独立してp = -1の代わりに（セクション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.
セクション6.1.1.3の溶液と比較した場合、圧縮効率を改善しながら、並べ替えを処理するために、既存のプロファイルの解釈間隔Pを変更することができます。
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]
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）近くに設定することで等しくすることができます。
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]への追加のセキュリティリスクは含まれていません。さらに、順番に遅いパケットがコンテキストを更新しない場合、注入されたパケットを使用したRモードのコンテキストダメージに関連するリスクが低下する場合があります（セクション6.1.2.1）。
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ドキュメントレビュー担当者、Carl KnutssonとMark Westのレビューの取り組みに感謝します。Aniruddha Kulkarni、Ramin 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] 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.、およびH. Zheng、 "Robust Header圧縮（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] Jonsson、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. Pelletier、「堅牢なヘッダー圧縮（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] Pelletier、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. Pelletier、「堅牢なヘッダー圧縮（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] Liu、Z。、およびK. Le、「拡張リンク層支援の堅牢なヘッダー圧縮（ROHC）プロファイルにおける双方向信頼できるモード（Rモード）のゼロバイトサポート」、RFC 3408、2002年12月。
[7] Ash, J., Goode, B., Hand, J., and R. Zhang, "Requirements for Header Compression over MPLS", RFC 4247, November 2005.
[7] Ash、J.、Goode、B.、Hand、J。、およびR. Zhang、「MPLS上のヘッダー圧縮の要件」、RFC 4247、2005年11月。
Authors' Addresses
著者のアドレス
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea、Sweden
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Lars-erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea、Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Kristofer Sandlund Ericsson AB Box 920 SE-971 28 Lulea、Sweden
Phone: +46 8 404 41 58
Fax: +46 920 996 21
EMail: kristofer.sandlund@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供され、貢献者、インターネット社会とインターネットエンジニアリングタスクフォースが代表する、または後援する組織、またはインターネットエンジニアリングタスクフォースは、すべての保証を否認します。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果、http://ww.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）によって提供されます。