Network Working Group L-E. Jonsson
Request for Comments: 4362 G. Pelletier
Obsoletes: 3242 K. Sandlund
Category: Standards Track Ericsson
January 2006
Network Working Group L-E. Jonsson
Request for Comments: 4362 G. Pelletier
Obsoletes: 3242 K. Sandlund
Category: Standards Track Ericsson
January 2006
RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
健壮的报头压缩（ROHC）：IP/UDP/RTP的链路层辅助配置文件
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User Datagram Protocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed in ROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format. This document is a replacement for RFC 3242, which it obsoletes.
本文件定义了用于压缩IP/UDP/RTP（互联网协议/用户数据报协议/实时传输协议）数据包的ROHC（鲁棒报头压缩）配置文件，利用较低层提供的功能，通过在优化操作期间完全消除大多数数据包的报头，提高压缩效率。该配置文件是作为ROHC RTP配置文件的扩展而构建的。它定义了ROHC中需要的其他机制，说明了辅助层的要求以保证透明度，并指定了与使用无报头数据包格式相关的压缩和解压缩的一般逻辑。本文件取代了已废弃的RFC 3242。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Differences from RFC 3242 ..................................5
2. Terminology .....................................................5
3. Overview of the Link-Layer Assisted Profile .....................6
3.1. Providing Packet Type Identification .......................7
3.2. Replacing the Sequence Number ..............................7
3.3. CRC Replacement ............................................8
3.4. Applicability of This Profile ..............................8
4. Additions and Exceptions Compared to ROHC RTP ...................9
4.1. Additional Packet Types ....................................9
4.1.1. No-Header Packet (NHP) ..............................9
4.1.2. Context Synchronization Packet (CSP) ................9
4.1.3. Context Check Packet (CCP) .........................11
4.2. Interfaces Towards the Assisting Layer ....................12
4.2.1. Interface, Compressor to Assisting Layer ...........13
4.2.2. Interface, Assisting Layer to Decompressor .........13
4.3. Optimistic Approach Agreement .............................14
4.4. Fast Context Initialization, IR Redefinition ..............15
4.5. Feedback Option, CV-REQUEST ...............................16
4.6. Periodic Context Verification .............................16
4.7. Use of Context Identifier .................................16
5. Implementation Issues ..........................................17
5.1. Implementation Parameters and Signals .....................17
5.1.1. Implementation Parameters at the Compressor ........17
5.1.2. Implementation Parameters at the Decompressor ......19
5.2. Implementation over Various Link Technologies .............19
6. IANA Considerations ............................................20
7. Security Considerations ........................................20
8. Acknowledgements ...............................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
1. Introduction ....................................................2
1.1. Differences from RFC 3242 ..................................5
2. Terminology .....................................................5
3. Overview of the Link-Layer Assisted Profile .....................6
3.1. Providing Packet Type Identification .......................7
3.2. Replacing the Sequence Number ..............................7
3.3. CRC Replacement ............................................8
3.4. Applicability of This Profile ..............................8
4. Additions and Exceptions Compared to ROHC RTP ...................9
4.1. Additional Packet Types ....................................9
4.1.1. No-Header Packet (NHP) ..............................9
4.1.2. Context Synchronization Packet (CSP) ................9
4.1.3. Context Check Packet (CCP) .........................11
4.2. Interfaces Towards the Assisting Layer ....................12
4.2.1. Interface, Compressor to Assisting Layer ...........13
4.2.2. Interface, Assisting Layer to Decompressor .........13
4.3. Optimistic Approach Agreement .............................14
4.4. Fast Context Initialization, IR Redefinition ..............15
4.5. Feedback Option, CV-REQUEST ...............................16
4.6. Periodic Context Verification .............................16
4.7. Use of Context Identifier .................................16
5. Implementation Issues ..........................................17
5.1. Implementation Parameters and Signals .....................17
5.1.1. Implementation Parameters at the Compressor ........17
5.1.2. Implementation Parameters at the Decompressor ......19
5.2. Implementation over Various Link Technologies .............19
6. IANA Considerations ............................................20
7. Security Considerations ........................................20
8. Acknowledgements ...............................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
Header compression is a technique used to compress and transparently decompress the header information of a packet on a per-hop basis, utilizing redundancy within individual packets and between consecutive packets within a packet stream. Over the years, several protocols [VJHC, IPHC] have been developed to compress the network and transport protocol headers [IPv4, IPv6, UDP, TCP], and these schemes have been successful in improving efficiency over many wired bottleneck links, such as modem connections over telephone networks. In addition to IP, UDP, and TCP compression, an additional compression scheme called Compressed RTP [CRTP] has been developed to
报头压缩是一种技术，用于在每跳的基础上压缩和透明地解压缩数据包的报头信息，利用数据包流中单个数据包内和连续数据包之间的冗余。多年来，已经开发了几种协议[VJHC，IPHC]来压缩网络和传输协议头[IPv4，IPv6，UDP，TCP]，这些方案成功地提高了许多有线瓶颈链路的效率，例如电话网络上的调制解调器连接。除了IP、UDP和TCP压缩之外，还开发了一种称为Compressed RTP[CRTP]的额外压缩方案，用于
improve compression efficiency further for real-time traffic using the Real-Time Transport Protocol [RTP].
使用实时传输协议[RTP]进一步提高实时流量的压缩效率。
The schemes mentioned above have all been designed by taking into account normal assumptions about link characteristics, which traditionally have been based on wired links only. However, with an increasing number of wireless links in the Internet paths, these assumptions are no longer generally valid. In wireless environments, especially wide-coverage cellular environments, relatively high error rates are tolerated in order to allow efficient usage of the radio resources. For real-time traffic, which is more sensitive to delays than to errors, such operating conditions will be norm over, for example, 3rd generation cellular links, and header compression must therefore tolerate packet loss. However, with the previously mentioned schemes, especially for real-time traffic compressed by CRTP, high error rates have been shown to significantly degrade header compression performance [CRTPC]. This problem was the driving force behind the creation of the RObust Header Compression (ROHC) WG in the IETF.
上述方案的设计均考虑了链路特性的正常假设，传统上仅基于有线链路。然而，随着互联网路径中无线链路数量的增加，这些假设不再普遍有效。在无线环境中，特别是宽覆盖蜂窝环境中，可以容忍相对较高的错误率，以便有效地使用无线电资源。对于对延迟比对错误更敏感的实时业务，此类操作条件将是正常的，例如，第三代蜂窝链路，因此报头压缩必须容忍数据包丢失。然而，对于前面提到的方案，特别是对于由CRTP压缩的实时流量，高错误率已经被证明会显著降低报头压缩性能[CRTPC]。这个问题是IETF中创建健壮头压缩（ROHC）工作组的驱动力。
The ROHC WG has developed a header compression framework on top of which profiles can be defined for different protocol sets, or for different compression strategies. Due to the limited packet-loss robustness of CRTP and the demands of the cellular industry for an efficient way of transporting voice over IP over wireless, the main focus of ROHC has so far been on compression of IP/UDP/RTP headers, which are generous in size, especially when compared to the payloads often carried by packets with such headers.
ROHC工作组开发了一个头部压缩框架，在此框架之上可以为不同的协议集或不同的压缩策略定义概要文件。由于CRTP的有限丢包鲁棒性以及蜂窝行业对通过无线通过IP传输语音的有效方式的需求，ROHC目前的主要关注点是IP/UDP/RTP报头的压缩，该报头的大小非常大，尤其是与具有此类报头的包通常携带的有效负载相比。
ROHC RTP has become a very efficient, robust, and capable compression scheme, able to compress the headers down to a total size of one octet only. Also, transparency is guaranteed to an extremely great extent, even when residual bit errors are present in compressed headers delivered to the decompressor. The requirements for RTP compression [RTP-REQ], defined by the WG before and during the development process, have thus been fulfilled.
ROHC-RTP已经成为一种非常高效、健壮、功能强大的压缩方案，能够将报头压缩到总大小仅为一个八位字节。此外，在很大程度上保证了透明度，即使在发送到解压缩器的压缩头中存在残余比特错误时也是如此。因此，工作组在开发过程之前和期间定义的RTP压缩要求[RTP-REQ]已得到满足。
As mentioned above, the 3rd generation cellular systems, where IP will be used end-to-end, have been one of the driving forces behind ROHC RTP, and the scheme has also been designed to suit new cellular air interfaces, such as WCDMA, making it possible to run even speech services with spectrum efficiency insignificantly lower than for existing one-service circuit switched solutions [VTC2000]. However, other air interfaces (such as those based on GSM and IS-95) will also be used in all-IP networks, with further implications for the header compression issue. These older air interfaces are less flexible, with radio bearers optimized for specific payload sizes. This means that not even a single octet of header can be added without using the
如上所述，IP将端到端使用的第三代蜂窝系统是ROHC RTP背后的驱动力之一，该方案也被设计为适应新的蜂窝空中接口，如WCDMA，使运行频谱效率比现有单业务电路交换解决方案低得多的语音服务成为可能[VTC2000]。然而，其他空中接口（例如基于GSM和IS-95的空中接口）也将用于所有IP网络，进一步影响报头压缩问题。这些老式的空中接口灵活性较差，无线电承载器针对特定的有效载荷尺寸进行了优化。这意味着，如果不使用
next higher fixed packet size supported by the link, something that is obviously very costly. For the already deployed speech vocoders, the spectrum efficiency over these links will thus be low compared to existing circuit-switched solutions. To achieve high spectrum efficiency overall with any application, more flexible air interfaces must be deployed, and then the ROHC RTP scheme will perform excellently, as shown for WCDMA [MOMUC01]. However, for deployment reasons, it is important to also provide a suitable header compression strategy for already existing vocoders and air interfaces, such as for GERAN and for CDMA2000, with minimal effects on spectral efficiency.
下一步，链路支持更高的固定数据包大小，这显然是非常昂贵的。对于已经部署的语音声码器，与现有的电路交换解决方案相比，这些链路上的频谱效率将较低。为了在任何应用中实现高频谱效率，必须部署更灵活的空中接口，然后ROHC RTP方案将表现出色，如WCDMA[MOMUC01]所示。然而，出于部署原因，还必须为现有声码器和空中接口（如GERAN和CDMA2000）提供合适的报头压缩策略，对频谱效率的影响最小。
This document describes a link-layer-assisted ROHC RTP profile, originally defined by [LLA], extending ROHC RTP (profile 0x0001) [ROHC], and compliant with the ROHC 0-byte requirements [0B-REQ]. The purpose of this profile is to provide a header-free packet format that, for a certain application behavior, can replace a majority of the 1-octet header ROHC RTP packets during normal U/O-mode operation, while still being fully transparent and complying with all the requirements of ROHC RTP [RTP-REQ]. For other applications, compression will be carried out as with normal ROHC RTP.
本文件描述了链路层辅助ROHC RTP配置文件，最初由[LLA]定义，扩展了ROHC RTP（配置文件0x0001）[ROHC]，并符合ROHC 0字节要求[0B-REQ]。该配置文件的目的是提供一种无报头的数据包格式，对于特定的应用行为，该格式可以在正常U/O模式操作期间替换大部分1-octet报头ROHC RTP数据包，同时仍然是完全透明的，并符合ROHC RTP[RTP-REQ]的所有要求。对于其他应用，压缩将与普通ROHC RTP一样进行。
To completely eliminate the compressed header, all functionality normally provided by the 1-octet header has to be provided by other means, typically by utilizing functionality provided by the lower layers and sacrificing efficiency for less-frequently occurring larger compressed headers. The latter is not a contradiction, since the argument for eliminating the last octet for most packets is not overall efficiency in general. It is important to remember that the purpose of this profile is to provide efficient matching of existing applications to existing link technologies, not efficiency in general. The additional complexity introduced by this profile, although minimized by a tight integration with already-existing ROHC functionality, implies that it should therefore only be used to optimize performance of specific applications over specific links.
为了完全消除压缩报头，通常由1-octet报头提供的所有功能必须通过其他方式提供，通常通过利用较低层提供的功能并牺牲发生频率较低的较大压缩报头的效率。后者并不矛盾，因为对于大多数数据包来说，消除最后一个八位字节的论点通常不是总体效率。重要的是要记住，此配置文件的目的是提供现有应用程序与现有链接技术的有效匹配，而不是总体效率。此配置文件引入的额外复杂性，虽然通过与现有ROHC功能的紧密集成而最小化，但意味着它只能用于优化特定链接上特定应用程序的性能。
When implementing this profile over various link technologies, care must be taken to guarantee that all the functionality needed is provided by ROHC and the lower layers together. Therefore, additional documents should specify how to incorporate this profile on top of various link technologies.
在通过各种链路技术实施此配置文件时，必须注意确保ROHC和较低层共同提供所需的所有功能。因此，其他文档应指定如何在各种链接技术之上合并此概要文件。
The profile defined by this document was originally specified by RFC 3242 [LLA], but to address one technical flaw and clarify one implementation issue, this document has been issued to replace RFC 3242, which becomes obsolete.
本文件定义的配置文件最初由RFC 3242[LLA]规定，但为了解决一个技术缺陷并澄清一个实施问题，发布本文件是为了替换已过时的RFC 3242。
This section briefly summarizes the differences of this document from RFC 3242. Acronyms and terminology can be found in Section 2.
本节简要总结了本文件与RFC 3242的不同之处。首字母缩略词和术语见第2节。
The format of the CSP packet, as defined in [LLA], was identified as non-interoperable when carrying a RHP header with a 3-bit or 7-bit CRC. This problem occurs because the payload has been dropped by the compressor, and the decompressor is supposed to use the payload length to infer certain fields in the uncompressed header. These fields are the IPv4 total length, the IPv6 payload length, the UDP length, and the IPv4 header checksum field (all INFERRED fields in [ROHC]). To correct this flaw, the CSP packet must carry information about the payload length of the RHP packet. Therefore, the length of the RTP payload has been included in the CSP packet.
[LLA]中定义的CSP数据包格式在携带带有3位或7位CRC的RHP报头时被确定为不可互操作。出现此问题是因为压缩程序丢弃了有效负载，而解压缩程序应该使用有效负载长度来推断未压缩标头中的某些字段。这些字段是IPv4总长度、IPv6有效负载长度、UDP长度和IPv4报头校验和字段（在[ROHC]中的所有推断字段）。要更正此缺陷，CSP数据包必须包含关于RHP数据包有效负载长度的信息。因此，RTP有效载荷的长度已经包括在CSP分组中。
This document also clarifies an unclear referencing in RFC 3242, where Section 4.1.3 of [LLA] states that upon CRC failure, the actions of [ROHC], Section 5.3.2.2.3 MUST be taken. That section specifies that detection of SN wraparound and local repair must be performed, but neither of these steps apply when the failing packet is a CCP. Therefore, upon CRC failure, actions to be taken are the ones specified in Section 5.3.2.2.3, but steps a-d only.
本文件还澄清了RFC 3242中的一个不明确引用，其中[LLA]第4.1.3节规定，一旦CRC故障，必须采取[ROHC]第5.3.2.2.3节中的措施。该部分规定必须执行SN环绕检测和本地修复，但当失败的数据包是CCP时，这两个步骤都不适用。因此，CRC故障时，应采取第5.3.2.2.3节规定的措施，但仅限于步骤a-d。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
CCP Context Check Packet CRC Cyclic Redundancy Check CSP Context Synchronization Packet LLA Link Layer Assisted ROHC RTP profile NHP No Header Packet ROHC RObust Header Compression RHP ROHC Header Packet (a non-NHP packet; i.e., RRP, CSP, or CCP) RRP ROHC RTP Packet as defined in [ROHC, profile 0x0001]
CCP上下文检查数据包CRC循环冗余检查CSP上下文同步数据包LLA链路层辅助ROHC RTP配置文件NHP无头数据包ROHC鲁棒头压缩RHP ROHC头数据包（非NHP数据包；即RRP、CSP或CCP）RRP ROHC RTP数据包，定义见[ROHC，配置文件0x0001]
Assisting layer
辅助层
"Assisting layer" refers to any entity implementing the interface to ROHC (Section 4.2). It may, for example, refer to a sub-layer used to adapt the ROHC implementation and the physical link layer. This layer is assumed to have knowledge of the physical layer synchronization.
“协助层”指实现ROHC接口的任何实体（第4.2节）。例如，它可以指用于适应ROHC实现和物理链路层的子层。假设该层了解物理层同步。
Compressing side
压缩侧
"Compressing side" refers to the combination of the header compressor, operating with the LLA profile, and its associated assisting layer.
“压缩侧”指与LLA剖面一起运行的集管压缩机及其相关辅助层的组合。
Lower layers
下层
"Lower layers", in this document, refers to entities located below ROHC in the protocol stack, including the assisting layer.
本文件中的“下层”指协议栈中ROHC下方的实体，包括辅助层。
ROHC RTP
ROHC RTP
"ROHC RTP" refers to the IP/UDP/RTP profile as defined in [ROHC].
“ROHC RTP”是指[ROHC]中定义的IP/UDP/RTP配置文件。
The ROHC IP/UDP/RTP profile defined in [LLA] and updated by this document, profile 0x0005 (hex), is designed to be used over channels that have been optimized for specific payload sizes and that therefore cannot efficiently accommodate header information when transmitted together with payloads corresponding to these optimal sizes.
[LLA]中定义并由本文件更新的ROHC IP/UDP/RTP配置文件，即配置文件0x0005（十六进制），设计用于已针对特定有效负载大小进行优化的信道，因此当与对应于这些最佳大小的有效负载一起传输时，无法有效容纳报头信息。
The LLA profile extends, and thus also inherits all functionality from, the ROCH RTP profile by defining some additional functionality and an interface from the ROHC component towards an assisting lower layer.
LLA配置文件扩展了ROCH RTP配置文件的所有功能，因此也继承了ROCH RTP配置文件的所有功能，通过定义一些附加功能和从ROHC组件到辅助底层的接口。
+---------------------------------------+
| |
The LLA | ROHC RTP, |
profile | Profile #1 +-----------------+
| | LLA Additions |
+---------------------+-----------------+
+---------------------------------------+
| |
The LLA | ROHC RTP, |
profile | Profile #1 +-----------------+
| | LLA Additions |
+---------------------+-----------------+
By imposing additional requirements on the lower layers compared to [ROHC], it is possible to infer the information needed to maintain robust and transparent header compression, even though the headers are completely eliminated during most of the operation time.
与[ROHC]相比，通过对较低层施加额外要求，可以推断出保持健壮和透明的报头压缩所需的信息，即使报头在大多数操作时间内被完全消除。
Basically, this profile replaces the smallest and most frequent ROHC U/O-mode headers with a no-header format, for which the header functionality must be provided by other means.
基本上，此配置文件将最小和最常见的ROHC U/O模式标头替换为无标头格式，必须通过其他方式提供标头功能。
Smallest header in Smallest header in
ROHC RTP (profile #1) LLA (profile #5)
+--+--+--+--+--+--+--+--+ ++
| 1 octet | -----> || No Header
+--+--+--+--+--+--+--+--+ ++
|
| Header field functionality
+-------------------> provided by other means
Smallest header in Smallest header in
ROHC RTP (profile #1) LLA (profile #5)
+--+--+--+--+--+--+--+--+ ++
| 1 octet | -----> || No Header
+--+--+--+--+--+--+--+--+ ++
|
| Header field functionality
+-------------------> provided by other means
The fields present in the ROHC RTP headers for U/O-mode PT0 are the packet type identifier, the sequence number, and the CRC. The subsequent sections elaborate more on how the functionality of these fields is replaced for NHP.
U/O模式PT0的ROHC RTP报头中存在的字段是数据包类型标识符、序列号和CRC。后续章节将详细介绍如何为NHP替换这些字段的功能。
All ROHC headers carry a packet type identifier, indicating to the decompressor how the header should be interpreted. This is a function that must be provided by some means in 0-byte header compression. It will be possible to distinguish ROHC RTP packets with compressed headers thanks to the packet type identifier, but a mechanism is needed to separate packets with a header from packets without a header. This function MUST therefore be provided by the assisting layer in one way or another.
所有ROHC报头都带有一个数据包类型标识符，向解压器指示如何解释报头。这是一个必须通过某种方式在0字节头压缩中提供的函数。由于数据包类型标识符，可以区分带有压缩头的ROHC RTP数据包，但需要一种机制将带有头的数据包与不带头的数据包分开。因此，该功能必须由辅助层以某种方式提供。
From the sending application, the RTP sequence number is increased by one for each packet sent. The purpose of the sequence number is to cope with packet reordering and packet loss. If reordering or loss has occurred before the transmission point, the compressing side, if needed, can easily avoid problems by not allowing the use of a header-free packet.
从发送应用程序，RTP序列号对于发送的每个数据包增加一个。序列号的目的是处理数据包重新排序和数据包丢失。如果在传输点之前发生了重新排序或丢失，则压缩端（如果需要）可以通过不允许使用无报头数据包来轻松避免问题。
However, at the transmission point, loss or reordering that may occur over the link can not be anticipated and covered for. Therefore, for NHP, the assisting layer MUST guarantee in-order delivery over the link (already assumed by [ROHC]), and at the receiving side, it MUST provide an indication for each packet loss over the link. This is basically the same principle as that which the VJ header compression [VJHC] relies on.
然而，在传输点，链路上可能发生的丢失或重新排序无法预期和覆盖。因此，对于NHP，辅助层必须保证链路上的有序交付（已由[ROHC]承担），并且在接收端，它必须提供链路上每个数据包丢失的指示。这与VJ头压缩[VJHC]所依赖的原理基本相同。
Note that guaranteeing in-order delivery and packet loss indication over the link not only makes it possible to infer the sequence number information, but also supersedes the main function of the CRC, which normally takes care of errors due to link losses and bit errors in the compressed sequence number.
注意，通过链路保证按序传送和分组丢失指示不仅可以推断序列号信息，而且还可以取代CRC的主要功能，CRC通常处理由于链路丢失和压缩序列号中的位错误引起的错误。
All context-updating RRP packets carry a CRC calculated over the uncompressed header. The CRC is used by the decompressor to verify that the updated context is correct. This verification serves three purposes in U/O-mode:
所有上下文更新RRP数据包都携带一个通过未压缩报头计算的CRC。解压缩程序使用CRC来验证更新的上下文是否正确。此验证在U/O模式下有三个目的：
1) Detection of longer losses than can be covered by the sequence number LSBs.
1) 检测比序列号LSB所能覆盖的更长的损耗。
2) Protection against failures caused by residual bit errors in compressed headers.
2) 针对压缩头中的残余位错误导致的故障提供保护。
3) Protection against faulty implementations and other causes of error.
3) 针对错误实现和其他错误原因提供保护。
Since this profile defines an NHP packet without this CRC, care must be taken to fulfill these purposes by other means when an NHP is used as a replacement for a context-updating packet. Detection of long losses (1) is already covered, since the assisting layer MUST provide an indication of all packet losses. Furthermore, the NHP packet has one important advantage over RHP packets in that residual bit errors (2) cannot damage a header that is not even sent.
由于此配置文件定义了一个没有此CRC的NHP数据包，因此当使用NHP作为上下文更新数据包的替换时，必须注意通过其他方式实现这些目的。由于辅助层必须提供所有数据包丢失的指示，因此长时间丢失（1）的检测已经包括在内。此外，与RHP分组相比，NHP分组具有一个重要的优点，即残余比特错误（2）不会损坏甚至未发送的报头。
It is thus reasonable to assume that compression and decompression transparency can be assured with high confidence, even without a CRC in header-free packets. However, to provide additional protection against damage propagation due to undetected residual bit errors in context-updating packets (2) or other unexpected errors (3), periodic context verifications SHOULD be performed (see Section 4.6).
因此，可以合理地假设，即使在无报头的分组中没有CRC，也可以以高置信度保证压缩和解压缩的透明性。然而，为了提供额外的保护，防止由于上下文更新数据包（2）中未检测到的残余位错误或其他意外错误（3）造成的损害传播，应定期进行上下文验证（见第4.6节）。
The LLA profile can be used with any link technology capable of providing the required functionality described in previous sections. Thus, whether LLA or ROHC RTP should be implemented depends on the characteristics of the link itself. For most RTP packet streams, LLA will work exactly as ROHC RTP, and it will have a higher compression efficiency for packet streams with certain characteristics. LLA will never have a lower compression efficiency than ROHC RTP.
LLA配置文件可与任何能够提供前几节所述功能的链路技术一起使用。因此，是否应该实施LLA或ROHC RTP取决于链路本身的特性。对于大多数RTP分组流，LLA将完全像ROHC RTP一样工作，并且对于具有特定特性的分组流，它将具有更高的压缩效率。LLA的压缩效率永远不会低于ROHC RTP。
Note as well that LLA, like all other ROHC profiles, is fully transparent to any packet stream reaching the compressor. LLA does not make any assumptions about the packet stream but will perform optimally for packet streams with certain characteristics, e.g., synchronized streams exactly timed with the assisting link over which the LLA profile is implemented.
还要注意的是，LLA和所有其他ROHC配置文件一样，对到达压缩器的任何数据包流都是完全透明的。LLA不对分组流进行任何假设，但将对具有特定特征的分组流进行最佳执行，例如，与实施LLA简档的辅助链路精确定时的同步流。
The LLA profile is obviously not applicable if the UDP checksum (2 bytes) is enabled, which is always the case for IPv6/UDP. For IPv4/UDP, the sender may choose to disable the UDP checksum.
如果启用了UDP校验和（2个字节），LLA配置文件显然不适用，IPv6/UDP总是如此。对于IPv4/UDP，发送方可以选择禁用UDP校验和。
The LLA profile defines three new packet types to be used in addition to the RRP packet types defined by [ROHC]. The following sections describe these packet types and their purpose in detail.
除了[ROHC]定义的RRP数据包类型外，LLA配置文件还定义了三种新的数据包类型。以下各节详细描述了这些数据包类型及其用途。
A No-Header Packet (NHP) is a packet that consists only of the payload of the original packet. The NHP MAY be used when only the sequence information needs to be conveyed to the decompressor. In other words, the NHP can be used when all header fields are either unchanged or follow the currently established change pattern. In addition, there are some considerations for the use of the NHP (see sections 4.3, 4.5, and 4.6). An LLA compressor is not allowed to deliver NHP packets when operating in R-mode.
无报头分组（NHP）是仅由原始分组的有效载荷组成的分组。当仅需要将序列信息传送到解压缩器时，可以使用NHP。换言之，当所有头字段都未更改或遵循当前建立的更改模式时，可以使用NHP。此外，NHP的使用也有一些考虑因素（见第4.3、4.5和4.6节）。在R模式下运行时，不允许LLA压缩器传送NHP数据包。
The assisting layer MAY send the NHP for RTP SN = X only if an NHP was delivered by the LLA compressor AND the assisting layer can guarantee that the decompressor will infer the proper sequencing for this NHP. This guarantee is based on the confidence that the decompressor
仅当LLA压缩机交付NHP时，辅助层可发送RTP SN=X的NHP，且辅助层可保证减压器将推断该NHP的正确顺序。此保证基于减压器
a) has the means to infer proper sequencing for the packet corresponding to SN = X-1, AND
a) 具有为对应于SN＝X-1的分组推断适当序列的方法，并且
b) has either received a loss indication or the packet itself for the packet corresponding to SN = X-1.
b) 已接收到与SN＝X-1对应的分组的丢失指示或分组本身。
Updating properties: NHP packets update context (RTP Sequence Number).
更新属性：NHP数据包更新上下文（RTP序列号）。
The case where the packet stream overruns the channel bandwidth may lead to discarded data, which may result in decompressor context invalidation. It might therefore be beneficial to send a packet with only the header information and to discard the payload. This would be helpful to maintain synchronization of the decompressor context while efficiently using the available bandwidth.
分组流超过信道带宽的情况可能导致丢弃的数据，这可能导致解压缩器上下文失效。因此，发送仅包含报头信息的数据包并丢弃有效负载可能是有益的。这将有助于在有效使用可用带宽的同时保持解压器上下文的同步。
This case can be handled with the Context Synchronization Packet (CSP), which has the following format:
可以使用上下文同步数据包（CSP）处理这种情况，该数据包具有以下格式：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 0 | Packet type identifier
+===+===+===+===+===+===+===+===+
/ RTP Payload Length / 2 octets
+---+---+---+---+---+---+---+---+
: ROHC header without padding :
: see [ROHC, Section 5.7] :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 0 | Packet type identifier
+===+===+===+===+===+===+===+===+
/ RTP Payload Length / 2 octets
+---+---+---+---+---+---+---+---+
: ROHC header without padding :
: see [ROHC, Section 5.7] :
+---+---+---+---+---+---+---+---+
RTP Payload Length: This field is the length of the payload carried inside the RTP header, stored in network byte order. That is, this field will be set by the compressor to (UDP length - size of the UDP header - size of the RTP header including CSRC identifiers).
RTP Payload Length（RTP有效负载长度）：该字段是RTP报头中承载的有效负载的长度，以网络字节顺序存储。也就是说，此字段将由压缩器设置为（UDP长度-UDP标头的大小-RTP标头的大小，包括CSC标识符）。
Updating properties: CSP maintains the updating properties of the ROHC header it carries.
更新属性：CSP维护其携带的ROHC头的更新属性。
The CSP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the one-octet base header. As for any ROHC packet, except the NHP, the packet may begin with ROHC padding and/or feedback. It may also carry context identification after the packet type identifier. It is possible to have two CID fields present, one after the packet type ID and one within the encapsulated ROHC header. If a decompressor receives a CSP with two non-equal CID values included, the packet MUST be discarded. ROHC segmentation may also be applied to the CSP.
CSP由ROHC RTP中的一个未使用的包类型标识符定义，该标识符携带在一个八位字节的基本报头中。对于除NHP之外的任何ROHC数据包，该数据包可以以ROHC填充和/或反馈开始。它还可以在包类型标识符之后携带上下文标识。可能存在两个CID字段，一个位于数据包类型ID之后，另一个位于封装的ROHC报头内。如果解压器接收到包含两个不相等CID值的CSP，则必须丢弃该数据包。ROHC分段也可应用于CSP。
In the CSP packet, the payload has been dropped by the compressor. However, the decompressor is supposed to use the payload length to infer certain fields in the uncompressed header (the IPv4 total length, the IPv6 payload length, the UDP length, and the IPv4 header checksum field). When dropping the payload, the CSP packet needs to contain information about the payload length carried in the RHP packet. Therefore, the length of the RTP payload is carried in the CSP packet. When the decompressor receives a CSP packet, it can use the RTP payload length field to calculate the value of fields classified as INFERRED in [ROHC] when attempting to verify a 3- or 7-bit CRC carried in the RHP header enclosed in the CSP.
在CSP数据包中，有效负载已被压缩器丢弃。但是，解压器应该使用有效负载长度推断未压缩标头中的某些字段（IPv4总长度、IPv6有效负载长度、UDP长度和IPv4标头校验和字段）。当丢弃有效负载时，CSP数据包需要包含关于RHP数据包中承载的有效负载长度的信息。因此，RTP有效载荷的长度被携带在CSP分组中。当解压器接收到CSP数据包时，当试图验证CSP中包含的RHP报头中携带的3位或7位CRC时，它可以使用RTP有效负载长度字段来计算[ROHC]中推断的字段值。
Note that when the decompressor has received and processed a CSP, the packet (including any possible data following the CSP encapsulated compressed header) MUST be discarded.
请注意，当解压缩程序接收并处理CSP时，必须丢弃该数据包（包括CSP封装的压缩头之后的任何可能数据）。
A Context Check Packet (CCP), which does not carry any payload but only an optional CRC value in addition to the packet type identifier, is defined.
定义了一个上下文检查数据包（CCP），它不携带任何有效载荷，但除了数据包类型标识符之外，只携带可选的CRC值。
The purpose of the CCP is to provide a useful packet that MAY be sent by a synchronized physical link layer in the case where data must be sent at fixed intervals, even if no compressed packet is available. Whether the CCP is sent over the link and delivered to the decompressor is decided by the assisting layer. The CCP has the following format:
CCP的目的是提供在数据必须以固定间隔发送的情况下，即使没有可用的压缩分组，也可由同步物理链路层发送的有用分组。CCP是否通过链路发送并交付给解压缩器由辅助层决定。CCP的格式如下：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 1 | Packet type identifier
+===+===+===+===+===+===+===+===+
| C | CRC |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 1 1 | Packet type identifier
+===+===+===+===+===+===+===+===+
| C | CRC |
+---+---+---+---+---+---+---+---+
C: C = 0 indicates that the CRC field is not used. C = 1 indicates that a valid CRC is present.
C:C=0表示未使用CRC字段。C=1表示存在有效的CRC。
Updating properties: CCP packets do not update context.
更新属性：CCP数据包不更新上下文。
The CCP is defined by one of the unused packet type identifiers from ROHC RTP, carried in the first octet of the base header. The first bit of the second octet, the C bit, indicates whether the CRC field is used. If C=1, the CRC field MUST be set to the 7-bit CRC calculated over the original uncompressed header defined in [ROHC, Section 5.9.2]. As for any ROHC packet, except NHP, the packet MAY begin with ROHC padding and/or carry context identification.
CCP由ROHC RTP中的一个未使用的包类型标识符定义，该标识符携带在基本报头的第一个八位组中。第二个八位字节的第一位，即C位，指示是否使用CRC字段。如果C=1，则必须将CRC字段设置为在[ROHC，第5.9.2节]中定义的原始未压缩头上计算的7位CRC。对于除NHP之外的任何ROHC数据包，该数据包可以以ROHC填充和/或携带上下文标识开始。
The use of the CRC field to perform decompressor context verification is optional and is therefore a compressor implementation issue. However, a CCP MUST always be made available to the assisting layer.
使用CRC字段执行解压缩器上下文验证是可选的，因此是一个压缩程序实现问题。但是，必须始终向辅助层提供CCP。
If the assisting layer receives CCPs with the C bit set (C=1) from the compressor, it MUST use the last CCP received if a CCP is to be sent, i.e., the CCP corresponding to the last non-CCP packet sent (NHP, RRP or CSP). An assisting layer MAY use the CCP for other purposes, such as signaling a packet loss before the link.
如果辅助层从压缩器接收到C位设置为（C=1）的CCP，则如果要发送CCP，则必须使用接收到的最后一个CCP，即与发送的最后一个非CCP数据包（NHP、RRP或CSP）相对应的CCP。辅助层可以将CCP用于其他目的，例如在链路之前发送分组丢失信号。
The decompressor is REQUIRED to handle a CCP received with the C bit set (C=1), indicating a valid CRC field, and to perform context verification. The received CRC MUST then be applied to the last decompressed packet, unless a packet loss indication was previously received. Upon CRC failure, actions MUST be taken as specified in
解压器需要处理用C位集（C=1）接收的CCP，指示有效的CRC字段，并执行上下文验证。然后，必须将接收到的CRC应用于最后一个解压缩的数据包，除非先前接收到数据包丢失指示。CRC故障时，必须按照中的规定采取措施
[ROHC, Section 5.3.2.2.3, steps a-d only]. A CCP received with C=0 MUST be ignored by the decompressor. The decompressor is not allowed to make any further interpretation of the CCP.
[ROHC，第5.3.2.2.3节，仅步骤a-d]。解压缩程序必须忽略接收到的C=0的CCP。不允许减压器对CCP进行任何进一步解释。
When using the 7-bit CRC in the CCP packet to verify the context, the decompressor needs to have access to the entire uncompressed header of the latest packet decompressed. Some implementations of [ROHC] might not save the values of INFERRED fields. An implementation of ROHC LLA MUST save these fields in the decompressor context to be able to successfully verify CCP packets.
当在CCP数据包中使用7位CRC来验证上下文时，解压器需要访问最新解压数据包的整个未压缩报头。[ROHC]的某些实现可能无法保存推断字段的值。ROHC LLA的实现必须将这些字段保存在解压器上下文中，才能成功验证CCP数据包。
The use of CCP by an assisting layer is optional and depends on the characteristics of the actual link. Whether it is used MUST therefore be specified in link-layer implementation specifications for this profile.
辅助层使用CCP是可选的，取决于实际链路的特性。因此，必须在该配置文件的链接层实现规范中指定是否使用它。
This profile relies on the lower layers to provide the necessary functionality to allow NHP packets to be sent. This interaction between LLA and the assisting layer is defined as interfaces between the LLA compressor/decompressor and the LLA applicable link technology.
此配置文件依赖于较低层提供必要的功能，以允许发送NHP数据包。LLA和辅助层之间的这种相互作用被定义为LLA压缩机/减压器和LLA适用链路技术之间的接口。
| |
+ +
+-------------------------+ +-------------------------+
| ROHC RTP HC | | ROHC RTP HD |
+-------------------------+ +-------------------------+
| LLA profile | | LLA profile |
+=========================+ +=========================+
| Interface | | Interface |
| ROHC to assisting layer | | Assisting layer to ROHC |
+=========================+ +=========================+
| Applicable | | Applicable |
| link technology | | link technology |
+=========================+ +=========================+
| |
+------>---- CHANNEL ---->-----+
| |
+ +
+-------------------------+ +-------------------------+
| ROHC RTP HC | | ROHC RTP HD |
+-------------------------+ +-------------------------+
| LLA profile | | LLA profile |
+=========================+ +=========================+
| Interface | | Interface |
| ROHC to assisting layer | | Assisting layer to ROHC |
+=========================+ +=========================+
| Applicable | | Applicable |
| link technology | | link technology |
+=========================+ +=========================+
| |
+------>---- CHANNEL ---->-----+
The figure above shows the various levels, as defined in [ROHC] and this document, constituting a complete implementation of the LLA profile. The figure also underlines the need for additional documents to specify how to implement these interfaces for a link technology for which this profile is relevant.
上图显示了[ROHC]和本文件中定义的各种级别，构成LLA配置文件的完整实现。该图还强调了需要额外的文档来指定如何为与此概要文件相关的链接技术实现这些接口。
This section defines the information to be exchanged between the LLA compressor and the assisting layer for this profile to operate
本节定义了LLA压缩机和辅助层之间要交换的信息，以便该剖面运行
properly. While it does define semantics, it does not specify how these interfaces are to be implemented.
正确地虽然它定义了语义，但没有指定如何实现这些接口。
This section defines the interface semantics between the compressor and the assisting layer, providing rules for packet delivery from the compressor.
本节定义压缩器和辅助层之间的接口语义，为压缩器的数据包传递提供规则。
The interface defines the following parameters: RRP, RRP segmentation flag, CSP, CSP segmentation flag, NHP, and RTP Sequence Number. All parameters, except the NHP, MUST always be delivered to the assisting layer. This leads to two possible delivery scenarios:
接口定义以下参数：RRP、RRP分段标志、CSP、CSP分段标志、NHP和RTP序列号。所有参数（NHP除外）必须始终传送到辅助层。这导致两种可能的交付场景：
a. RRP, CSP, CCP, NHP, and RTP Sequence Number are delivered, along with the corresponding segmentation flags, set accordingly.
a. 交付RRP、CSP、CCP、NHP和RTP序列号，并相应设置相应的分段标志。
This corresponds to the case when the compressor allows sending of an NHP packet, with or without segmentation applied to the corresponding RRP/CSP packets.
这对应于当压缩器允许发送NHP分组时的情况，对相应的RRP/CSP分组应用或不应用分段。
Recall that delivery of an NHP packet occurs when the ROHC RTP compressor would have used a ROHC UO-0.
回想一下，当ROHC RTP压缩器使用ROHC UO-0时，会发生NHP数据包的交付。
b. RRP, CSP, CCP, and RTP Sequence Number are delivered, along with the corresponding segmentation flags, set accordingly.
b. 交付RRP、CSP、CCP和RTP序列号，并相应设置相应的分段标志。
This corresponds to the case when the compressor does not allow sending of an NHP packet. Segmentation might be applied to the corresponding RRP and CSP packets.
这对应于压缩器不允许发送NHP分组的情况。分段可应用于相应的RRP和CSP数据包。
Segmentation may be applied independently to an RRP or a CSP packet if its size exceeds the largest value provided in the PREFERRED PACKET_SIZES list and if the LARGE_PACKET_ALLOWED parameter is set to false. The segmentation flags are explicitly stated in the interface definition to emphasize that the RRP and the CSP may be delivered by the compressor as segmented packets.
如果RRP或CSP数据包的大小超过首选数据包大小列表中提供的最大值，并且如果允许的大数据包参数设置为false，则分段可以独立地应用于RRP或CSP数据包。在接口定义中明确说明分段标志，以强调RRP和CSP可以作为分段分组由压缩器交付。
The RTP SN MUST be delivered for each packet by the compressor to allow the assisting layer to maintain the necessary sequencing information.
RTP SN必须由压缩器为每个分组传送，以允许辅助层维护必要的序列信息。
Here the interface semantics between the assisting layer and the decompressor are defined, providing simple rules for the delivery of received packets to the decompressor. The decompressor needs a way
这里定义了辅助层和解压器之间的接口语义，为将接收到的数据包传递给解压器提供了简单的规则。解压器需要一种方法
to distinguish NHP packets from RHP packets. Also, when receiving packets without a header, the decompressor needs a way to infer the sequencing information to keep synchronization between the received payload and the sequence information of the decompressed headers. To achieve this, the decompressor MUST receive the following from the assisting layer:
区分NHP数据包和RHP数据包。此外，当接收没有报头的分组时，解压缩器需要一种方法来推断序列信息，以保持所接收的有效载荷和解压缩报头的序列信息之间的同步。为了实现这一点，解压器必须从辅助层接收以下信息：
- an indication for each packet loss over the link between the compressing and decompressing sides for CID=0.
- CID=0时，压缩侧和解压缩侧之间链路上每个数据包丢失的指示。
- the received packet together with an indication of whether the packet received is an NHP.
- 接收到的分组以及接收到的分组是否为NHP的指示。
Note that the context is updated from a packet loss indication.
注意，上下文是根据数据包丢失指示更新的。
ROHC defines an optimistic approach for updates to reduce the header overhead. This approach is fully exploited in the Optimistic and Unidirectional modes of operation. Due to the presence of a CRC in all compressed headers, the optimistic approach is defined as a compressor issue only because the decompressor will always be able to detect an invalid context through the CRC verification.
ROHC定义了一种乐观的更新方法，以减少报头开销。这种方法在乐观和单向操作模式下得到充分利用。由于所有压缩头中都存在CRC，乐观方法被定义为压缩问题，因为解压器始终能够通过CRC验证检测到无效上下文。
However, no CRC is present in the NHP packet defined by the LLA profile. Therefore, the loss of an RHP packet updating the context may not always be detected. To avoid this problem, the compressing and decompressing sides must agree on the principles for the optimistic approach, and the agreed principles MUST be enforced not only by the compressor but also by the transmitting assisting layer. If, for example, three consecutive updates are sent to convey a header field change, the decompressor must know this and invalidate the context if three or more consecutive physical packets are lost. Note that the mechanism used to enforce the optimistic approach must be reinitialized if a new field change needs to be conveyed while the compressing side is already sending packets to convey non-linear context updates.
但是，LLA配置文件定义的NHP数据包中不存在CRC。因此，可能并不总是检测到更新上下文的RHP分组的丢失。为避免此问题，压缩和解压缩双方必须就乐观方法的原则达成一致，并且不仅压缩机必须执行一致的原则，传输辅助层也必须执行一致的原则。例如，如果发送了三个连续的更新以传递报头字段更改，则解压缩器必须知道这一点，并且如果丢失了三个或更多连续的物理数据包，则上下文将无效。请注意，如果在压缩端已经发送数据包以传输非线性上下文更新时需要传输新的字段更改，则必须重新初始化用于实施乐观方法的机制。
An LLA decompressor MUST use the optimistic approach knowledge to detect possible context loss events. If context loss is suspected, it MUST invalidate the context and not forward any packets before the context has been synchronized.
LLA解压器必须使用乐观方法知识来检测可能的上下文丢失事件。如果怀疑上下文丢失，它必须使上下文无效，并且在同步上下文之前不转发任何数据包。
It is REQUIRED that all documents describing how the LLA profile is implemented over a certain link technology define how the optimistic approach is agreed to between the compressing side and the decompressing side. It could be handled with a fixed principle, with
要求所有描述LLA配置文件如何在特定链路技术上实现的文档定义如何在压缩侧和解压缩侧之间商定乐观方法。它可以用一个固定的原则来处理
negotiation at startup, or by other means, but the method must be unambiguously defined.
启动时协商，或通过其他方式协商，但方法必须明确定义。
As initial IR packets might overrun the channel bandwidth and significantly delay decompressor context establishment, it might be beneficial to initially discard the payload. This allows state transitions and higher compression efficiency to be achieved with minimal delay.
由于初始IR数据包可能会超出信道带宽并显著延迟解压器上下文的建立，因此最初丢弃有效负载可能是有益的。这允许以最小的延迟实现状态转换和更高的压缩效率。
To serve this purpose, the D-bit from the basic structure of the ROHC RTP IR packet [ROHC, Section 5.7.7.1] is redefined for the LLA profile. For D=0 (no dynamic chain), the meaning of the D-bit is extended to indicate that the payload has been discarded when assembling the IR packet. All other fields keep their meanings as defined for ROHC RTP.
为了达到这一目的，针对LLA配置文件重新定义了ROHC RTP IR数据包基本结构[ROHC，第5.7.7.1节]中的D位。对于D＝0（无动态链），扩展D位的含义以指示在组装IR分组时有效载荷已被丢弃。所有其他字段的含义与ROHC RTP的定义相同。
The resulting structure, using small CIDs and CID=0, becomes:
使用小CID和CID=0得到的结构变为：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 1 | 0 | D |
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| Static | variable length
| chain |
- - - - - - - - - - - - - - - -
| Dynamic | not present if D = 0
| chain | present if D = 1, variable length
- - - - - - - - - - - - - - - -
| Payload | not present if D = 0
| | present if D = 1, variable length
- - - - - - - - - - - - - - - -
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 1 | 0 | D |
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| Static | variable length
| chain |
- - - - - - - - - - - - - - - -
| Dynamic | not present if D = 0
| chain | present if D = 1, variable length
- - - - - - - - - - - - - - - -
| Payload | not present if D = 0
| | present if D = 1, variable length
- - - - - - - - - - - - - - - -
D: D = 0 indicates that the dynamic chain is not present and that the payload has been discarded.
D:D=0表示动态链不存在，有效负载已被丢弃。
After an IR packet with D=0 has been processed by the decompressor, the packet MUST be discarded.
解压器处理D=0的IR数据包后，必须丢弃该数据包。
The CV-REQUEST option MAY be used by the decompressor to request an RRP or CSP for context verification. This option should be used if only NHPs have been received for a long time and the context therefore has not been verified recently.
解压器可以使用CV-REQUEST选项请求RRP或CSP进行上下文验证。如果只有NHP已经收到很长一段时间，因此最近未验证上下文，则应使用此选项。
+---+---+---+---+---+---+---+---+
| Opt Type = 8 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| Opt Type = 8 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
If the compressor receives a feedback packet with this option, the next packet compressed SHOULD NOT be delivered to the assisting layer as an NHP.
如果压缩器使用此选项接收到反馈数据包，则下一个压缩数据包不应作为NHP发送到辅助层。
As described in Section 3.3, transparency is expected to be guaranteed by the functionality provided by the lower layers. This ROHC profile would therefore be at least as reliable as the older header compression schemes [VJHC, IPHC, CRTP], which do not make use of a header compression CRC. However, since ROHC RTP normally is extremely safe to use from a transparency point of view, it would be desirable to be able to achieve this with LLA also.
如第3.3节所述，较低层提供的功能有望保证透明度。因此，该ROHC配置文件至少与旧的报头压缩方案[VJHC、IPHC、CRTP]一样可靠，后者不使用报头压缩CRC。然而，由于从透明度的角度来看，ROHC RTP的使用通常是非常安全的，因此也希望能够通过LLA实现这一点。
To provide an additional guarantee for transparency and also catch unexpected errors, such as errors due to faulty implementations, it is RECOMMENDED that context updating packets be sent periodically, even when the compressor logic allows NHP packets to be used.
为了提供额外的透明度保证并捕获意外错误，例如由于错误实现而导致的错误，建议定期发送上下文更新数据包，即使压缩器逻辑允许使用NHP数据包。
Since an NHP cannot carry a context identifier (CID), there is a restriction on how this profile may be used, related to context identification. Independent of which CID size has been negotiated, NHP packets can only be used for CID=0. If the decompressor receives an NHP packet, it can only belong to CID=0.
由于NHP不能携带上下文标识符（CID），因此对如何使用该配置文件有一个与上下文标识相关的限制。与已协商的CID大小无关，NHP数据包只能用于CID=0。如果解压缩程序接收到NHP数据包，则它只能属于CID=0。
Note that if multiple packet streams are handled by a compressor operating using LLA, the assisting layer must, in case of physical packet loss, be able to tell for which CID the loss occurred, or at least it MUST be able to tell if packets with CID=0 (packet stream with NHPs) have been lost.
注意，如果多个分组流由使用LLA操作的压缩器处理，则在物理分组丢失的情况下，辅助层必须能够辨别发生丢失的CID，或者至少它必须能够辨别CID=0的分组（具有NHPs的分组流）是否已经丢失。
This document specifies mechanisms for the protocol and leaves details on the use of these mechanisms to the implementers. The present section aims to provide guidelines, ideas, and suggestions for implementation of LLA.
本文档指定了协议的机制，并将这些机制的使用细节留给实现者。本节旨在为LLA的实施提供指导方针、想法和建议。
As described in [ROHC, Section 6.3], implementations use parameters to set up configuration information and to stipulate how a ROHC implementation is to operate. The following parameters are additions, useful to LLA, to the parameter set defined for ROHC RTP implementations. Note that if the PREFERRED_PACKET_SIZES parameters defined here are used, they obsolete all PACKET_SIZE and PAYLOAD_SIZE parameters of ROHC RTP.
如[ROHC，第6.3节]所述，实施使用参数设置配置信息，并规定ROHC实施的操作方式。以下参数是为ROHC RTP实现定义的参数集的补充，对LLA很有用。请注意，如果使用此处定义的首选_数据包_大小参数，则它们将淘汰ROHC RTP的所有数据包_大小和有效负载_大小参数。
ALWAYS_PAD -- value: boolean
始终\u PAD--值：布尔值
This parameter may be set by an external entity to specify to the compressor that every RHP packet MUST be padded with ROHC padding of one octet, minimum.
该参数可由外部实体设置，以向压缩器指定每个RHP数据包必须填充至少一个八位字节的ROHC填充。
The assisting layer MUST provide a packet type identification. If no field is available for this purpose from the protocol at the link layer, then a leading sequence may be used to distinguish RHP packets from NHP packets. Although the use of a leading sequence is obviously not efficient, since it sacrifices efficiency for RHP packets, the efficiency loss should be insignificant because the leading sequence applies only to packets with headers in order to favor the use of packets without headers. If a leading sequence is desired for RHP identification, the lower layer MAY use ROHC padding for the leading sequence by setting the ALWAYS_PAD parameter. Note that in such cases, possible collisions of the padding with the NHP payload must be avoided.
辅助层必须提供数据包类型标识。如果链路层的协议中没有用于此目的的字段，则可以使用前导序列来区分RHP分组和NHP分组。虽然前导序列的使用显然不是有效的，因为它牺牲了RHP数据包的效率，但是效率损失应该是微不足道的，因为前导序列仅适用于具有报头的数据包，以便有利于使用没有报头的数据包。如果需要一个前导序列用于RHP识别，下层可以通过设置ALWAYS_PAD参数为前导序列使用ROHC填充。注意，在这种情况下，必须避免填充物和NHP有效载荷可能发生的碰撞。
By default, this parameter is set to FALSE.
默认情况下，此参数设置为FALSE。
PREFERRED_PACKET_SIZES -- list of:
SIZE -- value: integer (octets)
RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION]
PREFERRED_PACKET_SIZES -- list of:
SIZE -- value: integer (octets)
RESTRICTED_TYPE -- values: [NHP_ONLY, RHP_ONLY, NO_RESTRICTION]
This parameter set governs which packet sizes are preferred by the assisting layer. If this parameter set is used, all RHP packets MUST be padded to fit the smallest possible preferred size. If the size of the unpadded packet (or, in the case of ALWAYS_PAD
此参数集控制辅助层首选的数据包大小。如果使用此参数集，则必须填充所有RHP数据包以适合最小的可能首选大小。如果未添加的数据包的大小（或者，如果是ALWAYS_PAD
being set, the packet with minimal one-octet padding) is larger than the maximal preferred packet size, the compressor has two options. Either it may deliver this larger packet with an arbitrary size, or it may split the packet into several segments using ROHC segmentation and pad each segment to one of the preferred sizes. Which method to use depends on the value of the LARGE_PACKETS_ALLOWED parameter below.
设置后，具有最小一个八位组填充的数据包大于最大首选数据包大小，压缩器有两个选项。它可以传送任意大小的较大数据包，也可以使用ROHC分段将数据包分割成几个段，并将每个段填充到首选大小之一。使用哪种方法取决于下面允许的大数据包参数的值。
NHP packets can be delivered to the lower layer only if the payload size is part of the preferred packet size set. Furthermore, if RESTRICTED_TYPE is set to one of NHP_ONLY or RHP_ONLY for any of the preferred packet sizes, that size is allowed only for packets of the specified type.
只有当有效负载大小是优选分组大小集的一部分时，NHP分组才能被传送到较低层。此外，如果对于任何优选分组大小，将受限分组类型设置为仅NHP分组或仅RHP分组中的一个，则该大小仅允许用于指定类型的分组。
By default, no preferred packet sizes are specified. When sizes are specified, the default value for RESTRICTED_TYPE is NO_RESTRICTION.
默认情况下，未指定首选数据包大小。指定大小后，受限\u类型的默认值为“无\u限制”。
LARGE_PACKETS_ALLOWED -- value: boolean
大数据包\u允许--值：布尔值
This parameter may be set by an external entity to specify how to handle packets that do not fit any of the preferred packet sizes specified. If it is set to TRUE, the compressor MUST deliver the larger packet as-is and MUST NOT use segmentation. If it is set to FALSE, the ROHC segmentation scheme MUST be used to split the packet into two or more segments, and each segment MUST further be padded to fit one of the preferred packet sizes.
该参数可由外部实体设置，以指定如何处理不符合指定的任何首选数据包大小的数据包。如果设置为TRUE，则压缩器必须按原样传送较大的数据包，并且不得使用分段。如果设置为FALSE，则必须使用ROHC分段方案将数据包分割为两个或多个数据段，并且必须进一步填充每个数据段以适合其中一个首选数据包大小。
By default, this parameter is set to TRUE, which means that segmentation is disabled.
默认情况下，此参数设置为TRUE，这意味着已禁用分段。
VERIFICATION_PERIOD -- value: integer
验证周期--值：整数
This parameter may be set by an external entity to specify to the compressor the minimum frequency with which a packet validating the context must be sent. This tells the compressor that a packet containing a CRC field MUST be sent at least once every N packets, where N=VERIFICATION_PERIOD (see Section 4.6).
该参数可由外部实体设置，以向压缩器指定验证上下文的数据包必须发送的最小频率。这告诉压缩器，包含CRC字段的数据包必须至少每N个数据包发送一次，其中N=验证周期（见第4.6节）。
By default, this parameter is set to 0, which indicates that periodical verifications are disabled.
默认情况下，此参数设置为0，表示禁用定期验证。
NHP_PACKET -- value: boolean
NHP_数据包--值：布尔值
This parameter informs the decompressor that the packet being delivered is an NHP packet. The decompressor MUST accept this packet type indicator from the lower layer. An assisting layer MUST set this indicator to true for every NHP packet delivered, and to false for any other packet.
此参数通知解压器正在交付的数据包是NHP数据包。解压缩程序必须从较低层接受此数据包类型指示符。辅助层必须为每个交付的NHP数据包将该指示符设置为true，为任何其他数据包将该指示符设置为false。
PHYSICAL_PACKET_LOSS -- signal
物理数据包丢失——信号
This signal indicates to the decompressor that a packet has been lost on the link between the compressing and the decompressing sides, due to a physical link error. The signal is given once for each packet that was lost, and a decompressor must increase the sequence number accordingly when this signal is received.
该信号向解压缩器指示由于物理链路错误，压缩侧和解压缩侧之间的链路上的数据包已丢失。对于每个丢失的数据包，该信号给出一次，当接收到该信号时，解压器必须相应地增加序列号。
PRE_LINK_PACKET_LOSS -- signal
链路前丢包——信号
This signal tells the decompressor to increase the sequence number due to a gap in the sequencing not related to a physical link error. A receiving assisting layer may, for example, use this signal to indicate to the decompressor that a packet was lost before the compressor, or that a packet was discarded by the transmitting assisting layer.
该信号告知解压器由于与物理链路错误无关的序列间隔而增加序列号。例如，接收辅助层可以使用该信号向解压缩器指示分组在压缩器之前丢失，或者分组被发送辅助层丢弃。
This document provides the semantics and requirements of the interface needed from the ROHC compressor and decompressor towards the assisting layer to perform link-layer-assisted header compression.
本文档提供了ROHC压缩器和解压缩器到辅助层所需接口的语义和要求，以执行链路层辅助的报头压缩。
However, this document does not provide any link-layer-specific operational information, except for some implementation suggestions. Further details about how this profile is to be implemented over various link technologies must be described in other documents, where specific characteristics of each link layer can be taken into account to provide optimal usage of this profile.
但是，除了一些实施建议外，本文档不提供任何链路层特定的操作信息。关于如何通过各种链接技术实现此配置文件的更多详细信息必须在其他文档中描述，其中可以考虑每个链接层的特定特征，以提供此配置文件的最佳使用。
These specifications MAY use a packet-type bit pattern unused by this profile to implement signaling on the lower layer. The pattern available to lower layer implementations is [11111001].
这些规范可以使用该简档未使用的分组类型比特模式来在较低层上实现信令。较低层实现可用的模式是[11111 001]。
ROHC profile identifier 0x0005 has been reserved by the IANA for the IP/UDP/RTP profile defined in this document.
IANA已为本文档中定义的IP/UDP/RTP配置文件保留ROHC配置文件标识符0x0005。
The security considerations of ROHC RTP [ROHC, Section 7] apply also to this document, with one addition: in the case of a denial-of-service attack scenario where an intruder injects bogus CCP packets using random CRC values onto the link, the CRC check will fail for incorrect reasons at the decompressor side. This would obviously greatly reduce the advantages of ROHC and any extra efficiency provided by this profile due to unnecessary context invalidation, feedback messages, and refresh packets. However, the same remarks related to the presence of such an intruder apply.
ROHC RTP[ROHC，第7节]的安全注意事项也适用于本文件，但有一点需要补充：在拒绝服务攻击的情况下，入侵者使用随机CRC值向链路注入虚假CCP数据包，CRC检查将因不正确的原因在解压缩器端失败。由于不必要的上下文失效、反馈消息和刷新数据包，这显然会大大降低ROHC的优势以及该配置文件提供的任何额外效率。然而，与此类入侵者的存在相关的评论同样适用。
The authors would like to thank Lila Madour, Ulises Olvera-Hernandez, and Francis Lupien for input regarding the typical links in which LLA can be applied. Thanks also to Mikael Degermark for fruitful discussions that led to improvements of this profile, and to Zhigang Liu for many valuable comments.
作者要感谢Lila Madour、Ulises Olvera Hernandez和Francis Lupien对LLA可应用的典型链接的投入。还要感谢米凯尔·德格马克（Mikael Degermark）的富有成效的讨论，这些讨论导致了本简介的改进，并感谢刘志刚（Zhigang Liu）的许多宝贵意见。
[ROHC] 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.
[ROHC]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月。
[IPv4] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPv4]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[LLA] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP", RFC 3242, April 2002.
[LLA]Jonsson，L-E.和G.Pelletier，“鲁棒头压缩（ROHC）：IP/UDP/RTP的链路层辅助配置文件”，RFC 3242，2002年4月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[RTP-REQ] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[RTP-REQ]Degermark，M.，“鲁棒IP/UDP/RTP报头压缩的要求”，RFC 3096，2001年7月。
[0B-REQ] Jonsson, L-E., "RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression", RFC 3243, April 2002.
[0B-REQ]Jonsson，L-E，“鲁棒头压缩（ROHC）：0字节IP/UDP/RTP压缩的要求和假设”，RFC 3243，2002年4月。
[VJHC] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[VJHC]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC 1144，1990年2月。
[IPHC] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHC]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[CRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[CRTP]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[CRTPC] Degermark, M., Hannu, H., Jonsson, L-E. and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communications Magazine, Volume 7, number 4, pp. 20-25, August 2000.
[CRTPC]Degermark，M.，Hannu，H.，Jonsson，L-E.和K.Svanbro，“蜂窝无线电网络上CRTP性能的评估”，IEEE个人通信杂志，第7卷，第4期，第20-25页，2000年8月。
[VTC2000] Svanbro, K., Hannu, H., Jonsson, L-E. and M. Degermark, "Wireless real time IP-services enabled by header compression", proceedings of IEEE VTC2000, May 2000.
[VTC2000]Svanbro，K.，Hannu，H.，Jonsson，L-E.和M.Degermark，“通过报头压缩实现的无线实时IP服务”，IEEE VTC2000会议记录，2000年5月。
[MOMUC01] Liu, G., et al., "Experimental field trials results of Voice-over IP over WCDMA links", MoMuC'01 - The International Workshop on Mobile Multimedia Communications, Conference proceedings, February 2001.
[MOMUC01]Liu，G.等人，“WCDMA链路上IP语音的实验现场试验结果”，MOMUC01-移动多媒体通信国际研讨会，会议记录，2001年2月。
Authors' Addresses
作者地址
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
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
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）提供。