Network Working Group L-E. Jonsson
Request for Comments: 3843 G. Pelletier
Category: Standards Track Ericsson
June 2004
Network Working Group L-E. Jonsson
Request for Comments: 3843 G. Pelletier
Category: Standards Track Ericsson
June 2004
RObust Header Compression (ROHC): A Compression Profile for IP
健壮的报头压缩（ROHC）：IP的压缩配置文件
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines a ROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length.
原始的健壮报头压缩（ROHC）RFC（RFC 3095）定义了报头压缩框架，以及IP/UDP/RTP、IP/ESP（封装安全负载）、IP/UDP的压缩协议（配置文件），以及未压缩数据包流的配置文件。然而，未定义仅用于IP压缩的剖面，该剖面已在RFC 3095中确定为缺失部分。本文档为IP定义了ROHC压缩配置文件，类似于RFC 3095定义的IP/UDP配置文件，但简化为排除UDP，并增强为压缩任意长度的IP头链。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. ROHC IP Compression (Profile 0x0004) . . . . . . . . . . . . . 3
3.1. Static Chain Termination . . . . . . . . . . . . . . . . 3
3.2. Handling Multiple Levels of IP Headers . . . . . . . . . 3
3.3. Constant IP-ID . . . . . . . . . . . . . . . . . . . . . 4
3.4. Additional Mode Transition Logic . . . . . . . . . . . . 6
3.5. Initialization . . . . . . . . . . . . . . . . . . . . . 8
3.6. Packet Types . . . . . . . . . . . . . . . . . . . . . . 8
3.7. The CONTEXT_MEMORY Feedback Option . . . . . . . . . . . 10
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. ROHC IP Compression (Profile 0x0004) . . . . . . . . . . . . . 3
3.1. Static Chain Termination . . . . . . . . . . . . . . . . 3
3.2. Handling Multiple Levels of IP Headers . . . . . . . . . 3
3.3. Constant IP-ID . . . . . . . . . . . . . . . . . . . . . 4
3.4. Additional Mode Transition Logic . . . . . . . . . . . . 6
3.5. Initialization . . . . . . . . . . . . . . . . . . . . . 8
3.6. Packet Types . . . . . . . . . . . . . . . . . . . . . . 8
3.7. The CONTEXT_MEMORY Feedback Option . . . . . . . . . . . 10
4. Security Considerations. . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Detailed Procedures for Canceling Mode Transitions. . 12
A.1. Transition from Optimistic to Reliable Mode. . . . . . . 12
A.2. Transition from Unidirectional to Reliable Mode. . . . . 13
A.3. Transition from Reliable to Optimistic Mode. . . . . . . 13
A.4. Transition Back to Unidirectional Mode . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Detailed Procedures for Canceling Mode Transitions. . 12
A.1. Transition from Optimistic to Reliable Mode. . . . . . . 12
A.2. Transition from Unidirectional to Reliable Mode. . . . . 13
A.3. Transition from Reliable to Optimistic Mode. . . . . . . 13
A.4. Transition Back to Unidirectional Mode . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16
The original RObust Header Compression (ROHC) RFC [RFC-3095] defines a framework for header compression, along with compression protocols (profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload), IP/UDP, and also a profile for uncompressed packet streams. The profile for uncompressed data was defined to provide a means to encapsulate all traffic over a link within ROHC packets. Through this profile, the lower layers do not have to provide multiplexing for different packet types, but instead ROHC can handle any packet stream, even if compression profiles for all kinds of packet streams have not yet been defined or implemented over the link.
原始的健壮报头压缩（ROHC）RFC[RFC-3095]定义了报头压缩框架，以及IP/UDP/RTP、IP/ESP（封装安全负载）、IP/UDP的压缩协议（配置文件），以及未压缩数据包流的配置文件。未压缩数据的配置文件被定义为提供一种方法来封装ROHC数据包中链路上的所有流量。通过该配置文件，较低层不必为不同的分组类型提供多路复用，而是ROHC可以处理任何分组流，即使链路上尚未定义或实现所有类型分组流的压缩配置文件。
Although the profile without compression is simple and can tunnel arbitrary packets, it has of course a major weakness in that it does not compress the headers at all. When considering that normally all packets are expected to be IP [RFC-791, RFC-2460] packets, and that the IP header often represents a major part of the total header, a useful alternative to no compression would for most packets be compression of the IP header only. Unfortunately, such a profile was not defined in [RFC-3095], and this has thus been identified as an important missing piece in the ROHC toolbox.
虽然没有压缩的概要文件很简单，可以通过隧道传输任意数据包，但它当然有一个主要缺点，即根本不压缩头。当考虑到通常所有数据包都预期为IP[RFC-791，RFC-2460]数据包，并且IP报头通常代表总报头的主要部分时，对于大多数数据包来说，不压缩的一个有用替代方案是仅压缩IP报头。不幸的是，[RFC-3095]中没有定义这样一个配置文件，因此被确定为ROHC工具箱中重要的缺失部分。
This document addresses this missing compression support and defines a ROHC compression profile for IP [RFC-791, RFC-2460] only, similar to the IP/UDP profile defined by [RFC-3095], but simplified to exclude UDP. Due to the similarities with the IP/UDP profile, the IP compression profile is described based on the IP/UDP profile, mainly covering differences. The most important differences are a different way of terminating the static header chain, and the capability of compressing IP header chains of arbitrary length.
本文档解决了这一缺失的压缩支持，并仅为IP[RFC-791，RFC-2460]定义了ROHC压缩配置文件，类似于[RFC-3095]定义的IP/UDP配置文件，但简化为排除UDP。由于与IP/UDP配置文件的相似性，IP压缩配置文件是在IP/UDP配置文件的基础上描述的，主要包括不同之处。最重要的区别是终止静态头链的不同方式，以及压缩任意长度的IP头链的能力。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
ROHC UDP
ROHC UDP
"ROHC UDP" in this document refers to the IP/UDP profile (Profile 0x0002) as defined in [RFC-3095].
本文件中的“ROHC UDP”是指[RFC-3095]中定义的IP/UDP配置文件（配置文件0x0002）。
In general, there are no major differences between the ROHC UDP profile and the IP profile (ROHC IP) defined in this document, since the removal of UDP has no impact on the compression mechanisms in principle. As for ROHC UDP, the compressor generates a 16-bit sequence number which increases by one for each packet compressed in the packet stream, simply called SN below. The most important difference between this profile and ROHC UDP is about static chain termination and the handling of multiple IP headers. Unless stated explicitly below, mechanisms and formats are the same as for ROHC UDP.
一般来说，ROHC UDP配置文件与本文档中定义的IP配置文件（ROHC IP）之间没有重大差异，因为删除UDP原则上不会影响压缩机制。对于ROHC UDP，压缩器生成一个16位序列号，对于包流中压缩的每个包，该序列号增加一个，下面简称为SN。此配置文件与ROHC UDP之间最重要的区别在于静态链终止和多个IP头的处理。除非下文明确说明，否则机制和格式与ROHC UDP相同。
One difference for IP-only compression, compared to IP/UDP compression, is related to the termination of the static chain in IR headers. For the UDP profile, the chain always ends with a UDP header part, which per definition provides the boundaries for the chain. The UDP header is also the last header in the uncompressed packet (except for a potential application header). For the IP-only profile, there is no single last header that per profile definition terminates the chain. Instead, the static chain is terminated if the "Next Header / Protocol" field of a static IP header part indicates anything but IP (IPinIP or IPv6). Alternatively, the compressor can choose to end the static chain at any IP header, and indicate this by setting the MSB of the IP version field to 1 (0xC for IPv4 or 0xE for IPv6). The decompressor must store this indication in the context for correct decompression of subsequent headers. Note that the IP version field in decompressed headers must be restored to its original value.
与IP/UDP压缩相比，纯IP压缩的一个区别在于IR报头中静态链的终止。对于UDP配置文件，链始终以UDP头部分结束，根据定义，该部分提供链的边界。UDP报头也是未压缩数据包中的最后一个报头（潜在应用程序报头除外）。对于仅限IP的配置文件，每个配置文件定义都没有终止链的最后一个头。相反，如果静态IP报头部分的“下一个报头/协议”字段指示除IP以外的任何内容（IPNIP或IPv6），则静态链终止。或者，压缩器可以选择在任何IP头结束静态链，并通过将IP版本字段的MSB设置为1（对于IPv4为0xC，对于IPv6为0xE）来指示这一点。解压缩程序必须将此指示存储在上下文中，以便正确解压缩后续头。请注意，解压缩标头中的IP版本字段必须还原为其原始值。
The ROHC IR and IR-DYN packets defined in [RFC-3095] are used to communicate static and/or dynamic parts of a context. For each of the compression profiles defined in [RFC-3095], there is a single last header in the header chain that clearly marks the termination of the static chain. The length of the dynamic chain is then inferred from the static chain in the IR header itself, or from the static chain in the context for the IR-DYN header. The length of both static and dynamic chains may thus be of arbitrary length and may, in theory, initialize a context with an arbitrary number of IP levels.
[RFC-3095]中定义的ROHC IR和IR-DYN数据包用于通信上下文的静态和/或动态部分。对于[RFC-3095]中定义的每个压缩配置文件，在头链中有一个最后的头，清楚地标记静态链的终止。然后从IR报头本身中的静态链或IR-DYN报头上下文中的静态链推断动态链的长度。因此，静态和动态链的长度可以是任意长度，并且在理论上可以用任意数量的IP级别初始化上下文。
However, the general compressed header formats defined in [RFC-3095, section 5.7.] specifies that at most two levels of IP headers (the 'Inner' and the 'Outer' level of IP headers) may be included in a compressed header. Specifically, the format defined for Extension 3 [RFC-3095, section 5.7.5.] can only carry one single 'Outer' IP header. In addition, while list compression may be used to compress other types of headers, it cannot be used to compress additional IP headers, as IP headers may not be part of an extension header chain in compressed headers [RFC-3095, section 5.8.].
但是，[RFC-3095，第5.7节]中定义的通用压缩头格式规定，压缩头中最多可包含两个级别的IP头（IP头的“内部”和“外部”级别）。具体而言，为扩展3定义的格式[RFC-3095，第5.7.5节]只能携带一个“外部”IP头。此外，虽然列表压缩可用于压缩其他类型的头，但不能用于压缩其他IP头，因为IP头可能不是压缩头中扩展头链的一部分[RFC-3095，第5.8节]。
For the compression profiles defined in [RFC-3095], the consequence is that at most two levels of IP headers can be compressed. In other words, the presence of additional IP headers at best partially disables header compression, as the compressor will only be allowed to send IR and IR-DYN packets in such cases.
对于[RFC-3095]中定义的压缩配置文件，其结果是最多可以压缩两级IP头。换句话说，附加IP报头的存在最多只能部分禁用报头压缩，因为在这种情况下，压缩器将只允许发送IR和IR-DYN数据包。
For the compression of IP headers only, the additional IP headers would however not have to cause header compression to be disabled because there is no single packet type that ends the compressed chain. The excess IP headers could simply be left uncompressed by implicitly terminating the static and dynamic chains after at most two levels of IP headers.
但是，对于仅压缩IP报头而言，附加IP报头不必导致禁用报头压缩，因为不存在结束压缩链的单一数据包类型。通过在最多两个级别的IP头之后隐式终止静态和动态链，可以简单地使多余的IP头保持未压缩状态。
The IP-only profile defined in this document goes one step further and supports compression of an arbitrary number of IP levels. This is achieved by adding a dynamic chain to the general format of compressed headers, to include the header part of each IP level in excess of the first two.
本文档中定义的仅限IP的配置文件更进一步，支持压缩任意数量的IP级别。这是通过向压缩头的通用格式添加动态链来实现的，以包括每个IP级别的头部分，超过前两个级别。
As explained above, the static chain within IR packets can be of arbitrary length, and the chain is terminated by the presence of a non-IP header (not IPinIP nor IPv6). Alternatively, the chain may be explicitly terminated with a special code value in the IP version field, as described in section 3.1. The dynamic chain is structured analogously.
如上所述，IR分组中的静态链可以具有任意长度，并且该链通过非IP报头（不是IPinIP或IPv6）的存在而终止。或者，如第3.1节所述，可以使用IP版本字段中的特殊代码值显式终止链。动态链的结构类似。
For compressed headers, the information related to the initial two IP headers is carried as for the IP/UDP profile, and a chain of dynamic header information is added to the end of the compressed header for each and every additional IP header. Thus, this additional data structure is exactly the same as the one used in IR and IR-DYN packets. The length of the chain is inferred from the chain of static parameters in the context. While a dynamic chain carries dynamically changing parameters using an uncompressed representation, this ensures that flows with arbitrary levels of IP headers will not impair compression efficiency.
对于压缩报头，与初始两个IP报头相关的信息与IP/UDP配置文件一样被携带，并且对于每个额外的IP报头，动态报头信息链被添加到压缩报头的末尾。因此，此附加数据结构与IR和IR-DYN数据包中使用的数据结构完全相同。链的长度是从上下文中的静态参数链推断出来的。虽然动态链使用未压缩表示携带动态变化的参数，但这确保具有任意级别IP头的流不会影响压缩效率。
Most IPv4 stacks assign an IP-ID according to the value of a counter, increasing by one for each outgoing packet. ROHC UDP compresses the IP-ID field using offset IP-ID encoding based on the UDP SN [RFC-3095]. For stacks generating IP-ID values using a pseudo-random number generator, the field is not compressed and is sent as-is in its entirety as additional octets after the compressed header.
大多数IPv4堆栈根据计数器的值分配IP-ID，每个传出数据包增加一个。ROHC UDP使用基于UDP SN的偏移IP-ID编码压缩IP-ID字段[RFC-3095]。对于使用伪随机数生成器生成IP-ID值的堆栈，字段不会被压缩，而是作为压缩头之后的附加八位字节整体发送。
Cases have also been found where an IPv4 stack uses a constant value for the IP Identifier. When the IP-ID field is constant, it cannot be compressed using offset IP-ID encoding and the field must be sent in its entirety. This overhead can be avoided with the addition of a flag within the dynamic part of the chain used to initialize the IPv4 header, as follow:
还发现了IPv4堆栈使用常量值作为IP标识符的情况。当IP-ID字段为常量时，无法使用偏移IP-ID编码对其进行压缩，必须完整发送该字段。通过在用于初始化IPv4报头的链的动态部分添加标志，可以避免此开销，如下所示：
Dynamic part:
动态部分：
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
| Type of Service |
+---+---+---+---+---+---+---+---+
| Time to Live |
+---+---+---+---+---+---+---+---+
/ Identification / 2 octets
+---+---+---+---+---+---+---+---+
| DF|RND|NBO|SID| 0 |
+---+---+---+---+---+---+---+---+
/ Generic extension header list / variable length
+---+---+---+---+---+---+---+---+
SID: Static IP Identifier.
SID：静态IP标识符。
For IR and IR-DYN packets, the logic is the same as for ROHC UDP with the addition that field(SID) must be kept in the context.
对于IR和IR-DYN数据包，逻辑与ROHC UDP相同，只是增加了字段（SID）必须保留在上下文中。
For compressed headers other than IR and IR-DYN:
对于非IR和IR-DYN的压缩头：
If value(RND) = 0 and context(SID) = 0, hdr(IP-ID) is compressed using Offset IP-ID encoding (see [RFC-3095 section 4.5.5]) using p = 0 and default-slope(IP-ID offset) = 0.
如果值（RND）=0且上下文（SID）=0，则使用偏移IP-ID编码（参见[RFC-3095第4.5.5节]）压缩hdr（IP-ID），使用p=0和默认斜率（IP-ID偏移）=0。
If value(RND) = 0 and context(SID) = 1, hdr(IP-ID) is constant and compressed away; hdr(IP-ID) is the value of context(IP-ID).
如果值（RND）=0，上下文（SID）=1，则hdr（IP-ID）是常量并被压缩掉；hdr（IP-ID）是上下文（IP-ID）的值。
If value(RND) = 1, IP-ID is the uncompressed hdr(IP-ID). IP-ID is then passed as additional octets at the end of the compressed header, after any extensions.
如果值（RND）=1，则IP-ID是未压缩的hdr（IP-ID）。然后，在任何扩展之后，IP-ID在压缩头的末尾作为额外的八位字节传递。
Note: Only IR and IR-DYN packets can update context(SID).
注意：只有IR和IR-DYN数据包可以更新上下文（SID）。
Note: All other fields are the same as for ROHC UDP [RFC-3095].
注：所有其他字段与ROHC UDP[RFC-3095]相同。
The profiles defined in [RFC-3095] operate using different modes of compression. A mode transition can be requested once a packet has reached the decompressor by sending feedback indicating the desired mode. As per the specifications found in [RFC-3095], the compressor is compelled to honor such requests.
[RFC-3095]中定义的外形使用不同的压缩模式运行。一旦数据包到达解压缩器，就可以通过发送指示所需模式的反馈来请求模式转换。根据[RFC-3095]中的规范，压缩机必须满足此类要求。
For the IP profile defined in this document, the Mode parameter for the value mode = 0 (packet types UOR-2, IR and IR-DYN) is redefined to allow the compressor to decline a mode transition requested by the decompressor:
对于本文档中定义的IP配置文件，值Mode=0（数据包类型UOR-2、IR和IR-DYN）的Mode参数被重新定义，以允许压缩器拒绝解压缩器请求的模式转换：
Mode: Compression mode. 0 = (C)ancel Mode Transition
Mode: Compression mode. 0 = (C)ancel Mode Transition
Upon receiving the Mode parameter set to '0', the decompressor MUST stay in its current mode of operation and SHOULD refrain from sending further mode transition requests for the declined mode for a certain amount of time.
在接收到设置为“0”的模式参数后，解压缩器必须保持其当前操作模式，并应在一定时间内避免发送拒绝模式的进一步模式转换请求。
More specifically, with reference to the parameters C_TRANS, C_MODE, D_TRANS, and D_MODE defined in [RFC-3095, section 5.6.1.], the following modifications apply when the compressor cancels a mode transition:
更具体地说，关于[RFC-3095，第5.6.1节]中定义的参数C_TRANS、C_MODE、D_TRANS和D_MODE，当压缩机取消模式转换时，以下修改适用：
Parameters for the compressor side:
压缩机侧的参数：
- C_MODE:
- C_模式：
This value must not be changed when sending mode information within packets if the mode parameter is set to '0' (as a response to a mode transition request from the decompressor).
如果模式参数设置为“0”（作为对来自解压缩程序的模式转换请求的响应），则在数据包内发送模式信息时，不得更改此值。
- C_TRANS:
- C_TRANS：
C_TRANS is (P)ending when receiving a mode transition request from the decompressor. C_TRANS is set to (D)one when the compressor receives an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode parameter set to the mode in use at the time the mode transition request was initiated.
C_TRANS（P）在收到来自解压缩器的模式转换请求时结束。当压缩机接收到UOR-2、IR-DYN或IR数据包的ACK时，C_TRANS被设置为（D）1，该数据包随模式参数一起发送，设置为启动模式转换请求时使用的模式。
Parameters for the decompressor side:
减压器侧的参数：
- D_MODE:
- D_模式：
D_MODE MUST remain unchanged when receiving a UOR-2, an IR-DYN, or an IR packet sent with the mode parameter set to '0'.
当接收到UOR-2、IR-DYN或模式参数设置为“0”的IR数据包时，D_模式必须保持不变。
- D_TRANS:
- D_TRANS：
D_TRANS is (P)ending when a UOR-2, IR-DYN, or IR packet sent with the mode parameter set to '0' is received. It is set to (D)one when a packet of type 1 or 0 corresponding to the unchanged mode is received.
当接收到模式参数设置为“0”的UOR-2、IR-DYN或IR数据包时，D_TRANS（P）结束。当接收到对应于未改变模式的类型1或0的分组时，它被设置为（D）1。
The resulting mode transition procedure is described below:
产生的模式转换程序如下所述：
Compressor Decompressor
----------------------------------------------
C_MODE = X | | D_MODE = X
| Mode Request(Y) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = X | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = X
| ACK(SN,X) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ X-0, X-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
Compressor Decompressor
----------------------------------------------
C_MODE = X | | D_MODE = X
| Mode Request(Y) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = X | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = X
| ACK(SN,X) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ X-0, X-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
where X: mode in use before the mode transition was initiated Y: mode requested by the decompressor C: (C)ancel mode transition
其中，启动模式转换之前使用的X:mode Y:mode由解压缩程序请求C:（C）取消模式转换
The static context for ROHC IP compression can be initialized in either of two ways:
ROHC IP压缩的静态上下文可以通过以下两种方式之一初始化：
1) By using an IR packet as in ROHC UDP, where the profile is 0x0004, and the static chain ends with the static part of an IP header, where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field indicates termination (see section 3.1). At the compressor, SN is initialized to a random value when the first IR packet is sent.
1) 通过使用ROHC UDP中的IR数据包，其中配置文件为0x0004，静态链以IP报头的静态部分结束，其中下一个报头/协议字段具有除IPNIP（4）或IPv6（41）[协议]之外的任何值，或者IP版本字段指示终止（见第3.1节）。在压缩器处，当发送第一IR分组时，SN被初始化为随机值。
2) By reusing an existing context. This is done with an IR-DYN packet, identifying profile 0x0004, where the dynamic chain corresponds to the prefix of the existing static chain, ending with an IP header where the Next Header/Protocol field has any value but IPinIP (4) or IPv6 (41) [PROTOCOL], or where the IP version field indicates termination (see section 3.1). At the compressor, SN is initialized to a random value when the first IR-DYN packet is sent.
2) 通过重用现有上下文。这是通过识别配置文件0x0004的IR-DYN数据包完成的，其中动态链对应于现有静态链的前缀，以IP报头结束，其中下一个报头/协议字段具有除IPNIP（4）或IPv6（41）[协议]以外的任何值，或者IP版本字段指示终止（参见第3.1节）。在压缩器处，当发送第一IR-DYN分组时，SN被初始化为随机值。
For ROHC IP, the dynamic part of an IR or IR-DYN packet is similar to the one for ROHC UDP, with a two-octet field containing the SN present at the end of the dynamic chain in IR and IR-DYN packets. It should be noted that the static and dynamic chains have an arbitrary length, and the SN is added only once, at the end of the dynamic chain in IR and IR-DYN packets.
对于ROHC IP，IR或IR-DYN数据包的动态部分类似于ROHC UDP的动态部分，两个八位组字段包含在IR和IR-DYN数据包动态链末端的SN。应当注意，静态和动态链具有任意长度，并且SN仅添加一次，在IR和IR-DYN分组中的动态链的末端。
Except for one new feedback option (see section 3.7), the only packet format that differs from ROHC UDP is the general format for compressed packets, which has no UDP checksum in the end. Instead, it ends with a list of dynamic header portions, one for each IP header above the initial two (if any, as indicated by the presence of corresponding header portions in the static chain).
除了一个新的反馈选项（见第3.7节），唯一不同于ROHC UDP的数据包格式是压缩数据包的通用格式，它最后没有UDP校验和。相反，它以动态报头部分的列表结束，在最初的两个IP报头之上的每个IP报头一个（如果有的话，如静态链中存在相应的报头部分所示）。
The general format for a compressed header is thus as follows:
因此，压缩头的一般格式如下：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : |
+---+---+---+---+---+---+---+---+ |
| first octet of base header | |
+---+---+---+---+---+---+---+---+ |
: : |
/ 0, 1, or 2 octets of CID / |
: : |
+---+---+---+---+---+---+---+---+ |
/ remainder of base header / |
+---+---+---+---+---+---+---+---+ |
: : |
/ Extension / |
: : |
--- --- --- --- --- --- --- --- |
: : |
+ IP-ID of outer IPv4 header +
: : (see section 5.7 of [RFC-3095])
--- --- --- --- --- --- --- ---
/ AH data for outer list / |
--- --- --- --- --- --- --- --- |
: : |
+ GRE checksum + |
: : |
--- --- --- --- --- --- --- --- |
: : |
+ IP-ID of inner IPv4 header + |
: : |
--- --- --- --- --- --- --- --- |
/ AH data for inner list / |
--- --- --- --- --- --- --- --- |
: : |
+ GRE checksum + |
: : |
--- --- --- --- --- --- --- ---
: List of :
/ Dynamic chains / variable, given by static chain
: for additional IP headers : (includes no SN)
--- --- --- --- --- --- --- ---
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : |
+---+---+---+---+---+---+---+---+ |
| first octet of base header | |
+---+---+---+---+---+---+---+---+ |
: : |
/ 0, 1, or 2 octets of CID / |
: : |
+---+---+---+---+---+---+---+---+ |
/ remainder of base header / |
+---+---+---+---+---+---+---+---+ |
: : |
/ Extension / |
: : |
--- --- --- --- --- --- --- --- |
: : |
+ IP-ID of outer IPv4 header +
: : (see section 5.7 of [RFC-3095])
--- --- --- --- --- --- --- ---
/ AH data for outer list / |
--- --- --- --- --- --- --- --- |
: : |
+ GRE checksum + |
: : |
--- --- --- --- --- --- --- --- |
: : |
+ IP-ID of inner IPv4 header + |
: : |
--- --- --- --- --- --- --- --- |
/ AH data for inner list / |
--- --- --- --- --- --- --- --- |
: : |
+ GRE checksum + |
: : |
--- --- --- --- --- --- --- ---
: List of :
/ Dynamic chains / variable, given by static chain
: for additional IP headers : (includes no SN)
--- --- --- --- --- --- --- ---
Note that the list of dynamic chains for the additional IP headers in compressed packets do not have a sequence number at the end of the chain, as SN is present within compressed base headers.
注意，压缩包中附加IP报头的动态链列表在链的末尾没有序列号，因为SN存在于压缩的基本报头中。
The CONTEXT_MEMORY option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream, as the stream is currently compressed.
CONTEXT_MEMORY选项通知压缩器，解压缩器没有足够的内存资源来处理数据包流的上下文，因为数据流当前已被压缩。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Opt Type = 9 | Opt Len = 0 |
+---+---+---+---+---+---+---+---+
When receiving a CONTEXT_MEMORY option, the compressor SHOULD take actions to compress the packet stream in a way that requires less decompressor memory resources, or stop compressing the packet stream.
当接收到CONTEXT_MEMORY选项时，压缩器应采取措施以减少解压缩器内存资源的方式压缩数据包流，或停止压缩数据包流。
The security considerations of [RFC-3095] apply equally to this document, without exceptions or additions.
[RFC-3095]的安全注意事项同样适用于本文件，无例外或补充。
ROHC profile identifier 0x0004 has been reserved by the IANA for the profile defined in this document.
IANA已为本文档中定义的配置文件保留ROHC配置文件标识符0x0004。
The authors would like to thank Carsten Bormann, Fredrik Lindstrom, Tommy Lundemo, and especially the committed document reviewers Kristofer Sandlund and Mark West, for valuable input and review.
作者要感谢Carsten Bormann、Fredrik Lindstrom、Tommy Lundemo，尤其是致力于文档审阅的Kristofer Sandlund和Mark West，他们提供了宝贵的意见和评论。
[RFC-791] Postel, J., "Internet Protocol", RFC 791, September 1981.
[RFC-791]Postel，J.，“互联网协议”，RFC 7911981年9月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC-3095] 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)", RFC 3095, July 2001.
[RFC-3095]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）”，RFC 3095，2001年7月。
[PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at:
http://www.iana.org/assignments/protocol-numbers
[PROTOCOL] "Assigned Internet Protocol Numbers", IANA registry at:
http://www.iana.org/assignments/protocol-numbers
The profiles defined in [RFC-3095] operate using different modes of compression: Unidirectional (U-Mode), Bi-directional Optimistic (O-Mode), and Bi-directional Reliable (R-Mode). Compression always starts in the U-Mode, and mode transitions can only be initiated by the decompressor [RFC-3095, section 5.6.]. A mode transition can be requested once a packet has reached the decompressor by sending feedback indicating the desired mode.
[RFC-3095]中定义的剖面使用不同的压缩模式运行：单向（U模式）、双向乐观（O模式）和双向可靠（R模式）。压缩总是在U模式下开始，模式转换只能由解压缩器启动[RFC-3095，第5.6节]。一旦数据包到达解压缩器，就可以通过发送指示所需模式的反馈来请求模式转换。
With reference to the parameters C_TRANS, C_MODE, D_TRANS, and D_MODE defined in [RFC-3095, section 5.6.1.], the following sub-sections describe the resulting procedures when a compressor declines a mode transition request from the decompressor as described in section 3.4.
参考[RFC-3095，第5.6.1节]中定义的参数C_-TRANS、C_-MODE、D_-TRANS和D_-MODE，以下小节描述了压缩机拒绝第3.4节中所述的减压器模式转换请求时产生的程序。
When the decompressor initiates a mode transition from Optimistic to Reliable mode, the cancellation of the transition procedure is as follows:
当解压缩器启动从乐观模式到可靠模式的模式转换时，转换过程的取消如下所示：
Compressor Decompressor
----------------------------------------------
| |
| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
Compressor Decompressor
----------------------------------------------
| |
| ACK(R)/NACK(R) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_TRANS = P
|->-.. | D_MODE = O
| ACK(SN,O) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
The compressor must not send packet types 1 or 0 when C_TRANS is P, i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C. When the decompressor receives a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C, it must keep the value D_MODE as O and set D_TRANS to P. When the decompressor receives packet types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
当C_TRANS为P时，压缩机不得发送数据包类型1或0，即，在收到UOR-2、IR-DYN或IR数据包的确认（发送时模式转换参数设置为C）。当解压器接收到UOR-2、IR-DYN或IR数据包，发送时模式转换参数设置为C，它必须将值D_MODE保持为O，并将D_TRANS设置为P。当解压缩程序接收到数据包类型0或1时，在确认UOR-2、IR-DYN或IR数据包后，它将D_TRANS设置为D。
The cancellation of a transition from Unidirectional to Reliable mode follows the same procedure as defined in section 4.2 above.
从单向模式到可靠模式转换的取消遵循上述第4.2节规定的相同程序。
When the decompressor initiates a mode transition from Reliable to Optimistic mode, the cancellation of the transition procedure is described as follows:
当解压缩器启动从可靠模式到乐观模式的模式转换时，转换过程的取消描述如下：
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = R | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_MODE = R
|->-.. |
| ACK(SN,R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ R-0, R-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
Compressor Decompressor
----------------------------------------------
| |
| ACK(O)/NACK(O) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = R | |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-| D_MODE = R
|->-.. |
| ACK(SN,R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| |
|->->->-+ R-0, R-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
| |
The compressor must not send packet types 1 or 0 when C_TRANS is P, i.e., not until it has received an ACK for a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C. When the decompressor receives a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C, it must keep the value D_MODE as R. When the decompressor receives packet types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
当C_TRANS为P时，压缩机不得发送数据包类型1或0，即，在收到UOR-2、IR-DYN或IR数据包的确认（发送时模式转换参数设置为C）。当解压器接收到UOR-2、IR-DYN或IR数据包，发送时模式转换参数设置为C，它必须将值D_MODE保持为R。当解压缩程序接收到数据包类型0或1时，在确认UOR-2、IR-DYN或IR数据包后，它将D_TRANS设置为D。
When the decompressor initiates a mode transition from Reliable or Optimistic mode back to Unidirectional mode, the cancellation of the transition procedure is as follows:
当解压缩器启动从可靠或乐观模式到单向模式的模式转换时，转换过程的取消如下：
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O/R| |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-|
|->-.. |
| ACK(SN,O/R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| R-0, R-1* or |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
D_MODE = O/R
Compressor Decompressor
----------------------------------------------
| |
| ACK(U)/NACK(U) +-<-<-<-| D_TRANS = I
| +-<-<-<-<-<-<-<-+ |
C_TRANS = P |-<-<-<-+ |
C_MODE = O/R| |
|->->->-+ IR/IR-DYN/UOR-2(SN,C) |
| +->->->->->->->-+ |
|->-.. +->->->-|
|->-.. |
| ACK(SN,O/R) +-<-<-<-|
| +-<-<-<-<-<-<-<-+ |
C_TRANS = D |-<-<-<-+ |
| R-0, R-1* or |
|->->->-+ UO-0, UO-1* |
| +->->->->->->->-+ |
| +->->->-| D_TRANS = D
D_MODE = O/R
When the decompressor receives a UOR-2, IR-DYN, or IR packet sent with the mode transition parameter set to C, it must keep the value D_MODE to the bi-directional mode already in use (either O- or R-mode). After ACKing the first UOR-2(C), IR-DYN(C), or IR(C), the decompressor MUST continue to send feedback with the Mode parameter set to the bi-directional mode in use (either O- or R-mode) until it receives packet types 0 or 1. When the decompressor receives packet types 0 or 1, after having ACKed a UOR-2, IR-DYN, or IR packet, it sets D_TRANS to D.
当解压器接收到模式转换参数设置为C时发送的UOR-2、IR-DYN或IR数据包时，它必须将值D_mode保持为已在使用的双向模式（O模式或R模式）。在确认第一个UOR-2（C）、IR-DYN（C）或IR（C）后，解压缩器必须继续发送反馈，并将模式参数设置为正在使用的双向模式（O-或R-模式），直到接收到数据包类型0或1。当解压缩程序在确认UOR-2、IR-DYN或IR数据包后接收到数据包类型0或1时，它将D_TRANS设置为D。
Authors' Addresses
作者地址
Lars-Erik Jonsson Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Lars Erik Jonsson Ericsson AB信箱920 SE-971 28 Lulea，瑞典
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Ghyslain Pelletier Ericsson AB信箱920 SE-971 28 Lulea，瑞典
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Phone: +46 8 404 29 43
Fax: +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。