Network Working Group G. Pelletier
Request for Comments: 4224 L-E. Jonsson
Category: Informational K. Sandlund
Ericsson
January 2006
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).
版权所有（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）RFC3095定义了一个报头压缩框架，以及许多压缩协议（概要文件）。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
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
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（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的各个方面。它解释了在RFC3095中找到的配置文件以及基于这些配置文件的其他配置文件在重新排序通道上的不同实现方式。这可以通过确保压缩器实现使用对预期可能的重新排序足够健壮的压缩头和/或通过修改解压缩器实现以容忍重新排序的数据包来实现。还讨论了有关如何更新现有配置文件以及如何定义新配置文件以有效应对重新排序的想法。
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].
- 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];
- 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）的数据包之前到达解压缩程序的数据包。在顺序提前分组到达时，链路上延迟的分组不能与丢失的分组区分开来。
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的一个或多个其他数据包之后到达解压器，则该数据包在其序列中是延迟的，尽管顺序延迟的数据包是在其他数据包之前从压缩器发送的。
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[1]中除R-0和R-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[1]中仅R-0和R-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）相关的功能相关的字段除外）的数据包。具体地说，它是更新除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.
以下各节概述了通常适用于RFC 3095[1]中定义的配置文件0x0001（RTP）、0x0002（UDP）和0x0003（ESP）的解决方案。配置文件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
为了使第6.1节和第6.2节中的一些实现解决方案适用于配置文件0x0002（UDP）[1]、0x0004（仅限IP）[3]和0x0008（UDP Lite）[4]，需要特别考虑。对于这些配置文件，SN在压缩器处生成，因为它不存在于被压缩的头中。对于最低有效位（LSB）编码方法，在解释SN时，解释间隔偏移量（p）始终为p=-1（见第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[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跳的点对点链路。请注意，一个IP跃点可以是一个或多个物理链路。例如，单跳重排序信道可以是应用错误检测并执行重传以保证所有数据无错误交付的无线链路。另一个例子可以是在切换过程中执行数据双广播的无线连接。
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
鲁棒性基于单向和乐观操作模式（U/O模式）中的乐观方法，以及双向可靠模式（R模式）中的安全参考原则。在压缩机和减压器之间存在重新排序时，这两种方法具有不同的特点。然而，在任何模式下，通常都会对顺序早期数据包进行解压缩
handled quite well since they will be perceived and treated by the decompressor as if there had been one or more packet losses.
处理得相当好，因为解压器会感知和处理它们，就好像有一个或多个数据包丢失一样。
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).
在U/O模式下执行上下文更新时，ROHC压缩器使用乐观方法来减少报头开销。压缩机通常会重复相同的更新，直到它确信解压缩器已成功接收到信息。获得该置信度所需的连续数据包的数量对实现是开放的，并且该数量通常与使用报头压缩的链路的数据包丢失特性有关（另请参见[1]，第5.3.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压缩器在R模式下使用安全参考原则，以确保ROHC对等点之间的上下文同步不会因数据包丢失而丢失。压缩器根据从解压器接收到的确认（另见[1]，第5.5.1.2节），确定解压器已成功地从携带7位或8位循环冗余校验（CRC）的数据包中更新上下文。
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 |
+-----------+--------------+--------------+
+-----------+--------------+--------------+
| 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的顺序延迟数据包（SN为4位或6位）将限制设置为一个顺序错误的数据包，以使成功解压缩成为可能。
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
<--- 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是第4.5.1节[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值（max delta（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个分组，并且仍然被正确解压缩。否则，它无法正确解压缩。这还意味着，如果压缩器在p＝7时发送SN（packet1）＝100和SN（packet2）＝108的两个连续分组，则即使分组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
ROHC列表压缩是RTP贡献源（CSC）列表和IP扩展头链的附加压缩方案。这个基础称为基于表的项压缩，它几乎完全独立于ROHC压缩逻辑的其余部分。因此，该计划的这一部分没有任何特殊要求
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.
假设在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).
如果数据包类型0（UO-0）被重新排序并延迟至少一个往返时间（RTT），则此转换可能受到重新排序的影响。如果解压器同时向R-mode发起模式改变请求，则重新排序的UO-0分组可以作为R-0分组处理；它可能被错误地解压缩并转发到上层。这是因为，一旦解压器向压缩器发送确认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.
RoC对等体之间交换的数据包的上下文更新属性是在导出重排序影响时要考虑的最重要因素。因此，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对等点之间存在重新排序时无法工作。
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节）完全依赖于每个分段的顺序交付，因为分段中没有序列信息。一个（或多个）段被无序接收的分段数据包不能被解压缩，并且被解压器丢弃。因此，如果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
ROHC对等方之间数据包的重新排序可能导致上下文更新数据包的解压缩失败次数增加（见第5.1.2.1和5.1.3节）。幸运的是，由于可以验证更新数据包解压缩的结果，解压缩器可以可靠地检测解压缩失败，包括由重新排序引起的失败，并丢弃数据包。请注意，局部维修，视情况而定
to the limitations stated in [1] section 5.3.2.2.3, can still be performed.
根据[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性能并最小化重新排序影响的不同方法。提供的示例用于指导新概要文件的实现者和设计者。这些解决方案要么针对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.
例如，可以增加每次上下文更新的重复次数。压缩器应确保重复每次更新，直到有理由确信重复序列中的至少一个更改数据包在该序列之后发送的第一个数据包之前到达解压缩器。
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节，当重新排序导致序列号变化（即δ（SN））最多7个单元时，使用8位SN允许对数据包进行解压缩。增加传输的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 |
+----------------------+-------------------------+
+----------------------+-------------------------+
| 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个八位组相比，这是一个折衷方案，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，与位（SN）无关，因此本节中建议的方法将不适用于这些剖面，除非修改该值（第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
当接收到大量带有扩展名的UOR-2数据包时，当流呈线性行为时（即，仅当与
functions established with respect to the sequence number are changing).
与序列号相关的功能正在更改）。
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).
配置文件0x0002（UDP）[1]、0x0004（仅IP）[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的值被认为是足够的。在这种情况下，可以使用正偏移约为负偏移两倍的比率。这将留下一个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 |
+-----------+--------------+----------------+
+-----------+--------------+----------------+
| 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
调整p将增加其中一个范围，而另一个范围将减小。这是处理能力之间的权衡
reordering and packet losses, including how these correlate with each other, should be considered in a ROHC profile that is meant to handle reordering.
重新排序和数据包丢失，包括它们如何相互关联，应该在处理重新排序的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).
例如，如果希望配置文件对重排序（负范围）和分组丢失（正范围）具有同样的鲁棒性，则可以通过将p设置在（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]的其他安全风险。此外，当顺序延迟的数据包不更新上下文时（第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.
感谢致力于工作组文件审查的Carl Knutsson和Mark West，感谢他们的审查工作。还要感谢阿尼鲁达·库尔卡尼、拉明·雷扎伊法尔和戈里·费尔赫斯特的建设性评论。
[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.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：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] Jonsson，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的配置文件”，RFC40192005年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] Jonsson，L-E.和G.Pelletier，“鲁棒报头压缩（ROHC）：IP/UDP/RTP的链路层辅助配置文件”，RFC 32422002年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信箱920 SE-971 28 Lulea，瑞典
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
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信箱920 SE-971 28 Lulea，瑞典
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
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信箱920 SE-971 28 Lulea，瑞典
Phone: +46 8 404 41 58
Fax: +46 920 996 21
EMail: kristofer.sandlund@ericsson.com
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).
版权所有（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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。