Network Working Group L-E. Jonsson
Request for Comments: 4995 G. Pelletier
Category: Standards Track K. Sandlund
Ericsson
July 2007
Network Working Group L-E. Jonsson
Request for Comments: 4995 G. Pelletier
Category: Standards Track K. Sandlund
Ericsson
July 2007
The RObust Header Compression (ROHC) Framework
健壮的报头压缩（ROHC）框架
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
鲁棒头压缩（ROHC）协议提供了一种高效、灵活、经得起未来考验的头压缩概念。它被设计为在具有不同特性的各种链路技术上高效、稳健地运行。
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.
ROHC框架以及一组压缩配置文件最初是在RFC3095中定义的。为了改进和简化ROHC规范，本文档分别明确定义了ROHC框架和未压缩文件的概要文件。更具体地说，框架的定义不会修改或更新RFC 3095指定的框架的定义。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Acronyms ...................................................4
2.2. ROHC Terminology ...........................................4
3. Background (Informative) ........................................7
3.1. Header Compression Fundamentals ............................7
3.2. A Short History of Header Compression ......................7
4. Overview of Robust Header Compression (ROHC) (Informative) ......8
4.1. General Principles .........................................8
4.2. Compression Efficiency, Robustness, and Transparency ......10
4.3. Developing the ROHC Protocol ..............................10
1. Introduction ....................................................3
2. Terminology .....................................................4
2.1. Acronyms ...................................................4
2.2. ROHC Terminology ...........................................4
3. Background (Informative) ........................................7
3.1. Header Compression Fundamentals ............................7
3.2. A Short History of Header Compression ......................7
4. Overview of Robust Header Compression (ROHC) (Informative) ......8
4.1. General Principles .........................................8
4.2. Compression Efficiency, Robustness, and Transparency ......10
4.3. Developing the ROHC Protocol ..............................10
4.4. Operational Characteristics of the ROHC Channel ...........11
4.5. Compression and Master Sequence Number (MSN) ..............13
4.6. Static and Dynamic Parts of a Context .....................13
5. The ROHC Framework (Normative) .................................14
5.1. The ROHC Channel ..........................................14
5.1.1. Contexts and Context Identifiers ...................14
5.1.2. Per-Channel Parameters .............................15
5.1.3. Persistence of Decompressor Contexts ...............16
5.2. ROHC Packets and Packet Types .............................16
5.2.1. General Format of ROHC Packets .....................17
5.2.1.1. Format of the Padding Octet ...............17
5.2.1.2. Format of the Add-CID Octet ...............18
5.2.1.3. General Format of Header ..................18
5.2.2. Initialization and Refresh (IR) Packet Types .......19
5.2.2.1. ROHC IR Packet Type .......................20
5.2.2.2. ROHC IR-DYN Packet Type ...................20
5.2.3. ROHC Initial Decompressor Processing ...............21
5.2.4. ROHC Feedback ......................................22
5.2.4.1. ROHC Feedback Format ......................23
5.2.5. ROHC Segmentation ..................................25
5.2.5.1. Segmentation Usage Considerations .........25
5.2.5.2. Segmentation Protocol .....................26
5.3. General Encoding Methods ..................................27
5.3.1. Header Compression CRCs, Coverage and Polynomials ..27
5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers .......27
5.3.1.2. 3-bit CRC in Compressed Headers ...........27
5.3.1.3. 7-bit CRC in Compressed Headers ...........28
5.3.1.4. 32-bit Segmentation CRC ...................28
5.3.2. Self-Describing Variable-Length Values .............29
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) .....29
5.4.1. IR Packet ..........................................30
5.4.2. Normal Packet ......................................31
5.4.3. Decompressor Operation .............................31
5.4.4. Feedback ...........................................32
6. Overview of a ROHC Profile (Informative) .......................32
7. Security Considerations ........................................33
8. IANA Considerations ............................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................35
Appendix A. CRC Algorithm ........................................37
4.4. Operational Characteristics of the ROHC Channel ...........11
4.5. Compression and Master Sequence Number (MSN) ..............13
4.6. Static and Dynamic Parts of a Context .....................13
5. The ROHC Framework (Normative) .................................14
5.1. The ROHC Channel ..........................................14
5.1.1. Contexts and Context Identifiers ...................14
5.1.2. Per-Channel Parameters .............................15
5.1.3. Persistence of Decompressor Contexts ...............16
5.2. ROHC Packets and Packet Types .............................16
5.2.1. General Format of ROHC Packets .....................17
5.2.1.1. Format of the Padding Octet ...............17
5.2.1.2. Format of the Add-CID Octet ...............18
5.2.1.3. General Format of Header ..................18
5.2.2. Initialization and Refresh (IR) Packet Types .......19
5.2.2.1. ROHC IR Packet Type .......................20
5.2.2.2. ROHC IR-DYN Packet Type ...................20
5.2.3. ROHC Initial Decompressor Processing ...............21
5.2.4. ROHC Feedback ......................................22
5.2.4.1. ROHC Feedback Format ......................23
5.2.5. ROHC Segmentation ..................................25
5.2.5.1. Segmentation Usage Considerations .........25
5.2.5.2. Segmentation Protocol .....................26
5.3. General Encoding Methods ..................................27
5.3.1. Header Compression CRCs, Coverage and Polynomials ..27
5.3.1.1. 8-bit CRCs in IR and IR-DYN Headers .......27
5.3.1.2. 3-bit CRC in Compressed Headers ...........27
5.3.1.3. 7-bit CRC in Compressed Headers ...........28
5.3.1.4. 32-bit Segmentation CRC ...................28
5.3.2. Self-Describing Variable-Length Values .............29
5.4. ROHC UNCOMPRESSED -- No Compression (Profile 0x0000) .....29
5.4.1. IR Packet ..........................................30
5.4.2. Normal Packet ......................................31
5.4.3. Decompressor Operation .............................31
5.4.4. Feedback ...........................................32
6. Overview of a ROHC Profile (Informative) .......................32
7. Security Considerations ........................................33
8. IANA Considerations ............................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................35
Appendix A. CRC Algorithm ........................................37
For many types of networks, reducing the deployment and operational costs by improving the usage of the bandwidth resources is of vital importance. Header compression over a link is possible because some of the information carried within the header of a packet becomes compressible between packets belonging to the same flow.
对于许多类型的网络，通过提高带宽资源的利用率来降低部署和运营成本至关重要。链路上的报头压缩是可能的，因为在分组报头内携带的一些信息在属于相同流的分组之间变得可压缩。
For links where the overhead of the IP header(s) is problematic, the total size of the header may be significant. Applications carrying data carried within RTP [13] will then, in addition to link-layer framing, have an IPv4 [10] header (20 octets), a UDP [12] header (8 octets), and an RTP header (12 octets), for a total of 40 octets. With IPv6 [11], the IPv6 header is 40 octets for a total of 60 octets. Applications transferring data using TCP [14] will have 20 octets for the transport header, for a total size of 40 octets for IPv4 and 60 octets for IPv6.
对于IP报头的开销有问题的链路，报头的总大小可能很大。除链路层帧外，承载RTP[13]中数据的应用程序将具有IPv4[10]报头（20个八位字节）、UDP[12]报头（8个八位字节）和RTP报头（12个八位字节），总共40个八位字节。对于IPv6[11]，IPv6头是40个八位字节，总共60个八位字节。使用TCP[14]传输数据的应用程序的传输头将有20个八位字节，IPv4的总大小为40个八位字节，IPv6的总大小为60个八位字节。
The relative gain for specific flows (or applications) depends on the size of the payload used in each packet. For applications such as Voice-over-IP, where the size of the payload containing coded speech can be as small as 15-20 octets, this gain will be quite significant. Similarly, relative gains for TCP flows carrying large payloads (such as file transfers) will be less than for flows carrying smaller payloads (such as application signaling, e.g., session initiation).
特定流（或应用程序）的相对增益取决于每个数据包中使用的有效负载的大小。对于IP语音这样的应用，包含编码语音的有效负载的大小可以小到15-20个八位组，这种增益将非常显著。类似地，承载较大有效负载（如文件传输）的TCP流的相对增益将小于承载较小有效负载（如应用程序信令，如会话启动）的TCP流的相对增益。
As more and more wireless link technologies are being deployed to carry IP traffic, care must be taken to address the specific characteristics of these technologies within the header compression algorithms. Legacy header compression schemes, such as those defined in [16] and [17], have been shown to perform inadequately over links where both the lossy behavior and the round-trip times are non-negligible, such as those observed for example in wireless links and IP tunnels.
随着越来越多的无线链路技术被部署用于承载IP流量，必须注意在报头压缩算法中解决这些技术的特定特征。传统的报头压缩方案，如[16]和[17]中定义的方案，已被证明在链路上执行不充分，其中有损行为和往返时间都是不可忽略的，例如在无线链路和IP隧道中观察到的。
In addition, a header compression scheme should handle the often non-trivial residual errors, i.e., where the lower layer may pass a packet that contains undetected bit errors to the decompressor. It should also handle loss and reordering before the compression point, as well as on the link between the compression and decompression points [7].
此外，报头压缩方案应处理通常非平凡的残余错误，即，较低层可将包含未检测到的比特错误的分组传递给解压缩器。它还应该处理压缩点之前的丢失和重新排序，以及压缩点和解压缩点之间的链接[7]。
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
鲁棒头压缩（ROHC）协议提供了一种高效、灵活、经得起未来考验的头压缩概念。它被设计为在具有不同特性的各种链路技术上高效、稳健地运行。
RFC 3095 [3] defines the ROHC framework along with an initial set of compression profiles. To improve and simplify the specification, the framework and the profiles' parts have been split into separate documents. This document explicitly defines the ROHC framework, but it does not modify or update the definition of the framework specified by RFC 3095; both documents can be used independently of each other. This also implies that implementations based on either definition will be compatible and interoperable with each other. However, it is the intent to let this specification replace RFC 3095 as the base specification for all profiles defined in the future.
RFC 3095[3]定义了ROHC框架以及一组初始压缩配置文件。为了改进和简化规范，框架和概要文件的部分被拆分为单独的文档。本文件明确定义了ROHC框架，但未修改或更新RFC 3095规定的框架定义；这两个文档可以相互独立使用。这也意味着基于这两个定义的实现将相互兼容和互操作。然而，本规范旨在取代RFC 3095，作为将来定义的所有外形的基本规范。
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 [1].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
This section lists most acronyms used for reference.
本节列出了大多数用于参考的首字母缩略词。
ACK Acknowledgment. CID Context Identifier. CO Compressed Packet Format. CRC Cyclic Redundancy Check. IR Initialization and Refresh. IR-DYN Initialization and Refresh, Dynamic part. LSB Least Significant Bit(s). MRRU Maximum Reconstructed Reception Unit. MSB Most Significant Bit(s). MSN Master Sequence Number. NACK Negative Acknowledgment. ROHC RObust Header Compression.
确认。CID上下文标识符。联合压缩包格式。循环冗余校验。红外初始化和刷新。IR-DYN初始化和刷新，动态部分。LSB最低有效位。最大重构接收单元。MSB最高有效位。MSN主序列号。NACK否定应答。ROHC鲁棒头压缩。
Context
上下文
The context of the compressor is the state it uses to compress a header. The context of the decompressor is the state it uses to decompress a header. Either of these or the two in combination are usually referred to as "context", when it is clear which is intended. The context contains relevant information from previous headers in the packet flow, such as static fields and possible reference values for compression and decompression. Moreover, additional information describing the packet flow is also part of
压缩器的上下文是它用来压缩头的状态。解压器的上下文是解压头所使用的状态。当清楚目的是什么时，这些或两者结合通常被称为“上下文”。上下文包含来自数据包流中以前的头的相关信息，例如静态字段和用于压缩和解压缩的可能参考值。此外，描述分组流的附加信息也是本文的一部分
the context, for example, information about the change behavior of fields (e.g., the IP Identifier behavior, or the typical inter-packet increase in sequence numbers and timestamps).
上下文，例如，关于字段更改行为的信息（例如，IP标识符行为，或序列号和时间戳中典型的数据包间增加）。
Context damage
环境损害
When the context of the decompressor is not consistent with the context of the compressor, decompression may fail to reproduce the original header. This situation can occur when the context of the decompressor has not been initialized properly or when packets have been lost or damaged between the compressor and decompressor.
当解压器的上下文与压缩器的上下文不一致时，解压可能无法再现原始头。当解压器的上下文未正确初始化，或者数据包在压缩器和解压器之间丢失或损坏时，可能会发生这种情况。
Packets which cannot be decompressed due to inconsistent contexts are said to be lost due to context damage. Packets that are decompressed but contain errors due to inconsistent contexts are said to be damaged due to context damage.
由于上下文不一致而无法解压缩的数据包称为由于上下文损坏而丢失。已解压缩但包含由于上下文不一致而导致的错误的数据包称为由于上下文损坏而损坏。
Context repair mechanism
上下文修复机制
Context repair mechanisms are used to resynchronize the contexts, an important task since context damage causes loss propagation. Examples of such mechanisms are NACK-based mechanisms, and the periodic refreshes of important context information, usually done in unidirectional operation. There are also mechanisms that can reduce the context inconsistency probability, for example, repetition of the same type of information in multiple packets and CRCs that protect context-updating information.
上下文修复机制用于重新同步上下文，这是一项重要任务，因为上下文损坏会导致丢失传播。这种机制的例子是基于NACK的机制，以及重要上下文信息的定期刷新，通常在单向操作中完成。还有一些机制可以降低上下文不一致的概率，例如，在多个数据包和保护上下文更新信息的CRC中重复相同类型的信息。
CRC-8 validation
CRC-8验证
The CRC-8 validation refers to the validation of the integrity against bit error(s) in a received IR and IR-DYN header using the 8-bit CRC included in the IR/IR-DYN header.
CRC-8验证是指使用IR/IR-DYN报头中包含的8位CRC，针对接收的IR和IR-DYN报头中的位错误验证完整性。
CRC verification
CRC校验
The CRC verification refers to the verification of the result of a decompression attempt using the 3-bit CRC or 7-bit CRC included in the header of a compressed packet format.
CRC验证是指使用压缩包格式的报头中包括的3位CRC或7位CRC对解压缩尝试的结果进行验证。
Damage propagation
损伤扩展
Delivery of incorrect decompressed headers due to context damage, that is, due to errors in (i.e., loss of or damage to) previous header(s) or feedback.
由于上下文损坏，也就是说，由于以前的头或反馈中的错误（即丢失或损坏），导致不正确的解压缩头的传递。
Error detection
错误检测
Detection of errors by lower layers. If error detection is not perfect, there will be residual errors.
通过较低层检测错误。如果错误检测不完美，就会有剩余错误。
Error propagation
误差传播
Damage propagation or loss propagation.
损害传播或损失传播。
ROHC profile
ROHC配置文件
A ROHC profile is a compression protocol, which specifies how to compress specific header combinations. A ROHC profile may be tailored to handle a specific set of link characteristics, e.g., loss characteristics, reordering between compression points, etc. ROHC profiles provide the details of the header compression framework defined in this document, and each compression profile is associated with a unique ROHC profile identifier [21]. When setting up a ROHC channel, the set of profiles supported by both endpoints of the channel is negotiated, and when initializing new contexts, a profile identifier from this negotiated set is used to associate each compression context with one specific profile.
ROHC配置文件是一种压缩协议，它指定如何压缩特定的头组合。ROHC配置文件可以定制为处理一组特定的链路特征，例如丢失特征、压缩点之间的重新排序等。ROHC配置文件提供了本文档中定义的报头压缩框架的详细信息，并且每个压缩配置文件与唯一的ROHC配置文件标识符相关联[21]。当设置ROHC通道时，通道的两个端点支持的配置文件集被协商，当初始化新上下文时，来自该协商集的配置文件标识符用于将每个压缩上下文与一个特定配置文件关联。
Link
链接
A physical transmission path that constitutes a single IP hop.
构成单个IP跃点的物理传输路径。
Loss propagation
损耗传播
Loss of headers, due to errors in (i.e., loss of or damage to) previous header(s) or feedback.
由于先前标题或反馈中的错误（即丢失或损坏），导致标题丢失。
Packet flow
包流
A sequence of packets where the field values and change patterns of field values are such that the headers can be compressed using the same context.
一种数据包序列，其中字段值和字段值的变化模式使得可以使用相同的上下文压缩报头。
Residual error
剩余误差
Errors introduced during transmission and not detected by lower-layer error detection schemes.
传输过程中引入的错误，下层错误检测方案无法检测到。
ROHC channel
ROHC频道
A logical unidirectional point-to-point channel carrying ROHC packets from one compressor to one decompressor, optionally carrying ROHC feedback information on the behalf of another
一种逻辑单向点对点信道，将ROHC数据包从一个压缩器传送到一个解压缩器，可选地代表另一个压缩器传送ROHC反馈信息
compressor-decompressor pair operating on a separate ROHC channel in the opposite direction. See also [5].
压缩机-减压器对在相反方向的单独ROHC通道上运行。另见[5]。
This document also makes use of the conceptual terminology defined by "ROHC Terminology and Channel Mapping Examples", RFC 3759 [5].
本文件还使用了RFC 3759[5]中“ROHC术语和渠道映射示例”定义的概念术语。
This section provides a background to the subject of header compression. The fundamental ideas are described together with a discussion about the history of header compression schemes. The motivations driving the development of the various schemes are discussed and their drawbacks identified, thereby providing the foundations for the design of the ROHC framework and profiles [3].
本节提供标题压缩主题的背景信息。描述了基本思想，并讨论了报头压缩方案的历史。讨论了推动各种方案开发的动机，并确定了其缺点，从而为ROHC框架和概要文件的设计提供了基础[3]。
Header compression is possible because there is significant redundancy between header fields; within the headers of a single packet, but in particular between consecutive packets belonging to the same flow. On the path end-to-end, the entire header information is necessary for all packets in the flow, but over a single link, some of this information becomes redundant and can be reduced, as long as it is transparently recovered at the receiving end of the link. The header size can be reduced by first sending field information that is expected to remain static for (at least most of) the lifetime of the packet flow. Further compression is achieved for the fields carrying information that changes more dynamically by using compression methods tailored to their respective assumed change behavior.
标头压缩是可能的，因为标头字段之间存在大量冗余；在单个数据包的报头内，但特别是在属于同一流的连续数据包之间。在端到端的路径上，流中的所有数据包都需要整个报头信息，但是在单个链路上，这些信息中的一些变得冗余，并且可以减少，只要在链路的接收端透明地恢复。可以通过首先发送预期在分组流的生存期（至少大部分）内保持静态的字段信息来减小报头大小。通过使用针对其各自假设的变化行为而定制的压缩方法，对承载更动态变化的信息的字段实现进一步压缩。
To achieve compression and decompression, some necessary information from past packets is maintained in a context. The compressor and the decompressor update their respective contexts upon certain, not necessarily synchronized, events. Impairment events may lead to inconsistencies in the decompressor context (i.e., context damage), which in turn may cause incorrect decompression. A Robust Header Compression scheme needs mechanisms to minimize the possibility of context damage, in combination with mechanisms for context repair.
为了实现压缩和解压缩，在上下文中维护来自过去数据包的一些必要信息。压缩器和解压缩器根据某些事件（不一定同步）更新各自的上下文。减值事件可能导致解压器上下文不一致（即上下文损坏），进而可能导致不正确的解压。健壮的报头压缩方案需要将上下文损坏的可能性降至最低的机制，并结合上下文修复机制。
The first header compression scheme, compressed TCP (CTCP) [15], was introduced by Van Jacobson. CTCP, also often referred to as VJ compression, compresses the 40 octets of the TCP/IP header down to 4 octets. CTCP uses delta encoding for sequentially changing fields. The CTCP compressor detects transport-level retransmissions and sends a header that updates the entire context when they occur. This
Van Jacobson介绍了第一种报头压缩方案compressed TCP（CTCP）[15]。CTCP，也称为VJ压缩，将TCP/IP头的40个八位字节压缩为4个八位字节。CTCP对顺序变化的字段使用增量编码。CTCP压缩器检测传输级重传，并发送一个报头，在重传发生时更新整个上下文。这
repair mechanism does not require any explicit signaling between the compressor and decompressor.
维修机制不需要压缩机和减压器之间的任何明确信号。
A general IP header compression scheme, IP header compression [16], improves somewhat on CTCP. IP Header Compression (IPHC) can compress arbitrary IP, TCP, and UDP headers. When compressing non-TCP headers, IPHC does not use delta encoding and is robust. The repair mechanism of CTCP is augmented with negative acknowledgments, called CONTEXT_STATE messages, which speeds up the repair. This context repair mechanism is thus limited by the round-trip time of the link. IPHC does not compress RTP headers.
一种通用的IP报头压缩方案，IP报头压缩[16]，对CTCP有所改进。IP头压缩（IPHC）可以压缩任意IP、TCP和UDP头。在压缩非TCP报头时，IPHC不使用增量编码，并且非常健壮。CTCP的修复机制通过称为CONTEXT_STATE messages的否定确认来增强，从而加快修复速度。因此，这种上下文修复机制受到链路往返时间的限制。IPHC不压缩RTP头。
CRTP [17] is an RTP extension to IPHC. CRTP compresses the 40 octets of IPv4/UDP/RTP headers to a minimum of 2 octets when the UDP Checksum is not enabled. If the UDP Checksum is enabled, the minimum CRTP header is 4 octets.
CRTP[17]是IPHC的RTP扩展。未启用UDP校验和时，CRTP将IPv4/UDP/RTP头的40个八位字节压缩为至少2个八位字节。如果启用UDP校验和，则最小CRTP报头为4个八位字节。
On lossy links with long round-trip times, CRTP does not perform well [20]. Each packet lost over the link causes decompression of several subsequent packets to fail, because the context becomes invalidated during at least one link round-trip time from the lost packet. Unfortunately, the large headers that CRTP sends when updating the context waste additional bandwidth.
在往返时间较长的有损链路上，CRTP性能不佳[20]。链路上丢失的每个数据包都会导致几个后续数据包的解压缩失败，因为上下文在丢失数据包的至少一个链路往返时间内失效。不幸的是，CRTP在更新上下文时发送的大报头浪费了额外的带宽。
CRTP uses a local repair mechanism known as TWICE, which was introduced by IPHC. TWICE derives its name from the observation that when the flow of compressed packets is regular, the correct guess when one packet is lost between the compression points is to apply the update in the current packet twice. While TWICE improves CRTP performance significantly, [20] also found that even with TWICE, CRTP doubled the number of lost packets.
CRTP使用一种称为“两次”的本地修复机制，这是IPHC引入的。tweeps的名称来源于这样一个观察：当压缩数据包的流是规则的时，当一个数据包在压缩点之间丢失时，正确的猜测是在当前数据包中应用两次更新。虽然两次显著提高了CRTP性能，[20]还发现，即使是两次，CRTP也会使丢失的数据包数量增加一倍。
An enhanced variant of CRTP, called eCRTP [19], means to improve the robustness of CRTP in the presence of reordering and packet losses, while keeping the protocol almost unchanged from CRTP. As a result, eCRTP does provide better means to implement some degree of robustness, albeit at the expense of additional overhead, leading to a reduction in compression efficiency in comparison to CRTP.
CRTP的一个增强型变体，称为eCRTP[19]，意味着在存在重新排序和数据包丢失的情况下提高CRTP的健壮性，同时保持协议与CRTP几乎相同。因此，eCRTP确实提供了更好的方法来实现某种程度的健壮性，尽管代价是额外的开销，与CRTP相比，这导致压缩效率降低。
As mentioned earlier, header compression is possible per-link due to the fact that there is much redundancy between header field values within packets, and especially between consecutive packets belonging to the same flow. To utilize these properties for header compression, there are a few essential steps to consider.
如前所述，由于数据包内的报头字段值之间，尤其是属于同一流的连续数据包之间存在大量冗余，因此每个链路都可以进行报头压缩。为了利用这些属性进行头压缩，有几个基本步骤需要考虑。
The first step consists of identifying and grouping packets together into different "flows", so that packet-to-packet redundancy is maximized in order to improve the compression ratio. Grouping packets into flows is usually based on source and destination host (IP) addresses, transport protocol type (e.g., UDP or TCP), process (port) numbers, and potentially additional unique application identifiers, such as the synchronization source (SSRC) in RTP [13]. The compressor and decompressor each establish a context for the packet flow and identify the context with a Context Identifier (CID) included in each compressed header.
第一步包括将数据包识别并分组到不同的“流”中，以便最大化数据包到数据包的冗余以提高压缩比。将数据包分组到流中通常基于源和目标主机（IP）地址、传输协议类型（如UDP或TCP）、进程（端口）号和潜在的其他唯一应用程序标识符，如RTP中的同步源（SSRC）[13]。压缩器和解压缩器各自为分组流建立上下文，并使用包括在每个压缩报头中的上下文标识符（CID）来识别上下文。
The second step is to understand the change patterns of the various header fields. On a high level, header fields fall into one of the following classes:
第二步是了解各种头字段的更改模式。在较高级别上，标题字段分为以下类别之一：
INFERRED These fields contain values that can be inferred from other fields or external sources, for example, the size of the frame carrying the packet can often be derived from the link layer protocol, and thus does not have to be transmitted by the compression scheme.
推断出的这些字段包含可以从其他字段或外部源推断出的值，例如，承载分组的帧的大小通常可以从链路层协议导出，因此不必通过压缩方案传输。
STATIC Fields classified as STATIC are assumed to be constant throughout the lifetime of the packet flow. The value of each field is thus only communicated initially.
被分类为静态的静态字段被假定为在包流的整个生命周期中是恒定的。因此，每个字段的值仅在最初传递。
STATIC-DEF Fields classified as STATIC-DEF are used to define a packet flow as discussed above. Packets for which respective values of these fields differ are treated as belonging to different flows. These fields are in general compressed as STATIC fields.
分类为STATIC-DEF的STATIC-DEF字段用于定义如上所述的数据包流。这些字段的相应值不同的数据包被视为属于不同的流。这些字段通常被压缩为静态字段。
STATIC-KNOWN Fields classified as STATIC-KNOWN are expected to have well-known values, and therefore their values do not need to be communicated.
被分类为静态已知的静态已知字段预期具有已知值，因此不需要传递它们的值。
CHANGING These fields are expected to vary randomly, either within a limited value set or range, or in some other manner. CHANGING fields are usually handled in more sophisticated ways based on a more detailed classification of their expected change patterns.
更改这些字段可能会在有限的值集或范围内，或以其他方式随机变化。根据预期变化模式的更详细分类，变化字段通常以更复杂的方式处理。
Finally, the last step is to choose the encoding method(s) that will be applied onto different fields based on classification. The encoding methods, in combination with the identified field behavior, provide the input to the design of the compressed header formats. The analysis of the probability distribution of the identified change patterns then provides the means to optimize the packet formats,
最后，最后一步是根据分类选择将应用于不同字段的编码方法。编码方法与已识别的字段行为相结合，为压缩头格式的设计提供输入。然后，对所识别的变化模式的概率分布的分析提供了优化数据包格式的方法，
where the most frequently occurring change patterns for a field should be encoded within the most efficient format(s).
其中，字段最频繁发生的更改模式应以最有效的格式进行编码。
However, compression efficiency has to be traded against two other properties: the robustness of the encoding to losses and errors between the compressor and the decompressor, and the ability to detect and cope with errors in the decompression process.
然而，压缩效率必须与其他两个属性进行权衡：编码对压缩器和解压缩器之间的丢失和错误的鲁棒性，以及检测和处理解压缩过程中错误的能力。
The performance of a header compression protocol can be described with three parameters: its compression efficiency, its robustness, and its compression transparency.
报头压缩协议的性能可以用三个参数来描述：压缩效率、健壮性和压缩透明性。
Compression efficiency
压缩效率
The compression efficiency is determined by how much the average header size is reduced by applying the compression protocol.
压缩效率取决于通过应用压缩协议减少的平均报头大小。
Robustness
健壮性
A robust protocol tolerates packet losses, residual bit errors, and out-of-order delivery on the link over which header compression takes place, without losing additional packets or introducing additional errors in decompressed headers.
一个健壮的协议可以容忍数据包丢失、残余比特错误和在进行报头压缩的链路上的无序传送，而不会丢失额外的数据包或在解压缩的报头中引入额外的错误。
Compression transparency
压缩透明度
The compression transparency is a measure of the extent to which the scheme maintains the semantics of the original headers. If all decompressed headers are bitwise identical to the corresponding original headers, the scheme is transparent.
压缩透明度是方案维护原始头的语义的程度的度量。如果所有解压缩的报头都与相应的原始报头按位相同，则该方案是透明的。
The challenge in developing a header compression protocol is to conciliate compression efficiency and robustness while maintaining transparency, as increasing robustness will always come at the expense of a lower compression efficiency, and vice-versa. The scheme should also be flexible enough in its design to minimize the impacts from the varying round-trip times and loss patterns of links where header compression will be used.
开发报头压缩协议的挑战是在保持透明度的同时兼顾压缩效率和健壮性，因为增加健壮性总是以降低压缩效率为代价，反之亦然。该方案的设计也应足够灵活，以尽量减少使用报头压缩的不同往返时间和链路丢失模式的影响。
To achieve this, the header compression scheme must provide facilities for the decompressor to verify decompression and detect potential context damage, as well as context recovery mechanisms such as feedback. Header compression schemes prior to the ones developed
为了实现这一点，头压缩方案必须为解压器提供验证解压和检测潜在上下文损坏的设施，以及诸如反馈之类的上下文恢复机制。头压缩方案先于开发的方案
by the Robust Header Compression (ROHC) WG were not designed with the above high-level objectives in mind.
根据ROHC，工作组的设计没有考虑到上述高级目标。
The ROHC WG has developed header compression solutions to meet the needs of present and future link technologies. While special attention has been put towards meeting the more stringent requirements stemming from the characteristics of wireless links, the results are equally applicable to many other link technologies.
ROHC工作组已开发了报头压缩解决方案，以满足当前和未来链路技术的需要。虽然人们特别注意满足无线链路特性所产生的更严格的要求，但其结果同样适用于许多其他链路技术。
RFC 3095 [3], "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", was published in 2001, as the first output of the ROHC WG. ROHC is a general and extendable framework for header compression, on top of which profiles can be defined for compression of different protocols headers. RFC 3095 introduced a number of new compression techniques, and was successful at living up to the requirements placed on it, as described in [18].
RFC 3095[3]，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP、UDP、ESP和未压缩”，作为ROHC工作组的第一个输出于2001年出版。ROHC是一个通用的、可扩展的报头压缩框架，在此框架之上可以定义用于压缩不同协议报头的概要文件。RFC 3095引入了许多新的压缩技术，并成功地满足了[18]中所述的要求。
Interoperability testing of RFC 3095 confirms the capabilities of ROHC to meet its purposes, but feedback from implementers has also indicated that the protocol specification is complex and sometimes obscure. Most importantly, a clear distinction between framework and profiles is not obvious in [3], which also makes development of additional profiles troublesome. This document therefore aims at explicitly specifying the ROHC framework, while a companion document [8] specifies revised versions of the compression profiles of RFC 3095.
RFC 3095的互操作性测试证实了ROHC满足其目的的能力，但实施者的反馈也表明，协议规范很复杂，有时不明确。最重要的是，框架和概要文件之间的明确区别在[3]中并不明显，这也使得开发其他概要文件变得麻烦。因此，本文件旨在明确规定ROHC框架，而配套文件[8]规定了RFC 3095压缩配置文件的修订版本。
Robust header compression can be used over many type of link technologies. The ROHC framework provides flexibility for profiles to address a wide range of applications, and this section lists some of the operational characteristics of the ROHC channel (see also [5]).
健壮的报头压缩可用于多种类型的链路技术。ROHC框架为配置文件提供了灵活性，以满足广泛的应用，本节列出了ROHC通道的一些操作特征（另见[5]）。
Multiplexing over a single logical channel
在单个逻辑信道上多路复用
The ROHC channel provides a mechanism to identify a context within the general ROHC packet format. The CID makes it possible for a logical channel that supports ROHC to transport multiple header-compressed flows, while still making it possible for a channel to be dedicated to one single packet flow without any CID overhead. More specifically, ROHC uses a distinct context identifier space per logical channel, and the context identifier can be omitted for one of the flows over the ROHC channel when configured to use a small CID space.
ROHC通道提供了一种机制来识别通用ROHC数据包格式中的上下文。CID使得支持ROHC的逻辑信道能够传输多个报头压缩流，同时仍然使得信道能够专用于单个分组流而不需要任何CID开销。更具体地说，ROHC在每个逻辑通道上使用不同的上下文标识符空间，并且当配置为使用小的CID空间时，可以省略ROHC通道上的一个流的上下文标识符。
Establishment of channel parameters
信道参数的建立
A link layer defining support for the ROHC channel must provide the means to establish header compression channel parameters (see Section 5.1). This can be achieved through a negotiation mechanism, static provisioning, or some out-of-band signaling.
定义ROHC信道支持的链路层必须提供建立报头压缩信道参数的方法（见第5.1节）。这可以通过协商机制、静态供应或一些带外信令来实现。
Packet type identification
包类型识别
The ROHC channel defines a packet type identifier space, and puts restrictions with respect to the use of a number of identifiers that are common for all ROHC profiles. Identifiers that have no restrictions, i.e., identifiers that are not defined by this document, are available to each profile. The identifier is part of each compressed header, and this makes it possible for the link that supports the ROHC channel to allocate one single link layer payload type for ROHC.
ROHC通道定义了一个数据包类型标识符空间，并对所有ROHC配置文件通用的多个标识符的使用进行了限制。没有限制的标识符，即本文件未定义的标识符，可用于每个概要文件。标识符是每个压缩报头的一部分，这使得支持ROHC信道的链路可以为ROHC分配一个链路层有效负载类型。
Out-of-order delivery between compression endpoints
压缩端点之间的无序传递
Each profile defines its own level of robustness, including tolerance to reordering of packets before but especially between compression endpoints, if any.
每个概要文件都定义了自己的健壮性级别，包括在压缩端点之前（尤其是压缩端点之间）对数据包重新排序的容忍度（如果有的话）。
For profiles specified in [3], the channel between the compressor and decompressor is required to maintain in-order delivery of the packets, i.e., the definition of these profiles assumes that the decompressor always receives packets in the same order as the compressor sent them. The impacts of reordering on the performance of these profiles is described in [7]. However, reordering before the compression point is handled, i.e., these profiles make no assumption that the compressor will receive packets in-order.
对于[3]中规定的配置文件，压缩机和解压器之间的通道需要保持数据包的有序交付，即，这些配置文件的定义假定解压器总是以与压缩机发送数据包相同的顺序接收数据包。[7]中描述了重新排序对这些配置文件性能的影响。然而，在处理压缩点之前重新排序，即，这些配置文件不假设压缩器将按顺序接收数据包。
For the ROHCv2 profiles specified in [8], their definitions assume that the decompressor can receive packets out-of-order, i.e., not in the same order that the compressor sent them. Reordering before the compression point is also dealt with.
对于[8]中指定的ROHCv2配置文件，其定义假定解压器可以无序接收数据包，即，与压缩器发送数据包的顺序不同。压缩点之前的重新排序也会被处理。
Duplication of packets
数据包复制
The link supporting the ROHC channel is required to not duplicate packets (however, duplication of packets can occur before they reach the compressor, i.e., there is no assumption that the compressor will receive only one copy of each packet).
支持ROHC信道的链路需要不复制数据包（但是，数据包在到达压缩器之前可能会发生复制，即，不假设压缩器只接收每个数据包的一个副本）。
Framing
框架
The link layer must provide framing that makes it possible to distinguish frame boundaries and individual frames.
链接层必须提供能够区分帧边界和单个帧的帧。
Error detection/protection
错误检测/保护
ROHC profiles should be designed to cope with residual errors in the headers delivered to the decompressor. CRCs are used to detect decompression failures and to prevent or reduce damage propagation. However, it is recommended that lower layers deploy error detection for ROHC headers and that ROHC headers with high residual error rates not be delivered.
ROHC配置文件的设计应能处理交付给解压器的标题中的残余错误。CRC用于检测减压故障并防止或减少损伤传播。但是，建议较低层为ROHC标头部署错误检测，并且不提供具有高剩余错误率的ROHC标头。
Compression of header fields is based on the establishment of a function to a sequence number, called the master sequence number (MSN). This function describes the change pattern of the field with respect to a change in the MSN.
头字段的压缩基于建立一个序列号函数，称为主序列号（MSN）。此函数描述与MSN中的更改相关的字段更改模式。
Change patterns include, for example, fields that increase monotonically or by a small value, fields that seldom change,and fields that remain unchanging for the entire lifetime of the packet flow, in which case the function to the MSN is equivalent to a constant value.
例如，改变模式包括单调增加或以较小值增加的字段、很少改变的字段以及在分组流的整个生命周期内保持不变的字段，在这种情况下，MSN的函数相当于常量。
The compressor first establishes functions for each of the header fields, and then reliably communicates the MSN. When the change pattern of the field does not match the established function, i.e., the existing function gives a result that is different from the field in the header being compressed, additional information can be sent to update the parameters of that function.
压缩器首先为每个报头字段建立功能，然后可靠地与MSN通信。当字段的更改模式与已建立的函数不匹配时，即，现有函数给出的结果与正在压缩的报头中的字段不同，可以发送附加信息以更新该函数的参数。
The MSN is defined per profile. It can be either derived directly from one of the fields of the protocol being compressed (e.g., the RTP SN [8]), or it can be created and maintained by the compressor (e.g., the MSN for compression of UDP in profile 0x0102 [8] or the MSN in ROHC-TCP [9]).
MSN是根据配置文件定义的。它可以直接从被压缩的协议的一个字段（例如，RTP SN[8]）派生，也可以由压缩器创建和维护（例如，配置文件0x0102[8]中用于压缩UDP的MSN或ROHC-TCP[9]中的MSN）。
A compression context can be conceptually divided into two different parts, the static context and the dynamic context, each based on the properties of the fields that are being compressed.
压缩上下文在概念上可以分为两个不同的部分，静态上下文和动态上下文，每个部分都基于被压缩字段的属性。
The static part includes the information necessary to compress and decompress the fields whose change behavior is classified as STATIC, STATIC-KNOWN, or STATIC-DEF (as described in Section 4.1 above).
静态部分包括压缩和解压缩字段所需的信息，这些字段的更改行为分类为静态、静态已知或静态定义（如上文第4.1节所述）。
The dynamic part includes the state maintained for all the other fields, i.e., those that are classified as CHANGING.
动态部分包括为所有其他字段维护的状态，即分类为“更改”的字段。
This section normatively defines the parts common to all ROHC profiles, i.e., the framework. The framework specifies the requirements and functionality of the ROHC channel, including how to handle multiple compressed packet flows over the same channel.
本节规范性地定义了所有ROHC配置文件共有的部分，即框架。该框架规定了ROHC通道的要求和功能，包括如何处理同一通道上的多个压缩数据包流。
Finally, this section specifies encoding methods used in the packet formats that are common to all profiles. These encoding methods may be reused within profile specifications for encoding fields in profile-specific parts of a packet format, without requiring their redefinition.
最后，本节指定了所有配置文件通用的数据包格式中使用的编码方法。这些编码方法可以在概要文件规范中重用，用于对数据包格式的概要文件特定部分中的字段进行编码，而无需重新定义。
Associated with each compressed flow is a context. The context is the state that the compressor and the decompressor maintain in order to correctly compress or decompress the headers of the packet in the flow. Each context is identified using a CID.
与每个压缩流关联的是一个上下文。上下文是压缩器和解压缩器保持的状态，以便正确压缩或解压缩流中数据包的头。使用CID标识每个上下文。
A context is considered to be a new context when the CID is associated with a profile for the first time since the creation of the ROHC channel, or when the CID gets associated from the reception of an IR (this does not apply to the IR-DYN) with a different profile than the profile in the context.
当CID自ROHC信道创建以来首次与配置文件关联时，或者当CID从接收IR（这不适用于IR-DYN）中与与上下文中的配置文件不同的配置文件关联时，上下文被视为新上下文。
Context information is conceptually kept in a table. The context table is indexed using the CID, which is sent along with compressed headers and feedback information.
上下文信息在概念上保存在表中。上下文表使用CID编制索引，CID与压缩头和反馈信息一起发送。
The CID space can be either small, which means that CIDs can take the values 0 through 15, or large, which means that CIDs take values between 0 and 2^14 - 1 = 16383. Whether the CID space is large or small MUST be established, possibly by negotiation, before any compressed packet may be sent over the ROHC channel.
CID空间可以是小的，这意味着CID可以取0到15的值；也可以是大的，这意味着CID可以取0到2^14-1=16383之间的值。在通过ROHC信道发送任何压缩包之前，必须确定CID空间是大还是小，可能是通过协商。
The CID space is distinct for each channel, i.e., CID 3 over channel A and CID 3 over channel B do not refer to the same context, even if the endpoints of A and B are the same nodes. In particular, CIDs for
每个通道的CID空间是不同的，即通道A上的CID 3和通道B上的CID 3不引用相同的上下文，即使A和B的端点是相同的节点。特别是针对
any pair of ROHC channels are not related (two associated ROHC channels serving as feedback channels for one another do not even need to have CID spaces of the same size).
任何一对ROHC通道都是不相关的（作为彼此反馈通道的两个相关ROHC通道甚至不需要具有相同大小的CID空间）。
The ROHC channel is based on a number of parameters that form part of the established channel state and the per-context state. The state of the ROHC channel MUST be established before the first ROHC packet may be sent, which may be achieved using negotiation protocols provided by the link layer (see also [4], which describes an option for negotiation of ROHC parameters for PPP). This section describes some of this channel state information in an abstract way:
ROHC通道基于许多参数，这些参数构成已建立通道状态和每上下文状态的一部分。在发送第一个ROHC数据包之前，必须建立ROHC信道的状态，这可以使用链路层提供的协商协议实现（另请参见[4]，其中描述了PPP的ROHC参数协商选项）。本节以抽象的方式描述一些信道状态信息：
LARGE_CIDS: Boolean; if false, the small CID representation (0 octets or 1 prefix octet, covering CID 0 to 15) is used; if true, the large CID representation (1 or 2 embedded CID octets covering CID 0 to 16383) is used. See also 5.1.1 and 5.2.1.3.
大型CIDS：布尔型；如果为false，则使用小CID表示（0个八位字节或1个前缀八位字节，覆盖CID 0到15）；如果为true，则使用大CID表示（1或2个包含CID 0至16383的嵌入式CID八位字节）。另见5.1.1和5.2.1.3。
MAX_CID: Non-negative integer; highest CID number to be used by the compressor (note that this parameter is not coupled to, but in effect further constrained by, LARGE_CIDS). This value represents an agreement by the decompressor that it can provide sufficient memory resources to host at least MAX_CID+1 contexts; the decompressor MUST maintain established contexts within this space until either the CID gets re-used by the establishment of a new context, or until the channel is taken down.
MAX_CID：非负整数；压缩机使用的最高CID编号（请注意，此参数不与大的_CID耦合，但实际上受其进一步限制）。此值表示解压缩程序同意它可以提供足够的内存资源来承载至少MAX_CID+1个上下文；解压器必须在这个空间中维护已建立的上下文，直到CID被新上下文的建立重新使用，或者直到通道被关闭。
PROFILES: Set of non-negative integers, where each integer indicates a profile supported by both the compressor and the decompressor. A profile is identified by a 16-bit value, where the 8 LSB bits indicate the actual profile, and the 8 MSB bits indicate the variant of that profile. The ROHC compressed header format identifies the profile used with only the 8 LSB bits; this means that if multiple variants of the same profile are available for a ROHC channel, the PROFILES set after negotiation MUST NOT include more than one variant of the same profile. The compressor MUST NOT compress using a profile that is not in PROFILES.
PROFILES：一组非负整数，其中每个整数表示压缩程序和解压缩程序都支持的配置文件。配置文件由16位值标识，其中8个LSB位表示实际配置文件，8个MSB位表示该配置文件的变体。ROHC压缩头格式识别仅与8个LSB位一起使用的配置文件；这意味着，如果同一配置文件的多个变体可用于ROHC通道，协商后设置的配置文件不得包括同一配置文件的多个变体。压缩机不得使用不在外形中的外形进行压缩。
FEEDBACK_FOR: Optional reference to a ROHC channel in the opposite direction between the same compression endpoints. If provided, this parameter indicates to which other ROHC channel any feedback sent on this ROHC channel refers (see [5]).
反馈：在相同压缩端点之间的相反方向上可选参考ROHC通道。如果提供，该参数指示在该ROHC通道上发送的任何反馈指向哪个其他ROHC通道（见[5]）。
MRRU: Non-negative integer. Maximum Reconstructed Reception Unit. This is the size of the largest reconstructed unit in octets that the decompressor is expected to reassemble from segments (see Section 5.2.5). This size includes the segmentation CRC. If MRRU
MRRU：非负整数。最大重构接收单元。这是解压器预期从段重新组装的最大重建单元（以八位字节为单位）的大小（见第5.2.5节）。该大小包括分段CRC。如果MRRU
is negotiated to be 0, segmentation MUST NOT be used on the channel, and received segments MUST be discarded by the decompressor.
协商为0时，不得在通道上使用分段，并且解压缩程序必须丢弃接收到的分段。
As part of the negotiated channel parameters, the compressor and decompressor have through the MAX_CID parameter agreed on the highest context identification (CID) number to be used. By agreeing on the MAX_CID, the decompressor also agrees to provide memory resources to host at least MAX_CID+1 contexts, and an established context with a CID within this negotiated space SHOULD be kept by the decompressor until either the CID gets re-used, or the channel is taken down or re-negotiated.
作为协商通道参数的一部分，压缩器和解压缩器通过MAX_CID参数商定了要使用的最高上下文标识（CID）编号。通过同意MAX_CID，解压器还同意提供内存资源以承载至少MAX_CID+1上下文，并且解压器应保留在该协商空间内具有CID的已建立上下文，直到CID被重新使用，或通道被关闭或重新协商。
This section uses the following convention in the diagrams when representing various ROHC packet types, formats, and fields:
当表示各种ROHC数据包类型、格式和字段时，本节在图表中使用以下约定：
- colons ":" indicate that the part is optional - slashes "/" indicate variable length
- 冒号“：”表示该零件是可选的-斜杠“/”表示可变长度
The ROHC packet type indication scheme has been designed to provide optional padding, a feedback packet type, an optional Add-CID octet (which includes 4 bits of CID), and a simple segmentation and reassembly mechanism.
ROHC数据包类型指示方案旨在提供可选填充、反馈数据包类型、可选添加CID八位字节（包括4位CID）以及简单的分段和重新组装机制。
The following packet types are reserved at the ROHC framework level:
以下数据包类型在ROHC框架级别保留：
11100000 : Padding 1110nnnn : Add-CID octet (nnnn=CID with values 0x1 through 0xF) 11110 : Feedback 11111000 : IR-DYN packet 1111110 : IR packet 1111111 : Segment
11100000:填充1110nnnn:添加CID八位字节（nnnn=CID，值0x1到0xF）11110:反馈11111 000:IR-DYN数据包111111 0:IR数据包1111111:段
Other packet types can be defined and used by individual profiles:
其他数据包类型可由各个配置文件定义和使用：
0 : available (not reserved by ROHC framework) 10 : available (not reserved by ROHC framework) 110 : available (not reserved by ROHC framework) 1111101 : available (not reserved by ROHC framework) 11111001 : available (not reserved by ROHC framework)
0:可用（ROHC框架未保留）10:可用（ROHC框架未保留）110:可用（ROHC框架未保留）11111 01:可用（ROHC框架未保留）11111 001:可用（ROHC框架未保留）
A ROHC packet has the following general format:
ROHC数据包具有以下通用格式：
--- --- --- --- --- --- --- ---
: Padding :
--- --- --- --- --- --- --- ---
: Feedback :
--- --- --- --- --- --- --- ---
: Header :
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- ---
: Padding :
--- --- --- --- --- --- --- ---
: Feedback :
--- --- --- --- --- --- --- ---
: Header :
--- --- --- --- --- --- --- ---
: Payload :
--- --- --- --- --- --- --- ---
Padding: Any number (zero or more) of padding octets, where the format of a padding octet is as defined in Section 5.2.1.1.
填充：任何数量（零或更多）的填充八位字节，其中填充八位字节的格式如第5.2.1.1节所定义。
Feedback: Any number (zero or more) of feedback elements, where the format of a feedback element is as defined in Section 5.2.4.1.
反馈：任何数量（零或更多）的反馈元素，其中反馈元素的格式如第5.2.4.1节所定义。
Header: Either a profile-specific CO header (see Section 5.2.1.3), an IR or IR-DYN header (see Section 5.2.2), or a ROHC Segment (see Section 5.2.5). There can be at most one Header in a ROHC packet, but it may also be omitted (if the packet contains Feedback only).
标题：特定于配置文件的CO标题（见第5.2.1.3节）、IR或IR-DYN标题（见第5.2.2节）或ROHC段（见第5.2.5节）。ROHC数据包中最多可以有一个报头，但也可以省略（如果数据包仅包含反馈）。
Payload: Corresponds to zero or more octets of payload from the uncompressed packet, starting with the first octet in the uncompressed packet after the last header compressible by the current profile.
有效载荷：对应于来自未压缩数据包的零个或多个有效载荷八位组，从未压缩数据包中的第一个八位组开始，在当前配置文件可压缩的最后一个报头之后。
At least one of Feedback or Header MUST be present.
必须至少存在一个反馈或标题。
Padding octet:
填充八位组：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 0 0 0 0 |
+---+---+---+---+---+---+---+---+
Note: The Padding octet MUST NOT be interpreted as an Add-CID octet for CID 0.
注意：填充八位字节不能解释为CID 0的Add CID八位字节。
Add-CID octet:
添加CID八位字节：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 0 | CID |
+---+---+---+---+---+---+---+---+
CID: 0x1 through 0xF indicates CIDs 1 through 15.
CID:0x1到0xF表示CID 1到15。
Note: The Padding octet looks like an Add-CID octet for CID 0.
注意：填充八位字节看起来像CID 0的Add CID八位字节。
All ROHC packet types have the following general Header format:
所有ROHC数据包类型具有以下通用报头格式：
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CIDs
+--- --- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+--- --- --- --- ---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+
0 x-1 x 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CIDs
+--- --- --- --- ---+--- --- ---+
| type indication | body | 1 octet (8-x bits of body)
+--- --- --- --- ---+--- --- ---+
: :
/ 0, 1, or 2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
/ body / variable length
+---+---+---+---+---+---+---+---+
type indication: ROHC packet type.
类型指示：ROHC数据包类型。
body: Interpreted according to the packet type indication and CID information, as defined by individual profiles.
正文：根据数据包类型指示和CID信息进行解释，如各个配置文件所定义。
Thus, the header either starts with a packet type indication or has a packet type indication immediately following an Add-CID octet.
因此，报头要么以分组类型指示开始，要么紧跟在Add-CID八位组之后具有分组类型指示。
When the ROHC channel is configured with a small CID space:
当ROHC通道配置有小CID空间时：
o If an Add-CID immediately precedes the packet type indication, the packet has the CID of the Add-CID; otherwise, it has CID 0.
o 如果在数据包类型指示之前紧接着添加CID，则该数据包具有添加CID的CID；否则，它的CID为0。
o A small CID with the value 0 is represented using zero bits; therefore, a flow associated with CID 0 has no CID overhead in the compressed header. In such case, Header starts with a packet type indication.
o 值为0的小CID使用零位表示；因此，与CID 0关联的流在压缩标头中没有CID开销。在这种情况下，报头以数据包类型指示开始。
o A small CID with a value from 1 to 15 is represented using the Add-CID octet as described above. The Header starts with the Add-CID octet, followed by a packet type indication.
o 如上所述，使用Add CID八位字节表示值为1到15的小CID。报头以Add-CID八位字节开头，后跟数据包类型指示。
o There is no large CID in the Header.
o 收割台中没有大的CID。
When the ROHC channel is configured with a large CID space:
当ROHC通道配置有较大的CID空间时：
o The large CID is always present and is represented using the encoding scheme of Section 5.3.2, limited to two octets. In this case, the Header starts with a packet type indication.
o 大CID始终存在，并使用第5.3.2节的编码方案表示，仅限于两个八位字节。在这种情况下，报头以数据包类型指示开始。
IR packet types contain a profile identifier, which determines how the rest of the header is to be interpreted. They also associate a profile with a context. The stored profile parameter further determines the syntax and semantics of the packet type identifiers and packet types used with a specific context.
IR数据包类型包含一个配置文件标识符，该标识符确定如何解释报头的其余部分。它们还将概要文件与上下文关联。存储的概要文件参数进一步确定分组类型标识符的语法和语义以及与特定上下文一起使用的分组类型。
The IR and IR-DYN packets always update the context for all context-updating fields carried in the header. They never clear the context, except when initializing a new context (see Section 5.1.1), or unless the profile indicated in the Profile field specifies otherwise.
IR和IR-DYN数据包始终更新头中携带的所有上下文更新字段的上下文。它们从不清除上下文，除非在初始化新上下文时（见第5.1.1节），或者除非配置文件字段中指示的配置文件另有规定。
The IR header associates a CID with a profile, and typically also initializes the context. It can typically also refresh all (or parts of) the context. For IR, Header has the following general format:
IR头将CID与配置文件相关联，并且通常还初始化上下文。它通常还可以刷新所有（或部分）上下文。对于IR，标题具有以下通用格式：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 | x | IR type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
x: Profile specific information. Interpreted according to the profile indicated in the Profile field of the IR header.
x：配置文件特定信息。根据IR标题的profile字段中指示的profile进行解释。
Profile: The profile associated with the CID. In the IR header, the profile identifier is abbreviated to the 8 least significant bits (see Section 5.1.2).
配置文件：与CID关联的配置文件。在IR报头中，配置文件标识符缩写为8个最低有效位（见第5.1.2节）。
CRC: 8-bit CRC (see Section 5.3.1.1).
CRC：8位CRC（见第5.3.1.1节）。
Profile specific information: The content of this part of the IR header is defined by the individual profiles. It is interpreted according to the profile indicated in the Profile field.
配置文件特定信息：IR标题的这部分内容由各个配置文件定义。它根据profile字段中指示的profile进行解释。
In contrast to the IR header, the IR-DYN header can never initialize a non-initialized context. However, it can redefine what profile is associated with a context, if the profile indicated in the IR-DYN header allows this. Thus, this packet type is also reserved at the framework level. The IR-DYN header typically also initializes or refreshes parts of a context. For IR-DYN, Header has the following general format:
与IR头不同，IR-DYN头永远不能初始化未初始化的上下文。但是，如果IR-DYN标题中指示的配置文件允许，它可以重新定义与上下文关联的配置文件。因此，该分组类型也保留在框架级别。IR-DYN标头通常还初始化或刷新部分上下文。对于IR-DYN，标题具有以下通用格式：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if CID 1-15 and small CID
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 0 0 | IR-DYN type octet
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID / 1 or 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
| |
/ profile specific information / variable length
| |
+---+---+---+---+---+---+---+---+
Profile: The profile associated with the CID. This is abbreviated in the same way as in IR packets.
配置文件：与CID关联的配置文件。这与IR数据包中的缩写方式相同。
CRC: 8-bit CRC (see Section 5.3.1.1).
CRC：8位CRC（见第5.3.1.1节）。
Profile specific information: The content of this part of the IR-DYN header is defined by the individual profiles. It is interpreted according to the profile indicated in the Profile field.
配置文件特定信息：IR-DYN标题的这部分内容由各个配置文件定义。它根据profile字段中指示的profile进行解释。
Initially, all contexts are in no context state. Thus, all packets referencing a non-initialized context, except packets that have enough information on the static fields, cannot be decompressed by the decompressor.
最初，所有上下文都处于无上下文状态。因此，除具有关于静态字段的足够信息的包外，所有引用未初始化上下文的包都不能由解压缩器解压缩。
When the decompressor receives a packet of type IR, the profile indicated in the IR packet determines how it is to be processed.
当解压缩器接收到IR类型的数据包时，IR数据包中指示的配置文件确定如何处理该数据包。
o If the 8-bit CRC fails to verify the integrity of the Header, the packet MUST NOT be decompressed and delivered to upper layers. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, the logic used to determine what, if any, feedback to send is up to the implementation. However, it may be suitable to take no further actions, as any part of the IR header covered by the CRC may have caused the failure.
o 如果8位CRC无法验证报头的完整性，则不得解压缩数据包并将其传送到上层。如果上下文中指示了配置文件，则该配置文件的逻辑将确定要发送的反馈（如果有）。如果上下文中未注明概要文件，则用于确定要发送的反馈（如果有）的逻辑取决于实现。然而，不采取进一步的措施可能是合适的，因为CRC覆盖的IR报头的任何部分都可能导致故障。
When the decompressor receives a packet of type IR-DYN, the profile indicated in the IR-DYN packet determines how it is to be processed.
当解压缩器接收到IR-DYN类型的数据包时，IR-DYN数据包中指示的配置文件确定如何处理该数据包。
o If the 8-bit CRC fails to verify the integrity of the header, the packet MUST NOT be decompressed and delivered to upper layers. If a profile is indicated in the context, the logic of that profile determines what, if any, feedback is to be sent. If no profile is noted in the context, the logic used to determine what, if any, feedback to send is up to the implementation. However, it may be suitable to take no further actions, as any part of the IR-DYN header covered by the CRC may have caused the failure.
o 如果8位CRC无法验证报头的完整性，则不得解压缩数据包并将其传送到上层。如果上下文中指示了配置文件，则该配置文件的逻辑将确定要发送的反馈（如果有）。如果上下文中未注明概要文件，则用于确定要发送的反馈（如果有）的逻辑取决于实现。然而，不采取进一步的措施可能是合适的，因为CRC覆盖的IR-DYN报头的任何部分都可能导致故障。
o If the context has not already been initialized, the packet MUST NOT be decompressed and delivered to upper layers. The logic of the profile indicated in the IR-DYN header (if verified by the 8-bit CRC), determines what, if any, feedback is to be sent.
o 如果上下文尚未初始化，则不能解压缩数据包并将其传送到上层。IR-DYN报头中指示的配置文件逻辑（如果由8位CRC验证）确定要发送的反馈（如果有）。
If a parsing error occurs for any packet type, the decompressor MUST discard the packet without further processing. For example, a CID field is present in the compressed header when the large CID space is used for the ROHC channel, and the field is coded using the self-describing variable-length encoding of Section 5.3.2; if the field starts with 110 or 111, this would generate a parsing error for the decompressor because this field must not be encoded with a size larger than 2 octets.
如果任何数据包类型发生解析错误，解压缩程序必须丢弃该数据包，而无需进一步处理。例如，当大CID空间用于ROHC信道时，压缩报头中存在CID字段，并且该字段使用第5.3.2节的自描述变长编码进行编码；如果字段以110或111开头，这将为解压缩程序生成解析错误，因为此字段的编码大小不得大于2个八位字节。
It is RECOMMENDED that profiles disallow the decompressor to make a decompression attempt for packets carrying only a 3-bit CRC after it has invalidated some or all of the entire dynamic context, until a packet that contains sufficient information on the dynamic fields is received, decompressed, and successfully verified by a 7- or 8-bit CRC.
建议配置文件禁止解压器在使整个动态上下文的部分或全部无效后，对仅携带3位CRC的数据包进行解压尝试，直到接收、解压并通过7位或8位CRC成功验证包含足够动态字段信息的数据包。
Feedback carries information from the decompressor to compressor. Feedback can be sent over a ROHC channel that operates in the same direction as the feedback.
反馈将信息从减压器传送到压缩机。反馈可通过ROHC通道发送，该通道与反馈方向相同。
The general ROHC packet format allows transport of feedback using interspersion or piggybacking (see [5]), or a combination of both, over a ROHC channel. This is facilitated by the following properties:
通用的ROHC数据包格式允许通过ROHC信道使用散布或搭载（参见[5]）或两者的组合来传输反馈。以下特性有助于实现这一点：
Reserved packet type:
保留数据包类型：
A feedback packet type is reserved at the framework level. The packet type can carry variable-length feedback information.
在框架级别保留反馈数据包类型。包类型可以携带可变长度的反馈信息。
CID information:
CID信息：
The feedback information sent on a particular channel is passed to, and interpreted by, the compressor associated with feedback on that channel. Thus, each feedback element contains CID information from the channel for which the feedback is sent. The ROHC feedback scheme thus requires that a channel carries feedback to at most one compressor. How a compressor is associated with the feedback for a particular channel is outside the scope of this specification. See also [5].
在特定通道上发送的反馈信息被传递给与该通道上的反馈相关联的压缩器，并由压缩器进行解释。因此，每个反馈元素包含来自为其发送反馈的信道的CID信息。因此，ROHC反馈方案要求一个通道最多向一个压缩机传送反馈。压缩器如何与特定通道的反馈相关联超出了本规范的范围。另见[5]。
Length information:
长度信息：
The length of a feedback element can be determined by examining the first few octets of the feedback. This enables piggybacking of feedback, and also the concatenation of more than one feedback element in a packet. The length information thus decouples the decompressor from the associated same-side compressor, as the decompressor can extract the feedback information from the compressed header without parsing its content and hand over the extracted information.
反馈元素的长度可以通过检查反馈的前几个八位字节来确定。这可以实现反馈的搭载，也可以在一个数据包中串联多个反馈元素。因此，长度信息将解压器与相关联的同侧压缩器分离，因为解压器可以从压缩报头提取反馈信息，而无需解析其内容并移交提取的信息。
The association between compressor-decompressor pairs operating in opposite directions, for the purpose of exchanging piggyback and/or interspersed feedback, SHOULD be maintained for the lifetime of the ROHC channel. Otherwise, it is RECOMMENDED that the compressor be notified if the feedback channel is no longer available: the compressor SHOULD then restart compression by creating a new context for each packet flow, and SHOULD use a CID value that was not previously associated with the profile used to compress the flow.
在ROHC通道的使用寿命内，应保持反向运行的压缩机-减压器对之间的关联，以交换背载和/或分散反馈。否则，建议在反馈通道不再可用时通知压缩器：然后压缩器应通过为每个数据包流创建新上下文来重新启动压缩，并应使用以前未与用于压缩流的配置文件关联的CID值。
ROHC defines three different categories of feedback messages: acknowledgment (ACK), negative ACK (NACK), and NACK for the entire context (STATIC-NACK). Other types of information may be defined in profile-specific feedback information.
ROHC定义了三种不同类型的反馈消息：确认（ACK）、否定确认（NACK）和整个上下文的NACK（STATIC-NACK）。其他类型的信息可以在特定于概要文件的反馈信息中定义。
ACK : Acknowledges successful decompression of a packet. Indicates that the decompressor considers its context to be valid.
确认已成功解压缩数据包。指示解压缩程序认为其上下文有效。
NACK : Indicates that the decompressor considers some or all of the dynamic part of its context invalid.
NACK：表示解压缩程序认为其上下文的部分或全部动态部分无效。
STATIC-NACK : Indicates that the decompressor considers its entire static context invalid, or that it has not been established.
STATIC-NACK：表示解压缩程序认为其整个静态上下文无效，或者尚未建立。
Feedback sent on a ROHC channel consists of one or more concatenated feedback elements, where each feedback element has the following format:
ROHC通道上发送的反馈由一个或多个串联反馈元素组成，其中每个反馈元素具有以下格式：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID (5.3.2 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK data / variable length
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 0 | Code | feedback type
+---+---+---+---+---+---+---+---+
: Size : if Code = 0
+---+---+---+---+---+---+---+---+
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
: :
/ large CID (5.3.2 encoding) / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
/ FEEDBACK data / variable length
+---+---+---+---+---+---+---+---+
Code: 0 indicates that a Size octet is present. 1-7 indicates the size of the feedback data field, in octets.
代码：0表示存在大小八位字节。1-7表示反馈数据字段的大小，以八位字节为单位。
Size: Indicates the size of the feedback data field, in octets.
大小：表示反馈数据字段的大小，以八位字节为单位。
FEEDBACK data: FEEDBACK-1 or FEEDBACK-2 (see below).
反馈数据：反馈1或反馈2（见下文）。
CID information in a feedback element indicates the context for which feedback is sent. The LARGE_CIDS parameter that controls whether a large CID is present is taken from the channel state of the receiving compressor's channel, not from the state of the channel carrying the feedback.
反馈元素中的CID信息指示发送反馈的上下文。控制大CID是否存在的大CID参数取自接收压缩器信道的信道状态，而不是来自承载反馈的信道状态。
The large CID field, if present, is encoded according to Section 5.3.2, and it MUST NOT be encoded using more than 2 octets.
大CID字段（如果存在）根据第5.3.2节进行编码，且不得使用超过2个八位字节进行编码。
The FEEDBACK data field can have either of the following two formats:
反馈数据字段可以有以下两种格式之一：
FEEDBACK-1:
反馈-1：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| profile specific information | 1 octet
+---+---+---+---+---+---+---+---+
FEEDBACK-2:
反馈-2：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|Acktype| |
+---+---+ profile specific / at least 2 octets
/ information |
+---+---+---+---+---+---+---+---+
Acktype: 0 = ACK 1 = NACK 2 = STATIC-NACK 3 is reserved (MUST NOT be used. Otherwise unparseable.)
Acktype:0=ACK 1=NACK 2=STATIC-NACK 3被保留（不得使用。否则不可解析。）
ROHC defines a simple segmentation protocol. The compressor may perform segmentation, e.g., to accommodate packets that are larger than a specific size configured for the channel.
ROHC定义了一个简单的分段协议。压缩器可以执行分段，例如，以容纳大于为信道配置的特定大小的分组。
The ROHC segmentation protocol is not particularly efficient. It is not intended to replace link layer segmentation functions; these SHOULD be used whenever available and efficient for the task at hand.
ROHC分段协议不是特别有效。它不打算取代链路层分段功能；只要手头的任务可用且有效，就应使用这些工具。
The ROHC segmentation protocol has been designed with an assumption of in-order delivery of packets between the compressor and the decompressor, using only a CRC for error detection, and no sequence numbers. If in-order delivery cannot be guaranteed, ROHC segmentation MUST NOT be used.
ROHC分段协议的设计假设在压缩器和解压缩器之间按顺序传送数据包，仅使用CRC进行错误检测，而不使用序列号。如果无法保证订单交付，则不得使用ROHC分段。
The segmentation protocol also assumes that all segments of a ROHC packet corresponding to one context are received without interference from other ROHC packets over the channel, including any ROHC packet corresponding to a different context. Based on this assumption, segments do not carry CID information, and therefore cannot be associated with a specific context until all segments have been received and the whole unit has been reconstructed.
分段协议还假设在信道上接收到与一个上下文相对应的ROHC分组的所有分段时，没有来自其他ROHC分组的干扰，包括与不同上下文相对应的任何ROHC分组。基于此假设，段不携带CID信息，因此在接收到所有段并重建整个单元之前，不能与特定上下文关联。
ROHC segmentation is applied to the combination of the Header and the Payload fields of the ROHC packet, as defined in Section 5.2.1.
如第5.2.1节所定义，ROHC分段应用于ROHC数据包的报头和有效载荷字段的组合。
Segment format:
段格式：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F | segment type
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 1 | F | segment type
+---+---+---+---+---+---+---+---+
/ Segment / variable length
+---+---+---+---+---+---+---+---+
F: Final bit. If set, it indicates that this is the last segment of a reconstructed unit.
F:最后一位。如果设置，则表示这是重建单元的最后一段。
Padding and/or Feedback may precede the segment type octet. There is no per-segment CID, but CID information is of course part of the reconstructed unit. The reconstructed unit MUST NOT contain padding, segments, or feedback.
填充和/或反馈可能位于段类型八位字节之前。没有每段CID，但CID信息当然是重建单元的一部分。重构单元不得包含填充、分段或反馈。
When a final segment is received, the decompressor reassembles the segment carried in this packet and any non-final segments that immediately preceded it into a single reconstructed unit, in the order they were received. All segments for one reconstructed unit have to be received consecutively and in the correct order by the decompressor. If a non-segment ROHC packet directly follows a non-final segment, the reassembly of the current reconstructed unit is aborted and the decompressor MUST discard the non-final segments so far received on this channel.
当接收到最终段时，解压器按照接收顺序将该数据包中携带的段和紧接其之前的任何非最终段重新组装成单个重构单元。解压器必须以正确的顺序连续接收一个重建单元的所有段。如果非段ROHC数据包直接跟随非最终段，则当前重构单元的重新组装将中止，解压器必须丢弃该通道上迄今为止接收到的非最终段。
Reconstructed unit:
重建单位：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ Header / (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
: Payload : (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
/ Header / (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
: Payload : (see Section 5.2.1)
+---+---+---+---+---+---+---+---+
/ CRC / 4 octets
+---+---+---+---+---+---+---+---+
CRC: 32-bit CRC computed using the polynomial of Section 5.3.1.4.
CRC：使用第5.3.1.4节中的多项式计算的32位CRC。
If the reconstructed unit is 4 octets or less, or if the CRC fails, or if it is larger than the channel parameter MRRU (see Section
如果重建单元为4个八位字节或更少，或者CRC失败，或者如果它大于信道参数MRRU（参见第节
5.1.2), the reconstructed unit MUST be discarded by the decompressor. If the CRC succeeds, the reconstructed unit can be further processed.
5.1.2），解压器必须丢弃重构单元。如果CRC成功，则可以进一步处理重构单元。
This section describes how to calculate the CRCs used by ROHC. For all CRCs, the algorithm used to calculate the CRC is the same as the one used in [2], defined in Appendix A of this document, with the polynomials specified in subsequent sections.
本节介绍如何计算ROHC使用的CRC。对于所有CRC，用于计算CRC的算法与本文件附录A中定义的[2]中使用的算法相同，多项式在后续章节中规定。
The coverage for the 8-bit CRC in the IR and IR-DYN headers is profile-dependent, but it MUST cover at least the initial part of the header ending with the Profile field, including the CID or an Add-CID octet. Feedback and padding are not part of Header (Section 5.2.1) and are thus not included in the CRC calculation. As a rule of thumb for profile specifications, any other information that initializes the decompressor context SHOULD also be covered by a CRC.
IR和IR-DYN头中8位CRC的覆盖范围取决于配置文件，但它必须至少覆盖以配置文件字段结尾的头的初始部分，包括CID或Add CID八位字节。反馈和填充不是标题的一部分（第5.2.1节），因此不包括在CRC计算中。作为概要文件规范的经验法则，CRC还应涵盖初始化解压缩器上下文的任何其他信息。
More specifically, the 8-bit CRC does not cover only and entirely the original uncompressed header; therefore, it does not provide the means for the decompressor to verify a decompression attempt, or the means to verify the correctness of the entire decompressor context. However, when successful, it does provide enough robustness for the decompressor to update its context with the information carried within the IR or the IR-DYN header.
更具体地说，8位CRC不仅覆盖并且完全覆盖原始未压缩报头；因此，它不提供解压器验证解压尝试的方法，也不提供验证整个解压器上下文的正确性的方法。但是，如果成功，它确实为解压缩程序提供了足够的健壮性，以便使用IR或IR-DYN头中携带的信息更新其上下文。
The CRC polynomial for the 8-bit CRC is:
8位CRC的CRC多项式为：
C(x) = 1 + x + x^2 + x^8
C(x) = 1 + x + x^2 + x^8
When computing the CRC, the CRC field in the header is set to zero, and the initial content of the CRC register is set to all 1's.
计算CRC时，报头中的CRC字段设置为零，CRC寄存器的初始内容设置为全部1。
The 3-bit CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner.
压缩头中的3位CRC在压缩之前，通过以下方式计算整个原始头的所有八位字节。
The initial content of the CRC register is set to all 1's.
CRC寄存器的初始内容设置为所有1。
The polynomial for the 3-bit CRC is:
3位CRC的多项式为：
C(x) = 1 + x + x^3
C(x) = 1 + x + x^3
The purpose of the 3-bit CRC is to provide the means for the decompressor to verify the outcome of a decompression attempt for small compressed headers, and to detect context damage based on aggregated probability over a number of decompression attempts. It is however too weak to provide enough success guarantees from the decompression of one single header. Therefore, compressed headers carrying a 3-bit CRC are normally not suitable to perform context repairs at the decompressor; hence, profiles should refrain from allowing decompression of such a header when some or the entire decompressor context is assumed invalid.
3位CRC的目的是为解压器提供验证小型压缩头的解压尝试结果的方法，并基于多次解压尝试的聚合概率检测上下文损坏。但是，它太弱，无法从单个头的解压缩中提供足够的成功保证。因此，携带3位CRC的压缩报头通常不适合在解压缩器处执行上下文修复；因此，当假定某些或整个解压器上下文无效时，概要文件应避免允许解压这样的头。
The 7-bit CRC in compressed headers is calculated over all octets of the entire original header, before compression, in the following manner.
压缩头中的7位CRC在压缩之前，通过以下方式计算整个原始头的所有八位字节。
The initial content of the CRC register is set to all 1's.
CRC寄存器的初始内容设置为所有1。
The polynomial for the 7-bit CRC is:
7位CRC的多项式为：
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
C(x) = 1 + x + x^2 + x^3 + x^6 + x^7
The purpose of the 7-bit CRC is to provide the means for the decompressor to verify the outcome of a decompression attempt for a larger compressed header, and to provide enough protection to validate a context repair at the decompressor. The 7-bit CRC is strong enough to assume a repair to be successful from the decompression of one single header; hence, profiles may allow decompression of a header carrying a 7-bit CRC when some of the decompressor context is assumed invalid.
7位CRC的目的是为解压器提供验证较大压缩报头的解压尝试结果的手段，并提供足够的保护以验证解压器处的上下文修复。7位CRC足够强，可以假设从一个报头的解压缩成功修复；因此，当一些解压缩器上下文被假定为无效时，配置文件可以允许解压缩携带7位CRC的报头。
The 32-bit CRC is used by the segmentation scheme to verify the reconstructed unit, and it is thus calculated over the segmented unit, i.e., over the Header and the Payload fields of the ROHC packet.
分段方案使用32位CRC来验证重构单元，因此在分段单元上（即，在ROHC数据包的报头和有效载荷字段上）计算该CRC。
The initial content of the CRC register is set to all 1's.
CRC寄存器的初始内容设置为所有1。
The polynomial for the 32-bit CRC is:
32位CRC的多项式为：
C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 + x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32.
C（x）=x^0+x^1+x^2+x^4+x^5+x^7+x^8+x^10+x^11+x^12+x^16+x^22+x^23+x^26+x^32。
The purpose of the 32-bit CRC is to verify the reconstructed unit.
32位CRC的目的是验证重构单元。
The values of many fields and compression parameters can vary widely. To optimize the transfer of such values, a variable number of octets are used to encode them. The first few bits of the first octet determine the number of octets used:
许多字段和压缩参数的值可能变化很大。为了优化这些值的传输，使用可变数量的八位字节对它们进行编码。第一个八位字节的前几位决定使用的八位字节数：
First bit is 0: 1 octet. 7 bits transferred. Up to 127 decimal. Encoded octets in hexadecimal: 00 to 7F
第一位是0:1八位字节。传输7位。最多127位小数。十六进制编码的八位字节：00到7F
First bits are 10: 2 octets. 14 bits transferred. Up to 16 383 decimal. Encoded octets in hexadecimal: 80 00 to BF FF
第一位是10:2八位字节。传输14位。最多16 383位小数。十六进制编码的八位字节：80 00到BF FF
First bits are 110: 3 octets. 21 bits transferred. Up to 2 097 151 decimal. Encoded octets in hexadecimal: C0 00 00 to DF FF FF
第一位是110:3个八位字节。传输21位。最多2 097 151位小数。十六进制编码的八位字节：C000到DF FF
First bits are 111: 4 octets. 29 bits transferred. Up to 536 870 911 decimal. Encoded octets in hexadecimal: E0 00 00 00 to FF FF FF FF
第一位是111:4八位字节。传输29位。最多536 870 911十进制。十六进制编码的八位字节：E000到FF FF
This section describes the uncompressed ROHC profile. The profile identifier for this profile is 0x0000.
本节介绍未压缩的ROHC配置文件。此配置文件的配置文件标识符为0x0000。
Profile 0x0000 provides a way to send IP packets without compressing them. This can be used for any packet for which a compression profile is not available in the set of profiles supported by the ROHC channel, or for which compression is not desirable for some reason.
配置文件0x0000提供了一种在不压缩IP数据包的情况下发送IP数据包的方法。这可用于在ROHC信道支持的配置文件集中没有压缩配置文件的任何分组，或者出于某种原因不需要压缩的任何分组。
After initialization, the only overhead for sending packets using Profile 0x0000 is the size of the CID. When uncompressed packets are frequent, Profile 0x0000 should be associated with a CID the size of zero or one octet. Profile 0x0000 SHOULD be associated with at most one CID.
初始化后，使用配置文件0x0000发送数据包的唯一开销是CID的大小。当未压缩数据包频繁出现时，配置文件0x0000应与大小为零或一个八位字节的CID相关联。配置文件0x0000最多应与一个CID关联。
The initialization and refresh packet (IR packet) for Profile 0x0000 has the following Header format:
配置文件0x0000的初始化和刷新数据包（IR数据包）具有以下标头格式：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 |res|
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x00 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 0 |res|
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| Profile = 0x00 | 1 octet
+---+---+---+---+---+---+---+---+
| CRC | 1 octet
+---+---+---+---+---+---+---+---+
res: MUST be set to zero; otherwise, the decompressor MUST discard the packet.
res：必须设置为零；否则，解压缩程序必须丢弃数据包。
Profile: 0x00
配置文件：0x00
CRC: 8-bit CRC, computed using the polynomial of Section 5.3.1.1. The CRC covers the first octet of the IR Header through the Profile octet of the IR Header, i.e., it does not cover the CRC itself. Neither does it cover any preceding Padding or Feedback, nor the Payload.
CRC：8位CRC，使用第5.3.1.1节中的多项式计算。CRC通过IR报头的配置文件八位字节覆盖IR报头的第一个八位字节，即，它不覆盖CRC本身。它既不包含任何先前的填充或反馈，也不包含有效负载。
For the IR packet, Payload has the following format:
对于IR数据包，有效载荷具有以下格式：
--- --- --- --- --- --- --- ---
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- ---
: : (optional)
/ IP packet / variable length
: :
--- --- --- --- --- --- --- ---
IP packet: An uncompressed IP packet may be included in the IR packet. The decompressor determines if the IP packet is present by considering the length of the IR packet.
IP包：未压缩的IP包可能包含在IR包中。解压缩器通过考虑IR分组的长度来确定IP分组是否存在。
A Normal packet is a normal IP packet plus CID information. For the Normal Packet, the following format corresponds to the Header and Payload (as defined in Section 5.2.1):
正常数据包是一个正常的IP数据包加上CID信息。对于正常数据包，以下格式对应于报头和有效载荷（如第5.2.1节所定义）：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| first octet of IP packet |
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : if for small CIDs and (CID != 0)
+---+---+---+---+---+---+---+---+
| first octet of IP packet |
+---+---+---+---+---+---+---+---+
: :
/ 0-2 octets of CID info / 1-2 octets if for large CIDs
: :
+---+---+---+---+---+---+---+---+
| |
/ rest of IP packet / variable length
| |
+---+---+---+---+---+---+---+---+
Note that the first octet of the IP packet starts with the bit pattern 0100 (IPv4) or 0110 (IPv6). This does not conflict with any reserved packet types.
请注意，IP数据包的第一个八位字节以位模式0100（IPv4）或0110（IPv6）开始。这与任何保留的数据包类型都不冲突。
When the channel uses small CIDs, and profile 0x0000 is associated with a CID > 0, an Add-CID octet precedes the IP packet. When the channel uses large CIDs, the CID is placed so that it starts at the second octet of the combined Header/Payload format above.
当通道使用小CID，且配置文件0x0000与CID>0关联时，IP数据包前面会有一个Add CID八位组。当信道使用较大的CID时，放置CID以使其从上述组合报头/有效负载格式的第二个八位字节开始。
A Normal Packet may carry Padding and/or Feedback as any other ROHC packet, preceding the combined Header/Payload.
普通分组可以像任何其他ROHC分组一样在组合报头/有效载荷之前携带填充和/或反馈。
When an IR packet is received, the decompressor first validates its header using the 8-bit CRC.
当接收到IR数据包时，解压缩程序首先使用8位CRC验证其报头。
o If the header fails validation, the decompressor MUST NOT deliver the IP packet to upper layers.
o 如果报头未通过验证，解压缩程序不得将IP数据包传送到上层。
o If the header is successfully validated, the decompressor
o 如果成功验证了标头，则解压缩程序
1) initializes the context if it has no valid context for the given CID already associated to the specified profile,
1) 如果上下文没有与指定配置文件关联的给定CID的有效上下文，则初始化该上下文，
2) delivers the IP packet to upper layers if present,
2) 将IP数据包传送到上层（如果存在），
3) MAY send an ACK.
3) 可能会发送确认。
When any other packet is received while the decompressor has no context, it is discarded without further action.
当在解压器没有上下文的情况下接收到任何其他数据包时，它将被丢弃，无需进一步操作。
When a Normal packet is received and the decompressor has a valid context, the IP packet is extracted and delivered to upper layers.
当接收到正常数据包且解压器具有有效上下文时，将提取IP数据包并将其发送到上层。
The only kind of feedback defined by Profile 0x0000 is ACK, using the FEEDBACK-1 format of Section 5.2.4.1, where the value of the profile-specific octet in the FEEDBACK-1 is 0 (zero). The FEEDBACK-2 format is thus not defined for Profile 0x0000.
配置文件0x0000定义的唯一反馈类型是ACK，使用第5.2.4.1节的反馈-1格式，其中反馈-1中的配置文件特定八位字节的值为0（零）。因此，没有为概要文件0x0000定义反馈-2格式。
The ROHC protocol consists of a framework part and a profile part. The framework defines the mechanisms common to all profiles, while the profile defines the compression algorithm and profile specific packet formats.
ROHC协议由框架部分和概要文件部分组成。该框架定义了所有概要文件共有的机制，而概要文件定义了压缩算法和特定于概要文件的数据包格式。
Section 5 specifies the details of the ROHC framework. This section provides an informative overview of the elements that make a profile specification. The normative specification of individual profiles is outside the scope of this document.
第5节详细说明了ROHC框架。本节提供了构成纵断面规范的元素的信息性概述。单个外形的规范性规范不在本文件范围内。
A ROHC profile defines the elements that build up the compression protocol. A ROHC profile consists of:
ROHC配置文件定义了构成压缩协议的元素。ROHC配置文件包括：
Packet formats:
数据包格式：
o Bits-on-the-wire
o 线头
The profile defines the layout of the bits for profile-specific packet types that it defines, and for the profile-specific parts of packet types common to all profiles (e.g., IR and IR-DYN).
配置文件为其定义的配置文件特定分组类型以及所有配置文件（例如，IR和IR-DYN）通用的分组类型的配置文件特定部分定义位的布局。
o Field encodings
o 字段编码
Bits and groups of bits from the packet format layout, referred to as Compressed fields, represents the result of an encoding method specific for that compressed field within a specific packet format. The profile defines these encoding methods.
来自数据包格式布局的位和位组（称为压缩字段）表示特定数据包格式中该压缩字段的特定编码方法的结果。概要文件定义了这些编码方法。
o Updating properties
o 更新属性
The profile-specific packet formats may update the state of the decompressor, and may do so in different ways. The profile defines how individual profile-specific fields, or entire profile-specific packet types, update the decompressor context.
特定于简档的分组格式可以更新解压缩器的状态，并且可以以不同的方式这样做。配置文件定义了单个配置文件特定字段或整个配置文件特定数据包类型如何更新解压缩器上下文。
o Verification
o 验证
Packets that update the state of the decompressor are verified to prevent incorrect updates to the decompressor context. The profile defines the mechanisms used to verify the decompression of a packet.
对更新解压缩程序状态的数据包进行验证，以防止对解压缩程序上下文进行不正确的更新。概要文件定义了用于验证数据包解压缩的机制。
Context management:
上下文管理：
o Robustness logic
o 鲁棒性逻辑
Packets may be lost or reordered between the compressor and the decompressor. The profile defines mechanism to minimize the impacts of such events and prevent damage propagation.
数据包可能在压缩器和解压缩器之间丢失或重新排序。该概要定义了将此类事件的影响降至最低并防止损害传播的机制。
o Repair mechanism
o 修复机制
Despite the robustness logic, impairment events may still lead to decompression failure(s), and even to context damage at the decompressor. The profile defines context repair mechanisms, including feedback logic if used.
尽管存在健壮性逻辑，但损坏事件仍可能导致解压缩失败，甚至导致解压器的上下文损坏。概要文件定义了上下文修复机制，包括反馈逻辑（如果使用）。
Because encryption eliminates the redundancy that header compression schemes try to exploit, there is some inducement to forego encryption of headers in order to enable operation over low-bandwidth links.
由于加密消除了报头压缩方案试图利用的冗余，因此有一些诱因导致放弃报头加密，以便能够在低带宽链路上进行操作。
A malfunctioning or malicious header compressor could cause the header decompressor to reconstitute packets that do not match the original packets but still have valid headers and possibly also valid transport checksums. Such corruption may be detected with end-to-end authentication and integrity mechanisms, which will not be affected by the compression. Moreover, the ROHC header compression scheme uses an internal checksum for verification of reconstructed headers, which reduces the probability of producing decompressed headers not matching the original ones without this being noticed.
出现故障或恶意的报头压缩器可能会导致报头解压缩器重新生成与原始数据包不匹配但仍具有有效报头以及可能具有有效传输校验和的数据包。这种损坏可以通过端到端身份验证和完整性机制进行检测，而不会受到压缩的影响。此外，ROHC报头压缩方案使用内部校验和来验证重构报头，这降低了在没有注意到这一点的情况下生成与原始报头不匹配的解压缩报头的概率。
Denial-of-service attacks are possible if an intruder can introduce, for example, bogus IR, IR-DYN, or FEEDBACK packets onto the link and thereby cause compression efficiency to be reduced. However, an
如果入侵者可以在链路上引入（例如）伪造的IR、IR-DYN或反馈数据包，从而导致压缩效率降低，则可能发生拒绝服务攻击。但是,
intruder having the ability to inject arbitrary packets at the link layer in this manner raises additional security issues that dwarf those related to the use of header compression.
入侵者能够以这种方式在链路层注入任意数据包，这会引发额外的安全问题，使与使用报头压缩相关的安全问题相形见绌。
An IANA registry for "RObust Header Compression (ROHC) Profile Identifiers" [21] was created by RFC 3095 [3]. The assignment policy, as outlined by RFC 3095, is the following:
RFC 3095[3]创建了一个IANA注册表，用于“鲁棒头压缩（ROHC）配置文件标识符”[21]。RFC 3095概述的派遣政策如下：
The ROHC profile identifier is a non-negative integer. In many negotiation protocols, it will be represented as a 16-bit value. Due to the way the profile identifier is abbreviated in ROHC packets, the 8 least significant bits of the profile identifier have a special significance: Two profile identifiers with identical 8 LSBs should be assigned only if the higher-numbered one is intended to supersede the lower-numbered one. To highlight this relationship, profile identifiers should be given in hexadecimal (as in 0x1234, which would for example supersede 0x0A34).
ROHC配置文件标识符为非负整数。在许多协商协议中，它将表示为16位值。由于ROHC数据包中配置文件标识符的缩写方式，配置文件标识符的8个最低有效位具有特殊意义：只有当较高编号的配置文件标识符要取代较低编号的配置文件标识符时，才应分配具有相同8个LSB的两个配置文件标识符。为了突出显示这种关系，配置文件标识符应该以十六进制形式给出（例如，0x1234将取代0x0A34）。
Following the policies outlined in [22], the IANA policy for assigning new values for the profile identifier shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible. In the 8 LSBs, the range 0 to 127 is reserved for IETF standard-track specifications; the range 128 to 254 is available for other specifications that meet this requirement (such as Informational RFCs). The LSB value 255 is reserved for future extensibility of the present specification.
根据[22]中概述的政策，IANA为配置文件标识符分配新值的政策应符合规范要求：值及其含义必须记录在RFC或其他永久性且随时可用的参考文件中，足够详细，以确保独立实现之间的互操作性。在8个LSB中，0到127的范围为IETF标准轨道规范保留；128到254的范围可用于满足此要求的其他规范（如信息RFC）。LSB值255保留用于本规范的未来扩展。
The following profile identifiers have so far been allocated:
到目前为止，已分配以下配置文件标识符：
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 4995
0x0001 ROHC RTP RFC 3095
0x0002 ROHC UDP RFC 3095
0x0003 ROHC ESP RFC 3095
0x0004 ROHC IP RFC 3843
0x0005 ROHC LLA RFC 3242
0x0105 ROHC LLA with R-mode RFC 3408
0x0006 ROHC TCP RFC 4996
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0008 ROHC UDP-Lite RFC 4019
Profile Identifier Usage Reference
------------------ ---------------------- ---------
0x0000 ROHC uncompressed RFC 4995
0x0001 ROHC RTP RFC 3095
0x0002 ROHC UDP RFC 3095
0x0003 ROHC ESP RFC 3095
0x0004 ROHC IP RFC 3843
0x0005 ROHC LLA RFC 3242
0x0105 ROHC LLA with R-mode RFC 3408
0x0006 ROHC TCP RFC 4996
0x0007 ROHC RTP/UDP-Lite RFC 4019
0x0008 ROHC UDP-Lite RFC 4019
New profiles will need new identifiers to be assigned by the IANA, but this document does not require any additional IANA action.
新的配置文件需要IANA分配新的标识符，但本文件不需要IANA采取任何其他行动。
The authors would like to acknowledge all who have contributed to previous ROHC work, and especially to the authors of RFC 3095 [3], which is the technical basis for this document. Thanks also to the various individuals who contributed to the RFC 3095 corrections and clarifications document [6], from which technical contents, when applicable, have been incorporated into this document. Committed WG document reviewers were Carl Knutsson and Biplab Sarkar, who reviewed the document during working group last-call.
作者要感谢所有对之前ROHC工作做出贡献的人，尤其是RFC 3095[3]的作者，RFC 3095[3]是本文件的技术基础。还感谢为RFC 3095更正和澄清文件[6]作出贡献的各种个人，适用时，技术内容已纳入本文件。致力于工作组文件审查的是Carl Knutsson和Biplab Sarkar，他们在工作组上次电话会议期间审查了该文件。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[2] 辛普森，W.“HDLC类框架中的PPP”，STD 51，RFC 16621994年7月。
[3] 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.
[3] 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月。
[4] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[4] Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[5] Jonsson, L-E., "RObust Header Compression (ROHC): Terminology and Channel Mapping Examples", RFC 3759, April 2004.
[5] Jonsson，L-E，“鲁棒头压缩（ROHC）：术语和信道映射示例”，RFC 3759，2004年4月。
[6] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
[6] Jonsson，L-E.，Sandlund，K.，Pelletier，G.，和P.Kremer，“鲁棒头压缩（ROHC）：对RFC 3095的修正和澄清”，RFC 4815，2007年2月。
[7] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets", RFC 4224, January 2006.
[7] Pelletier，G.，Jonsson，L-E.，和K.Sandlund，“鲁棒报头压缩（ROHC）：可以重新排序数据包的信道上的ROHC”，RFC 42242006年1月。
[8] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP Lite", Work in Progress, September 2006.
[8] Pelletier，G.和K.Sandlund，“鲁棒头压缩版本2（ROHCv2）：RTP、UDP、IP、ESP和UDP Lite的配置文件”，正在进行的工作，2006年9月。
[9] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", RFC 4996, July 2007.
[9] Pelletier，G.，Sandlund，K.，Jonsson，L-E.，和M.West，“鲁棒头压缩（ROHC）：TCP/IP配置文件（ROHC-TCP）”，RFC 49962007年7月。
[10] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[10] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[11] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[12] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[12] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[13] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[14] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[14] 《传输控制协议》，标准7，RFC 793，1981年9月。
[15] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990.
[15] Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC 1144，1990年2月。
[16] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[16] Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[17] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[17] Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[18] Degermark, M., "Requirements for robust IP/UDP/RTP header compression", RFC 3096, July 2001.
[18] Degermark，M.“鲁棒IP/UDP/RTP报头压缩的要求”，RFC 3096，2001年7月。
[19] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[19] Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.，和P.Ruddy，“具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 35452003年7月。
[20] Degermark, M., Hannu, H., Jonsson, L.E., and K. Svanbro, "Evaluation of CRTP Performance over Cellular Radio Networks", IEEE Personal Communication Magazine, Volume 7, number 4, pp. 20-25, August 2000.
[20] Degermark，M.，Hannu，H.，Jonsson，L.E.，和K.Svanbro，“蜂窝无线网络上CRTP性能的评估”，《IEEE个人通信杂志》，第7卷，第4期，第20-25页，2000年8月。
[21] IANA registry, "RObust Header Compression (ROHC) Profile
Identifiers", http://www.iana.org/assignments/rohc-pro-ids
[21] IANA registry, "RObust Header Compression (ROHC) Profile
Identifiers", http://www.iana.org/assignments/rohc-pro-ids
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[22] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRC in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#!/usr/bin/perl -w
use strict;
#=================================
#
# ROHC CRC demo - Carsten Bormann cabo@tzi.org 2001-08-02
#
# This little demo shows the four types of CRC in use in RFC 3095,
# the specification for robust header compression. Type your data in
# hexadecimal form and then press Control+D.
#
#---------------------------------
#
# utility
#
sub dump_bytes($) {
my $x = shift;
my $i;
for ($i = 0; $i < length($x); ) {
printf("%02x ", ord(substr($x, $i, 1)));
printf("\n") if (++$i % 16 == 0);
}
printf("\n") if ($i % 16 != 0);
}
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
#---------------------------------
#
# The CRC calculation algorithm.
#
sub do_crc($$$) {
my $nbits = shift;
my $poly = shift;
my $string = shift;
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
my $crc = ($nbits == 32 ? 0xffffffff : (1 << $nbits) - 1);
for (my $i = 0; $i < length($string); ++$i) {
my $byte = ord(substr($string, $i, 1));
for( my $b = 0; $b < 8; $b++ ) {
if (($crc & 1) ^ ($byte & 1)) {
$crc >>= 1;
$crc ^= $poly;
} else {
$crc >>= 1;
}
$byte >>= 1;
}
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
printf "%2d bits, ", $nbits;
printf "CRC: %02x\n", $crc;
}
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# Test harness
#
$/ = undef;
$_ = <>; # read until EOF
my $string = ""; # extract all that looks hex:
s/([0-9a-fA-F][0-9a-fA-F])/$string .= chr(hex($1)), ""/eg;
dump_bytes($string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies this is complemented like for PPP
# (this differs from 8, 7, and 3-bit CRC)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 32-bit segmentation CRC
# Note that the text implies this is complemented like for PPP
# (this differs from 8, 7, and 3-bit CRC)
#
# C(x) = x^0 + x^1 + x^2 + x^4 + x^5 + x^7 + x^8 + x^10 +
# x^11 + x^12 + x^16 + x^22 + x^23 + x^26 + x^32
#
do_crc(32, 0xedb88320, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 8-bit IR/IR-DYN CRC
#
# C(x) = x^0 + x^1 + x^2 + x^8
#
do_crc(8, 0xe0, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 7-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^2 + x^3 + x^6 + x^7
#
do_crc(7, 0x79, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
#---------------------------------
#
# 3-bit FO/SO CRC
#
# C(x) = x^0 + x^1 + x^3
#
do_crc(3, 0x6, $string);
Authors' Addresses
作者地址
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden
Lars Erik Jonsson Optand 737 SE-831 92奥斯特松，瑞典
Phone: +46 70 365 20 58
EMail: lars-erik@lejonsson.com
Phone: +46 70 365 20 58
EMail: lars-erik@lejonsson.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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。