Network Working Group L-E. Jonsson
Request for Comments: 3242 G. Pelletier
Category: Standards Track Ericsson
April 2002
Network Working Group L-E. Jonsson
Request for Comments: 3242 G. Pelletier
Category: Standards Track Ericsson
April 2002
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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 making use of this header-free packet.
本文件定义了用于压缩IP/UDP/RTP（互联网协议/用户数据报协议/实时传输协议）数据包的ROHC（鲁棒报头压缩）配置文件，利用较低层提供的功能，通过在优化操作期间完全消除大多数数据包的报头，提高压缩效率。该配置文件是作为ROHC RTP配置文件的扩展而构建的。它定义了ROHC中需要的其他机制，说明了辅助层的要求以保证透明度，并指定了使用此无报头数据包进行压缩和解压缩的一般逻辑。
Table of Contents
目录
1. Introduction....................................................2
2. Terminology.....................................................4
3. Overview of the Link-Layer Assisted Profile.....................5
3.1. Providing Packet Type Identification.....................6
3.2. Replacing the Sequence Number............................6
3.3. CRC Replacement..........................................7
3.4. Applicability of This Profile............................7
4. Additions and Exceptions Compared to ROHC RTP...................8
4.1. Additional Packet Types..................................8
4.1.1. No-Header Packet (NHP)..........................8
4.1.2. Context Synchronization Packet (CSP)............8
4.1.3. Context Check Packet (CCP)......................9
1. Introduction....................................................2
2. Terminology.....................................................4
3. Overview of the Link-Layer Assisted Profile.....................5
3.1. Providing Packet Type Identification.....................6
3.2. Replacing the Sequence Number............................6
3.3. CRC Replacement..........................................7
3.4. Applicability of This Profile............................7
4. Additions and Exceptions Compared to ROHC RTP...................8
4.1. Additional Packet Types..................................8
4.1.1. No-Header Packet (NHP)..........................8
4.1.2. Context Synchronization Packet (CSP)............8
4.1.3. Context Check Packet (CCP)......................9
4.2. Interfaces Towards the Assisting Layer..................11
4.2.1. Interface, Compressor to Assisting Layer.......11
4.2.2. Interface, Assisting Layer to Decompressor.....12
4.3. Optimistic Approach Agreement...........................13
4.4. Fast Context Initialization, IR Redefinition............13
4.5. Feedback Option, CV-REQUEST.............................14
4.6. Periodic Context Verification...........................15
4.7. Use of Context Identifier...............................15
5. Implementation Issues..........................................15
5.1. Implementation Parameters and Signals...................15
5.1.1. Implementation Parameters at the Compressor....16
5.1.2. Implementation Parameters at the Decompressor..17
5.2. Implementation over Various Link Technologies...........18
6. IANA Considerations............................................18
7. Security Considerations........................................18
8. Acknowledgements...............................................18
9. References.....................................................19
10. Authors' Addresses.............................................20
11. Full Copyright Statement.......................................21
4.2. Interfaces Towards the Assisting Layer..................11
4.2.1. Interface, Compressor to Assisting Layer.......11
4.2.2. Interface, Assisting Layer to Decompressor.....12
4.3. Optimistic Approach Agreement...........................13
4.4. Fast Context Initialization, IR Redefinition............13
4.5. Feedback Option, CV-REQUEST.............................14
4.6. Periodic Context Verification...........................15
4.7. Use of Context Identifier...............................15
5. Implementation Issues..........................................15
5.1. Implementation Parameters and Signals...................15
5.1.1. Implementation Parameters at the Compressor....16
5.1.2. Implementation Parameters at the Decompressor..17
5.2. Implementation over Various Link Technologies...........18
6. IANA Considerations............................................18
7. Security Considerations........................................18
8. Acknowledgements...............................................18
9. References.....................................................19
10. Authors' Addresses.............................................20
11. Full Copyright Statement.......................................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 further improve compression efficiency for the case of real-time traffic using the Real-Time Transport Protocol [RTP].
报头压缩是一种技术，用于在每跳的基础上压缩和透明地解压缩数据包的报头信息，利用数据包流中单个数据包内和连续数据包之间的冗余。多年来，已经开发了几种协议[VJHC，IPHC]来压缩网络和传输协议头[IPv4，IPv6，UDP，TCP]，这些方案成功地提高了许多有线瓶颈链路的效率，例如电话网络上的调制解调器连接。除了IP、UDP和TCP压缩之外，还开发了一种称为压缩RTP[CRTP]的额外压缩方案，以进一步提高使用实时传输协议[RTP]的实时流量的压缩效率。
The schemes mentioned above have all been designed 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
上述方案的设计考虑了链路特性的正常假设，传统上仅基于有线链路。然而，随着互联网路径中无线链路数量的增加，这些假设不再普遍有效。在无线环境中，特别是宽覆盖蜂窝环境中，可以容忍相对较高的错误率，以便有效地使用无线电资源。对于对延迟比对错误更敏感的实时业务，此类操作条件将是正常的，例如，第三代蜂窝链路，因此报头压缩必须容忍数据包丢失。然而，对于前面提到的方案，特别是对于由CRTP压缩的实时流量，高错误率已经被证明会显著降低性能
header compression performance [CRTPC]. This problem was the driving force behind the creation of the RObust Header Compression (ROHC) WG in the IETF.
头压缩性能[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 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 been designed to also 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 next higher fixed packet size supported by the link, something which 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 however 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.
如上所述，IP将端到端使用的第三代蜂窝系统是ROHC RTP背后的驱动力之一，该方案的设计也适用于新的蜂窝空中接口，如WCDMA，使运行频谱效率比现有单业务电路交换解决方案低得多的语音服务成为可能[VTC2000]。然而，其他空中接口，如基于GSM和IS-95的空中接口，也将用于所有IP网络，进一步影响报头压缩问题。这些老式的空中接口灵活性较差，无线电承载器针对特定的有效载荷尺寸进行了优化。这意味着，如果不使用链路支持的下一个更高的固定数据包大小，甚至不能添加一个八位字节的报头，这显然是非常昂贵的。对于已经部署的语音声码器，与现有的电路交换解决方案相比，这些链路上的频谱效率将较低。为了在任何应用中实现高频谱效率，必须部署更灵活的空中接口，然后ROHC RTP方案将表现出色，如WCDMA[MOMUC01]所示。然而，出于部署原因，还必须为现有声码器和空中接口（如GERAN和CDMA2000）提供合适的报头压缩策略，并且对频谱效率的影响最小。
This document defines a new link-layer assisted ROHC RTP profile extending ROHC RTP (profile 0x0001) [ROHC], compliant with the ROHC 0-byte requirements [0B-REQ]. The purpose of this new profile is to provide a header-free packet format that, for a certain application
本文件定义了一个新的链路层辅助ROHC RTP配置文件，扩展了ROHC RTP（配置文件0x0001）[ROHC]，符合ROHC 0字节要求[0B-REQ]。此新配置文件的目的是提供一种无报头的数据包格式，用于特定的应用程序
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.
在正常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 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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
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" in this document refers to the IP/UDP/RTP profile (profile 0x0001) as defined in [ROHC].
本文件中的“ROHC RTP”是指[ROHC]中定义的IP/UDP/RTP配置文件（配置文件0x0001）。
The ROHC IP/UDP/RTP profile defined in this document, profile 0x0005 (hex), is designed to be used over channels that have been optimized for specific payload sizes and therefore cannot efficiently accommodate header information when transmitted together with payloads corresponding to these optimal sizes.
本文件中定义的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, what this profile does is to replace 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. ROHC RTP packets with compressed headers will be possible to distinguish 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, if needed the compressing side 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 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 long 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 2) Protection against failures caused by residual bit errors in compressed headers 3) Protection against faulty implementations and other causes of error
1) 检测超过序列号LSBs所能覆盖的时间的丢失2）防止压缩报头中残余位错误导致的故障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 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. Whether LLA or ROHC RTP should be implemented thus depends on the characteristics of the link itself. For most RTP packet streams, LLA will work exactly as ROHC RTP, while it will be more efficient for packet streams with certain characteristics. LLA will never be less efficient than ROHC RTP.
LLA配置文件可与任何能够提供前几节所述功能的链路技术一起使用。因此，是否应实施LLA或ROHC RTP取决于链路本身的特性。对于大多数RTP数据包流，LLA的工作原理与ROHC RTP完全相同，而对于具有某些特性的数据包流，LLA的工作效率更高。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), i.e., a packet consisting only of a payload, is defined and MAY be used when only sequencing must be conveyed, i.e., 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 4.3, 4.5 and 4.6). An LLA compressor is not allowed to deliver NHP packets when operating in R-mode.
定义了无报头分组（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 b) has either received a loss indication or the packet itself for the packet corresponding to SN = X-1.
a) 具有为对应于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 data being discarded, which may result in decompressor context invalidation. It might therefore be beneficial to send a packet with only the header information and 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
+===+===+===+===+===+===+===+===+
: 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
+===+===+===+===+===+===+===+===+
: ROHC header without padding :
: see [ROHC, section 5.7] :
+---+---+---+---+---+---+---+---+
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。
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 or not. If C=1, the CRC field MUST be set to the 7-bits 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 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 [ROHC, section 5.3.2.2.3]. 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.
解压器需要处理用C位集（C=1）接收的CCP，指示有效的CRC字段，并执行上下文验证。然后，必须将接收到的CRC应用于最后一个解压缩的数据包，除非先前接收到数据包丢失指示。CRC故障时，必须按照[ROHC，第5.3.2.2.3节]的规定采取措施。解压缩程序必须忽略接收到的C=0的CCP。不允许减压器对CCP进行任何进一步解释。
The use of CCP by an assisting layer is optional and depends on the characteristics of the actual link. Whether it is used or not 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 properly. While it does define semantics, it does not specify how these interfaces are to be implemented.
本节定义了LLA压缩机和辅助层之间要交换的信息，以便该剖面正常运行。虽然它定义了语义，但没有指定如何实现这些接口。
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 being 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 - the received packet together with an indication whether the packet received is an NHP or not
- CID=0的压缩侧和解压缩侧之间链路上的每个分组丢失指示-接收到的分组以及接收到的分组是否为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 in case of three or more consecutive physical packet losses. 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 between the compressing side and the decompressing side. It could be handled with a fixed principle, negotiation at startup, or by other means, but the method must be unambiguously defined.
要求所有描述LLA配置文件如何在特定链路技术上实现的文档定义压缩侧和解压缩侧之间如何商定乐观方法。可以使用固定原则、启动时协商或其他方式来处理，但方法必须明确定义。
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
为了达到这一目的，针对LLA配置文件重新定义了ROHC RTP IR数据包基本结构[ROHC第5.7.7.1节]中的D位。对于D=0（无动态链），D位的含义为
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.
扩展以指示在组装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 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 NHP 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 to periodically send context updating packets, 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 chapter 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 a minimum of one octet ROHC padding.
该参数可由外部实体设置，以向压缩器指定每个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 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.
此参数集控制辅助层首选的数据包大小。如果使用此参数集，则必须填充所有RHP数据包以适合最小的可能首选大小。如果未添加的数据包的大小（或者，在设置ALWAYS_PAD的情况下，具有最小一个八位组填充的数据包）大于最大首选数据包大小，则压缩器有两个选项。或者，它可以以任意大小传送这个较大的数据包，或者它可以使用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 onto the link using random CRC values, 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., 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.，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", RFC 1889, January 1996.
[RTP]Schulzrinne，H.，Casner S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[TCP] Postel, P., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，P.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[RTP-REQ] Degermark, M., "Requirements for 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月。
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea Sweden
Lars Erik Jonsson Ericsson AB信箱920 SE-971 28瑞典卢利亚
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
EMail: lars-erik.jonsson@ericsson.com
Phone: +46 920 20 21 07
Fax: +46 920 20 20 99
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 920 20 24 32
Fax: +46 920 20 20 99
EMail: ghyslain.pelletier@epl.ericsson.se
Phone: +46 920 20 24 32
Fax: +46 920 20 20 99
EMail: ghyslain.pelletier@epl.ericsson.se
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编辑功能的资金目前由互联网协会提供。