Network Working Group K. Svanbro
Request for Comments: 3409 Ericsson
Category: Informational December 2002
Network Working Group K. Svanbro
Request for Comments: 3409 Ericsson
Category: Informational December 2002
Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression
健壮RTP/UDP/IP报头压缩的低层指南
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers. The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by Third Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2), European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP and UDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document.
本文档描述了鲁棒头压缩（ROHC）的低层指南以及ROHC对低层的要求。本文件的目的是支持将ROHC工作组规定的健壮的报头压缩算法纳入不同的系统，如第三代合作伙伴关系项目（3GPP）、3GPP项目2（3GPP2）、欧洲技术标准协会（ETSI）规定的系统，本文件仅涵盖[RFC3095]中规定的RTP/UDP/IP和UDP/IP头压缩的较低层指南。本文件讨论了蜂窝系统的一般指南和特定指南。
Table of Contents
目录
1. Introduction.................................................. 2
2. General guidelines............................................ 2
2.1. Error detection....................................... 2
2.2. Inferred header field information..................... 3
2.3. Handling of header size variation..................... 3
2.4. Negotiation of header compression parameters.......... 5
2.5. Demultiplexing of flows onto logical channels......... 5
2.6. Packet type identification............................ 5
2.7. Packet duplication.................................... 6
2.8. Packet reordering..................................... 6
2.9. Feedback packets...................................... 6
3. Cellular system specific guidelines........................... 7
3.1. Handover procedures................................... 7
3.2. Unequal error detection (UED)......................... 8
3.3. Unequal error protection (UEP)........................ 9
1. Introduction.................................................. 2
2. General guidelines............................................ 2
2.1. Error detection....................................... 2
2.2. Inferred header field information..................... 3
2.3. Handling of header size variation..................... 3
2.4. Negotiation of header compression parameters.......... 5
2.5. Demultiplexing of flows onto logical channels......... 5
2.6. Packet type identification............................ 5
2.7. Packet duplication.................................... 6
2.8. Packet reordering..................................... 6
2.9. Feedback packets...................................... 6
3. Cellular system specific guidelines........................... 7
3.1. Handover procedures................................... 7
3.2. Unequal error detection (UED)......................... 8
3.3. Unequal error protection (UEP)........................ 9
4. IANA Considerations........................................... 9
5. Security Considerations....................................... 9
6. References.................................................... 9
7. Author's Address..............................................10
8. Full Copyright Statement......................................11
4. IANA Considerations........................................... 9
5. Security Considerations....................................... 9
6. References.................................................... 9
7. Author's Address..............................................10
8. Full Copyright Statement......................................11
Almost all header compression algorithms [RFC1144, RFC2507, RFC2508] rely on some functionality from the underlying link layer. Headers (compressed or not) are expected to be delivered without any residual bit errors. IP length fields are inferred from link layer length fields. Packet type identification may be separated from the header compression scheme and performed at the underlying link layer. [RFC2509], for example, elaborates on how to incorporate IP header compression [RFC2507] in PPP [RFC1661].
几乎所有的报头压缩算法[RFC1144、RFC2507、RFC2508]都依赖于底层链路层的一些功能。标头（压缩或未压缩）预计将在没有任何剩余位错误的情况下交付。IP长度字段是从链路层长度字段推断出来的。分组类型识别可以与报头压缩方案分离，并在底层链路层执行。例如，[RFC2509]详细介绍了如何将IP报头压缩[RFC2507]合并到PPP[RFC1661]中。
It is important to be aware of such assumptions on required functionality from underlying layers when incorporating a header compression scheme into a system. The functionality required by a specific header compression scheme from lower layers may also be needed if incorporation of a header compression scheme is to be prepared without knowing the exact details of the final scheme.
在将报头压缩方案合并到系统中时，必须了解对底层所需功能的此类假设。如果在不知道最终方案的确切细节的情况下准备合并报头压缩方案，则可能还需要来自较低层的特定报头压缩方案所需的功能。
This document describes lower layer guidelines for robust RTP/UDP/IP header compression [RFC3095] as specified by the ROHC working group. [RFC3095] will from this point be referenced to as ROHC. These guidelines should simplify incorporation of the robust header compression algorithms into cellular systems like those standardized by 3GPP, 3GPP2, ETSI, etc, and also into specific link layer protocols such as PPP. The document should also enable preparation of this incorporation without requiring detailed knowledge about the final header compression scheme. Relevant standardization groups standardizing link layers should, aided by this document, include required functionality in "their" link layers to support robust header compression.
本文件描述了ROHC工作组规定的健壮RTP/UDP/IP报头压缩[RFC3095]的底层指南。[RFC3095]从此将被称为ROHC。这些指南应简化将健壮的报头压缩算法并入蜂窝系统（如3GPP、3GPP2、ETSI等标准化的系统）以及特定链路层协议（如PPP）的过程。该文件还应允许在不需要详细了解最终报头压缩方案的情况下准备本合并。在本文件的帮助下，标准化链接层的相关标准化组应在“其”链接层中包含所需的功能，以支持健壮的标头压缩。
Hence, this document clarifies the requirements ROHC put on lower layers, while the requirements on ROHC may be found in [RFC3096].
因此，本文件澄清了ROHC对下层的要求，而对ROHC的要求可在[RFC3096]中找到。
All current header compression schemes [RFC1144, RFC2507, RFC2508] rely on lower layers to detect errors in (compressed) headers. This is usually done with link layer checksums covering at least the
所有当前的报头压缩方案[RFC1144、RFC2507、RFC2508]都依赖较低的层来检测（压缩的）报头中的错误。这通常是通过链路层校验和至少覆盖
compressed header. However, any error detecting mechanism may fail to detect some bit errors, which are usually called residual bit errors.
压缩标题。然而，任何错误检测机制都可能无法检测某些位错误，这些位错误通常被称为残余位错误。
As for non-compressed IP packets, lower layers must provide similar error detection, at least for ROHC headers. ROHC has been designed not to increase the residual bit error rate (for reasonable residual error rates) compared to the case when no header compression is used. Headers passed up to the header decompressor should, however, have a residual bit error probability close to zero.
对于非压缩的IP数据包，较低的层必须提供类似的错误检测，至少对于ROHC头。与不使用报头压缩的情况相比，ROHC的设计不会增加残余误码率（合理的残余误码率）。然而，传递给报头解压缩器的报头的剩余误码概率应接近于零。
A ROHC decompressor might make use of packets with erroneous headers, even if they must be discarded. It is therefore recommended that such invalid packets are passed up to the decompressor instead of being discarded by lower layers, but the packet must then be accompanied with an error indication.
ROHC解压器可能会使用具有错误头的数据包，即使它们必须被丢弃。因此，建议将此类无效数据包传递给解压器，而不是由较低层丢弃，但该数据包随后必须附有错误指示。
Some fields of the RTP/UDP/IP headers may be classified as inferred, that is their values are to be inferred from other values or from an underlying link layer. A ROHC decompressor requires that at least the following information can be inferred from any underlying link layer:
RTP/UDP/IP报头的某些字段可能被分类为推断字段，也就是说，它们的值将从其他值或基础链路层推断出来。ROHC解压器要求至少可以从任何底层链路层推断出以下信息：
Packet Length (IPv4) / Payload Length (IPv6)
数据包长度（IPv4）/有效负载长度（IPv6）
The received packet (with compressed header) length.
接收到的数据包（带有压缩头）长度。
Length (UDP)
长度（UDP）
This field is redundant with the Packet Length (IPv4) or the Payload Length (IPv6) field.
此字段与数据包长度（IPv4）或有效负载长度（IPv6）字段冗余。
In summary, all these fields relate to the length of the packet the compressed header is included in. These fields may thus be inferred by the decompressor if one packet length value is signaled from the link layer to the decompressor on a per packet basis. This packet length value should be the length of the received packet including the (compressed) header.
总之，所有这些字段都与包含压缩头的数据包的长度有关。因此，如果在每个分组的基础上从链路层向解压缩器发送一个分组长度值的信号，则解压缩器可以推断这些字段。此数据包长度值应为包括（压缩）报头的接收数据包的长度。
It is desirable for many cellular link layer technologies that bit rate variations and thus packet size variations are minimized. However, there will always be some variation in compressed header sizes since there is a trade-off between header size variations and compression efficiency, and also due to events in the header flow and
对于许多蜂窝链路层技术来说，期望比特率变化和分组大小变化最小化。然而，由于报头大小变化和压缩效率之间存在折衷，并且由于报头流中的事件和
on the channel. Variations in header sizes cause variations in packet sizes depending on variations of payload size. The following will only treat header size variations caused by ROHC and not packet size variations due to variations of payload size.
在频道上。报头大小的变化导致数据包大小的变化，这取决于有效负载大小的变化。以下内容仅处理ROHC引起的报头大小变化，而不处理因有效负载大小变化引起的数据包大小变化。
The link layer must in some manner support varying header sizes from 40 bytes (full RTP/UDP/IPv4 header) or 60 bytes (full RTP/UDP/IPv6) down to 1 byte for the minimal compressed header. It is likely that the small compressed headers dominate the flow of headers, and that the largest headers are sent rarely, e.g., only a few times in the initialization phase of the header compression scheme.
链路层必须以某种方式支持不同的报头大小，从40字节（完整RTP/UDP/IPv4报头）或60字节（完整RTP/UDP/IPv6）到最小压缩报头的1字节。小的压缩报头很可能主导报头流，而最大的报头很少发送，例如，在报头压缩方案的初始化阶段仅发送几次。
Header size variations and thus packet size variations depend on numerous factors. Unpredictable changes in the RTP, UDP or IP headers may cause compressed headers to momentarily increase in size, and header sizes may depend on packet loss rate at lower layers. Header size distributions depend also on the mode ROHC operates in. However, for e.g., a voice application, carried by RTP/UDP/IPv4, with a constant speech frame size and silence suppression, the following basic header size changes may be considered as typical:
报头大小变化和数据包大小变化取决于许多因素。RTP、UDP或IP报头中不可预测的变化可能会导致压缩报头的大小瞬间增加，并且报头大小可能取决于较低层的数据包丢失率。标头大小分布也取决于ROHC的工作模式。然而，例如，对于RTP/UDP/IPv4承载的语音应用程序，具有恒定的语音帧大小和静音抑制，以下基本报头大小变化可能被认为是典型的：
In the very beginning of the speech session, the ROHC scheme is initialized by sending full headers called IR/DYN. These are the largest headers, with sizes depending basically on the IP-version. For IPv4 the size is approximately 40 bytes, and for IPv6 approximately 60 bytes. The IR/DYN headers are used typically during one round trip time, possible interleaved with compressed headers. After that, usually only compressed headers are sent. Compressed headers may vary in size from 1 byte up to several bytes. The smallest compressed headers are used when there is no unpredictable changes in header fields, typically during a talk spurt. In the beginning of a talk spurt, compressed header sizes may increase by one or a few bytes momentarily. Apart from increases due to new talk spurts, compressed headers may increase in size momentarily due to unpredictable changes in header fields.
在语音会话的一开始，ROHC方案通过发送称为IR/DYN的完整报头进行初始化。这些是最大的报头，其大小基本上取决于IP版本。对于IPv4，大小约为40字节，对于IPv6，大小约为60字节。IR/DYN报头通常在一个往返时间内使用，可能与压缩报头交叉使用。之后，通常只发送压缩的头。压缩头的大小可能从1字节到几个字节不等。当报头字段中没有不可预测的更改时（通常在通话突发期间），使用最小的压缩报头。在通话开始时，压缩的报头大小可能会瞬间增加一个或几个字节。除了由于新的通话激增而增加外，由于报头字段的不可预测变化，压缩报头的大小可能会暂时增加。
ROHC provides some means to limit the amount of produced header sizes. In some cases a larger header than needed may be used to limit the number of header sizes used. Padding octets may also be used to fill up to a desired size. Chapter 6.3 (Implementation parameters) in [RFC3095] provides optional implementation parameters that make it possible to mandate how a ROHC implementation should operate, for instance to mandate how many header sizes that may be used.
ROHC提供了一些方法来限制产生的页眉大小。在某些情况下，可以使用大于所需的标题来限制使用的标题大小的数量。填充八位字节也可用于填充到所需的大小。[RFC3095]中的第6.3章（实施参数）提供了可选的实施参数，可以强制执行ROHC实施应如何运行，例如强制执行可使用的页眉大小。
ROHC has some parameters that need to be configured in an initial setup phase. Which header compression profiles are allowed may have to be determined and also what kind of context identification (CID) mechanism to use.
ROHC有一些参数需要在初始设置阶段进行配置。可能需要确定允许哪些头压缩配置文件，以及使用哪种上下文标识（CID）机制。
The lower layers supporting ROHC should thus include mechanisms for negotiation of header compression parameters such as CID usage and header compression profile support. In certain environments, it might also be desirable to have mechanisms for re-negotiation of these parameters.
因此，支持ROHC的较低层应包括用于协商报头压缩参数的机制，例如CID使用和报头压缩配置文件支持。在某些环境中，可能还需要有重新协商这些参数的机制。
The negotiation must also make sure that compressor and decompressor use exactly the same profile, i.e. that the set of profiles available after negotiation must not include two profile identifiers with the same 8-bit LSB value.
协商还必须确保压缩器和解压缩器使用完全相同的配置文件，即协商后可用的配置文件集不得包括具有相同8位LSB值的两个配置文件标识符。
For unidirectional links, this configuration might have to be performed out-of-band or a priori, and similar methods could of course also be used for bi-directional links if direct negotiation is not possible.
对于单向链路，此配置可能必须在带外或先验条件下执行，如果无法直接协商，则类似方法当然也可用于双向链路。
In some cellular technologies flows are demultiplexed onto radio bearers suitable to the particular flows, i.e., onto logically separated channels. For instance, real-time flows such as voice and video may be carried on logically separated bearers. It is recommended that this kind of demultiplexing is done in the lower layers supporting robust header compression. By doing so, the need for context identification in the header compression scheme is reduced. If there is a one to one mapping between flow and logical channel, there is no need at all for context identification at the header compression level.
在一些蜂窝技术中，流被解复用到适合于特定流的无线电承载上，即，到逻辑上分离的信道上。例如，诸如语音和视频之类的实时流可以在逻辑上分离的承载上进行。建议在支持健壮的报头压缩的较低层中执行这种解复用。通过这样做，减少了在报头压缩方案中对上下文识别的需要。如果流和逻辑通道之间存在一对一映射，则根本不需要在报头压缩级别进行上下文标识。
Header compression schemes like [RFC2507, RFC2508] have relied on the underlying link layer to identify different kinds of headers by means of packet type identifiers on link layers. This kind of mechanism is not necessarily needed for ROHC since a ROHC packet type identifier is included in all compressed ROHC headers. Only if ROHC packets are to be mixed with other packets, such as packets compressed by other header compression schemes, must the link layer provide a packet type identifier. In such cases, or if ROHC is used on top of link layers already providing packet type identification, one (1) packet type identifier must be reserved for identification of ROHC packets. Thus,
像[RFC2507，RFC2508]这样的报头压缩方案依赖于底层链路层，通过链路层上的包类型标识符来识别不同类型的报头。ROHC不一定需要这种机制，因为所有压缩的ROHC报头中都包含ROHC数据包类型标识符。只有当ROHC数据包与其他数据包（如通过其他报头压缩方案压缩的数据包）混合时，链路层才必须提供数据包类型标识符。在这种情况下，或者如果ROHC用于已经提供数据包类型标识的链路层之上，则必须保留一（1）个数据包类型标识符用于识别ROHC数据包。因此
only one ROHC packet type is needed to mix ROHC and e.g., RFC 2507 flows, or to support ROHC on links where packet type identifiers are already present.
只有一种ROHC数据包类型需要混合ROHC和RFC2507流，或者在已经存在数据包类型标识符的链路上支持ROHC。
Exact duplications of one and the same packet may waste transmission resources and is in contradiction to compression. Even so, packet duplication may occur for various reasons. Packet duplication may also occur in different places along the path for a packet.
同一数据包的精确复制可能会浪费传输资源，并与压缩相矛盾。即使如此，由于各种原因也可能发生数据包重复。数据包复制也可能发生在数据包路径上的不同位置。
ROHC can handle packet duplication before the compressor but such packet duplications should be avoided for optimal compression efficiency. For correct ROHC operation, lower layers are not allowed to duplicate packets on the ROHC compressor-decompressor path.
ROHC可以在压缩器之前处理数据包复制，但应避免此类数据包复制，以获得最佳压缩效率。对于正确的ROHC操作，不允许较低层在ROHC压缩机解压缩器路径上复制数据包。
Lower layers between compressor and decompressor are assumed not to reorder packets, i.e., the decompressor must receive packets in the same order as the compressor sends them. ROHC handles, however, reordering before the compression point. That is, there is no assumption that the compressor will only receive packets in sequence.
假定压缩器和解压缩器之间的较低层不会对数据包重新排序，即，解压缩器接收数据包的顺序必须与压缩器发送数据包的顺序相同。然而，ROHC处理在压缩点之前重新排序。也就是说，不存在压缩器仅按顺序接收分组的假设。
ROHC may operate in three different modes; Unidirectional mode (U-mode), bidirectional optimistic mode (O-mode) and bidirectional reliable mode (R-mode). A brief description of the modes can be found in chapter 4.4 of [RFC3095].
ROHC可在三种不同模式下运行；单向模式（U模式）、双向乐观模式（O模式）和双向可靠模式（R模式）。有关模式的简要说明，请参见[RFC3095]的第4.4章。
In U-mode it is not necessary to send any feedback from the decompressor to the compressor. O-mode and R-mode requires however that feedback messages from the decompressor to the compressor be sent. Feedback messages consist of small ROHC internal packets without any application payload. It is possible in ROHC to piggy-back feedback packets onto regular packets with ROHC compressed headers and payload, if there is ROHC type of compression in both the forward and reverse direction. However, this piggy-backing may not be desired or possible in some cases.
在U型模式下，无需从减压器向压缩机发送任何反馈。然而，O模式和R模式要求从减压器向压缩机发送反馈信息。反馈消息由小型ROHC内部数据包组成，没有任何应用程序负载。在ROHC中，如果正向和反向都有ROHC类型的压缩，则可以使用ROHC压缩头和有效负载将反馈数据包背驮到常规数据包上。然而，在某些情况下，这种背驮可能并不理想，也不可能。
To support ROHC O-mode or R-mode operation, lower layers must provide transport of feedback packets from decompressor to compressor. If piggybacking of feedback packets is not used, lower layers must be able to handle feedback as small stand-alone packets. For optimal compression efficiency, feedback packets from the decompressor should be delivered as soon as possible to the compressor.
为了支持ROHC O模式或R模式操作，较低层必须提供从解压器到压缩器的反馈数据包传输。如果不使用反馈数据包的背驮，则较低的层必须能够将反馈作为小型独立数据包处理。为了获得最佳压缩效率，应尽快将来自解压缩器的反馈数据包传送到压缩机。
An important group of link layer technologies where robust header compression will be needed are future cellular systems, which may have a very large number of users in some years. The need for header compression is large in these kinds of systems to achieve spectrum efficiency. Hence, it is important that future cellular systems can efficiently incorporate the robust header compression scheme.
一组重要的链路层技术需要鲁棒的报头压缩，这是未来的蜂窝系统，在某些年内可能会有大量的用户。在这类系统中，为了实现频谱效率，对报头压缩的需求很大。因此，重要的是未来的蜂窝系统能够有效地结合鲁棒的报头压缩方案。
One cellular specific property that may affect header compression is mobility and thus, handover (i.e., change of serving base station or radio network controller).
可能影响报头压缩的一个蜂窝特定属性是移动性，因此是切换（即，服务基站或无线网络控制器的改变）。
The main characteristics of handovers relevant for robust header compression are: the length of the longest packet loss event due to handover (i.e., the number of consecutive packet losses), and relocation of header compression context when necessary.
与健壮的报头压缩相关的切换的主要特征是：由于切换导致的最长分组丢失事件的长度（即，连续分组丢失的数量），以及必要时重新定位报头压缩上下文。
Depending on the location of the header compressor/decompressor in the radio access network and the type of handover, handover may or may not cause disruptions or packet loss events in the (compressed) header flow relevant for the header compression scheme. For instance, if soft handover is used and if the header compressor/decompressor reside above the combining point for soft handover, there will be no extra packet losses visible to the decompressor due to handover. In hard handovers, where packet loss events due to handover is introduced, the length of the longest consecutive packet loss is most relevant and thus should be minimized.
根据报头压缩器/解压缩器在无线接入网络中的位置和切换的类型，切换可能会或可能不会导致与报头压缩方案相关的（压缩的）报头流中的中断或分组丢失事件。例如，如果使用软切换，并且如果报头压缩器/解压缩器位于用于软切换的组合点之上，则解压缩器不会因切换而看到额外的分组丢失。在硬切换中，由于切换而引入分组丢失事件，最长的连续分组丢失的长度是最相关的，因此应该最小化。
To maintain efficient ROHC operation, it should be ensured that handover events do not cause significant long events of consecutive packet loss. The term "significant" in this context relates to the kind of loss tolerable for the carried real-time application.
为了维持有效的ROHC操作，应确保切换事件不会导致连续数据包丢失的重大长事件。在这种情况下，“重大”一词与实时应用可容忍的损失类型有关。
If hard handovers are performed, which may cause significant long events of consecutive packet loss, the radio access network should notify the compressor when such a handover has started and completed. The compressor could then be implemented to take proper actions and prevent consequences from such long loss events.
如果执行硬切换，这可能导致连续分组丢失的重大长事件，则无线接入网络应在此类切换开始和完成时通知压缩器。然后可实施压缩机，以采取适当措施，防止此类长期损失事件造成的后果。
Cellular systems supporting robust header compression may have internal mechanisms for transferring the header compression context between nodes where contexts may reside, at or before handover. If no such mechanism for transferring header compression context between nodes is available, the contexts may be resynchronized by the header
支持鲁棒报头压缩的蜂窝系统可以具有内部机制，用于在切换时或切换之前在上下文可能驻留的节点之间传输报头压缩上下文。如果没有用于在节点之间传输报头压缩上下文的这种机制可用，则可以由报头重新同步上下文
compression scheme itself by means of a context refresh. The header compressor will then perform a new header compression initialization, e.g., by sending full headers. This will, however, introduce an increase in the average header size dependent on how often a transfer of context is needed. To reinitialize the context in such cases, the lower layers must indicate to the header compressor when a handover has occurred, so that it knows when to refresh the context. Chapter 6.3 (Implementation parameters) in [RFC3095] provides optional implementation parameters that make it possible to trigger e.g., a complete context refresh.
通过上下文刷新压缩方案本身。然后，收割台压缩器将执行新的收割台压缩初始化，例如发送完整的收割台。然而，这将导致平均报头大小的增加，这取决于需要传输上下文的频率。为了在这种情况下重新初始化上下文，较低的层必须在发生切换时向报头压缩器指示，以便它知道何时刷新上下文。[RFC3095]中的第6.3章（实现参数）提供了可选的实现参数，可以触发例如完整的上下文刷新。
Section 3.1 states that ROHC requires error detection from lower layers for at least the compressed header. However, some cellular technologies may differentiate the amount of error detection for different parts of a packet. For instance, it could be possible to have a stronger error detection for the header part of a packet, if the application payload part of the packet is less sensitive to errors, e.g., some cellular types of speech codes.
第3.1节规定，ROHC要求从较低层至少对压缩头进行错误检测。然而，一些蜂窝技术可以区分分组的不同部分的错误检测量。例如，如果分组的应用有效载荷部分对错误（例如，某些蜂窝类型的语音代码）不太敏感，则可以对分组的报头部分具有更强的错误检测。
ROHC does not require UED from lower layers, ROHC requires only an error detection mechanism that detects errors in at least the header part of the packet. Thus there is no requirement on lower layers to provide separate error detection for the header and payload part of a packet. However, overall performance may be increased if UED is used.
ROHC不需要来自较低层的UED，ROHC只需要一个错误检测机制，该机制至少检测数据包头部分的错误。因此，在较低层上不需要为数据包的报头和有效负载部分提供单独的错误检测。但是，如果使用UED，则总体性能可能会提高。
For example, if equal error detection is used in the form of one link layer checksum covering the entire packet including both header and payload part, any bit error will cause the packet to be discarded at the ROHC decompressor. It is not possible to distinguish between errors in the header and the payload part of the packet with this error detection mechanism and the ROHC decompressor must assume that the header is damaged, even if the bit error hit the payload part of the packet. If the header is assumed to be damaged, it is not possible to ensure correct decompression and that packet will thus be discarded. If the application is such that it tolerates some errors in the payload, it could have been better to deliver that packet to the application and let the application judge whether the payload was usable or not. Hence, with an unequal error detection scheme where it is possible to separate detection of errors in the header and payload part of a packet, more packets may be delivered to applications in some cases for the same lower layer error rates. The final benefit depends of course on the cost of UED for the radio interface and related protocols.
例如，如果以一个链路层校验和的形式使用相等错误检测，该校验和覆盖整个分组，包括报头和有效负载部分，则任何比特错误都将导致分组在ROHC解压缩器处被丢弃。使用此错误检测机制无法区分报头中的错误和数据包的有效负载部分，ROHC解压器必须假设报头已损坏，即使误码击中数据包的有效负载部分。如果假定报头已损坏，则无法确保正确解压缩，因此该数据包将被丢弃。如果应用程序能够容忍有效负载中的某些错误，那么最好将该数据包交付给应用程序，并让应用程序判断有效负载是否可用。因此，利用不等错误检测方案，其中可以分离对分组的报头和有效载荷部分中的错误的检测，在某些情况下，可以以相同的低层错误率将更多分组交付给应用程序。最终的好处当然取决于无线接口和相关协议的UED成本。
Some cellular technologies can provide different error probabilities for different parts of a packet, unequal error protection (UEP). For instance, the lower layers may provide a stronger error protection for the header part of a packet compared to the payload part of the packet.
一些蜂窝技术可以为数据包的不同部分提供不同的错误概率，即不等错误保护（UEP）。例如，与分组的有效载荷部分相比，较低层可以为分组的报头部分提供更强的错误保护。
ROHC does not require UEP. UEP may be beneficial in some cases to reduce the error rate in ROHC headers, but only if it is possible to distinguish between errors in header and payload parts of a packet, i.e., only if unequal error detection (UED) is used. The benefit of UEP depends of course on the cost of UEP for the radio interface and related protocols.
ROHC不需要UEP。UEP在某些情况下可能有助于降低ROHC报头中的错误率，但前提是能够区分报头中的错误和数据包的有效负载部分，即，仅当使用不等错误检测（UED）时。UEP的好处当然取决于无线接口和相关协议的UEP成本。
A protocol which follows these guidelines, e.g., [RFC3095], will require the IANA to assign various numbers. This document by itself, however, does not require IANA involvement.
遵循这些准则的协议，例如[RFC3095]，将要求IANA分配各种号码。然而，本文件本身并不要求IANA参与。
A protocol which follows these guidelines, e.g., [RFC3095], must be able to compress packets containing IPSEC headers according to [RFC3096]. There may be other security aspects to consider in such protocols. This document by itself, however, does not add security risks.
遵循这些准则的协议，例如[RFC3095]，必须能够根据[RFC3096]压缩包含IPSEC头的数据包。在这些协议中可能需要考虑其他安全方面。然而，本文件本身并不增加安全风险。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509]Engan，M.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 2509，1999年2月。
[RFC3095] Borman, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "Robust Header Compression (ROHC)", RFC 3095, July 2001.
[RFC3095]Borman，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）”，RFC 3095，2001年7月。
[RFC3096] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RFC3096]Degermark，M.，“鲁棒IP/UDP/RTP报头压缩的要求”，RFC 3096，2001年7月。
Krister Svanbro Box 920 Ericsson AB SE-971 28 Lulea, Sweden
Krister Svanbro信箱920爱立信AB SE-971 28路利亚，瑞典
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@ericsson.com
Phone: +46 920 20 20 77
Fax: +46 920 20 20 99
EMail: krister.svanbro@ericsson.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。