Network Working Group G. Pelletier
Request for Comments: 4019 Ericsson AB
Category: Standards Track April 2005
Network Working Group G. Pelletier
Request for Comments: 4019 Ericsson AB
Category: Standards Track April 2005
RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
健壮的报头压缩（ROHC）：用户数据报协议（UDP）Lite的配置文件
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095.
本文档定义了用于压缩实时传输协议、用户数据报协议Lite、互联网协议（RTP/UDP Lite/IP）数据包和UDP Lite/IP的健壮报头压缩（ROHC）配置文件。这些配置文件是根据它们与RFC 3095中指定的UDP配置文件的差异定义的。
Table of Contents
目录
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations...................................... 6
4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters...................................... 7
5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic............... 9
1. Introduction.................................................. 2
2. Terminology................................................... 3
3. Background.................................................... 3
3.1. Overview of the UDP-Lite Protocol....................... 3
3.2. Expected Behaviours of UDP-Lite Flows................... 5
3.2.1. Per-Packet Behavior............................. 5
3.2.2. Inter-Packet Behavior........................... 5
3.2.3. Per-Flow Behavior............................... 5
3.3. Header Field Classification............................. 5
4. Rationale behind the Design of ROHC Profiles for UDP-Lite..... 6
4.1. Design Motivations...................................... 6
4.2. ROHC Considerations..................................... 6
5. ROHC Profiles for UDP-Lite.................................... 6
5.1. Context Parameters...................................... 7
5.2. Initialization.......................................... 8
5.2.1. Initialization of the UDP-Lite Header [1]....... 8
5.2.2. Compressor and Decompressor Logic............... 9
5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.......................................... 13
6. Security Considerations....................................... 14
7. IANA Considerations........................................... 14
8. Acknowledgments............................................... 15
9. References.................................................... 15
9.1. Normative References.................................... 15
9.2. Informative References.................................. 15
Appendix A. Detailed Classification of Header Fields............. 17
Appendix B. Detailed Format of the CCE Packet Type............... 20
Author's Address.................................................. 22
Full Copyright Statement.......................................... 23
5.3. Packet Formats.......................................... 9
5.3.1. General Packet Format........................... 9
5.3.2. Packet Type CCE: CCE(), CCE(ON), and CCE(OFF)... 10
5.3.2.1. Properties of CCE():.................. 11
5.3.2.2. Properties of CCE(ON):................ 11
5.3.2.3. Properties of CCE(OFF):............... 12
5.4. Compressor Logic........................................ 12
5.5. Decompressor Logic...................................... 12
5.6. Additional Mode Transition Logic........................ 13
5.7. The CONTEXT_MEMORY Feedback Option...................... 13
5.8. Constant IP-ID.......................................... 13
6. Security Considerations....................................... 14
7. IANA Considerations........................................... 14
8. Acknowledgments............................................... 15
9. References.................................................... 15
9.1. Normative References.................................... 15
9.2. Informative References.................................. 15
Appendix A. Detailed Classification of Header Fields............. 17
Appendix B. Detailed Format of the CCE Packet Type............... 20
Author's Address.................................................. 22
Full Copyright Statement.......................................... 23
The ROHC WG has developed a header compression framework on top of which various profiles can be defined for different protocol sets or compression strategies. Due to the demands of the cellular industry for an efficient way to transport voice over IP over wireless, ROHC [2] has mainly focused on compression of IP/UDP/RTP headers, which are generous in size, especially compared to the payloads often carried by packets with these headers.
ROHC工作组开发了一个头部压缩框架，在此框架之上，可以为不同的协议集或压缩策略定义各种概要文件。由于蜂窝行业对通过无线传输IP语音的有效方式的需求，ROHC[2]主要关注IP/UDP/RTP报头的压缩，其大小非常大，尤其是与具有这些报头的数据包通常携带的有效负载相比。
ROHC RTP has become a very efficient, robust, and capable compression scheme, able to compress the headers down to a total size of one octet only. Also, transparency is guaranteed to an extremely high extent, even when residual bit errors are present in compressed headers delivered to the decompressor.
ROHC-RTP已经成为一种非常高效、健壮、功能强大的压缩方案，能够将报头压缩到总大小仅为一个八位字节。此外，即使在发送到解压缩器的压缩头中存在残余比特错误时，也能在极高程度上保证透明度。
UDP-Lite [4] is a transport protocol similar to the UDP protocol [7]. UDP-Lite is useful for applications designed with the capability to tolerate errors in the payload, for which receiving damaged data is better than dealing with the loss of entire packets. This may be particularly suitable when packets are transported over link technologies in which data can be partially damaged, such as wireless links.
UDP Lite[4]是一种与UDP协议[7]类似的传输协议。UDP Lite对于设计为能够容忍有效负载中的错误的应用程序非常有用，因为接收损坏的数据比处理整个数据包的丢失要好。当分组通过链路技术传输时，这可能特别合适，在链路技术中，数据可能会部分损坏，例如无线链路。
Although these transport protocols are very similar, ROHC profiles must be defined separately for robust compression of UDP-Lite headers because UDP-Lite does not share the same protocol identifier with UDP. Also, the UDP-Lite Checksum Coverage field does not share the semantics of the corresponding UDP Length field, and as a consequence it cannot always be inferred anymore.
尽管这些传输协议非常相似，但必须单独定义ROHC配置文件，以便对UDP Lite头进行健壮的压缩，因为UDP Lite与UDP不共享相同的协议标识符。此外，UDP Lite校验和覆盖率字段不共享相应UDP长度字段的语义，因此无法再始终对其进行推断。
This document defines two ROHC profiles for efficient compression of UDP-Lite headers. The objective of this document is to provide simple modifications to the corresponding ROHC profiles for UDP, specified in RFC 3095 [2]. In addition, the ROHC profiles for UDP-Lite support some of the mechanisms defined in the profile for compression of IP headers [3] (ROHC IP-Only). This specification includes support for compression of multiple IP headers and for compressing IP-ID fields with constant behavior, as well as improved mode transition logic and a feedback option for decompressors with limited memory resources.
本文档定义了两个ROHC配置文件，用于高效压缩UDP Lite头。本文件的目的是对RFC 3095[2]中规定的UDP的相应ROHC配置文件进行简单修改。此外，UDP Lite的ROHC配置文件支持配置文件中定义的IP头压缩机制[3]（仅限ROHC IP）。该规范包括对多个IP头的压缩和对具有恒定行为的IP-ID字段的压缩的支持，以及对具有有限内存资源的解压器的改进模式转换逻辑和反馈选项的支持。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD, "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中的说明进行解释。
ROHC RTP : RTP/UDP/IP profile 0x0001 defined in RFC 3095 [2]. ROHC UDP : UDP/IP profile 0x0002 defined in RFC 3095 [2]. ROHC UDP-Lite : UDP-Lite/IP profile defined in this document. ROHC RTP/UDP-Lite: RTP/UDP-Lite/IP profile defined in this document.
ROHC RTP:RFC 3095[2]中定义的RTP/UDP/IP配置文件0x0001。ROHC UDP:RFC 3095[2]中定义的UDP/IP配置文件0x0002。ROHC UDP Lite：本文档中定义的UDP Lite/IP配置文件。ROHC RTP/UDP Lite：本文档中定义的RTP/UDP Lite/IP配置文件。
UDP-Lite is a transport protocol defined as an independent variant of the UDP transport protocol. UDP-Lite is very similar to UDP, and it allows applications that can tolerate errors in the payload to use a checksum with an optional partial coverage. This is particularly useful with IPv6 [6], in which the use of the transport-layer checksum is mandatory.
UDP Lite是一种传输协议，定义为UDP传输协议的独立变体。UDP Lite与UDP非常相似，它允许能够容忍负载中的错误的应用程序使用具有可选部分覆盖的校验和。这对于IPv6[6]特别有用，在IPv6[6]中，必须使用传输层校验和。
UDP-Lite replaces the Length field of the UDP header with a Checksum Coverage field. This field indicates the number of octets covered by the 16-bit checksum, which is applied on a per-packet basis. The coverage area always includes the UDP-Lite header and may cover the entire packet, in which case UDP-Lite becomes semantically identical to UDP. UDP-Lite and UDP do not share the same protocol identifier.
UDP Lite将UDP标头的长度字段替换为校验和覆盖率字段。此字段表示16位校验和所覆盖的八位字节数，该校验和按每个数据包应用。覆盖区域始终包括UDP Lite报头，并可能覆盖整个数据包，在这种情况下，UDP Lite在语义上与UDP相同。UDP Lite和UDP不共享相同的协议标识符。
The UDP-Lite header format:
UDP Lite标头格式：
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
0 15 16 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| Checksum | |
| Coverage | Checksum |
+--------+--------+--------+--------+
| |
: Payload :
| |
+-----------------------------------+
Like the UDP checksum, the UDP-Lite checksum is an end-to-end mechanism against erroneous delivery of error sensitive data. This checksum is mandatory with IPv6 [5] for both protocols. However, unlike its UDP counterpart, the UDP-Lite checksum may not be transmitted as all zeroes and cannot be disabled for IPv4 [5]. For UDP, if the checksum is disabled (IPv4 only), the Checksum field maintains a constant value and is normally not sent by the header compression scheme. If the UDP checksum is enabled (mandatory for IPv6), such an unpredictable field cannot be compressed and is sent uncompressed. The UDP Length field, however, is always redundant and can be provided by the IP module. Header compression schemes do not normally transmit any bits of information for this field, as its value can be inferred from the link layer.
与UDP校验和一样，UDP Lite校验和也是一种端到端机制，用于防止错误敏感数据的错误传递。对于这两个协议，IPv6[5]必须使用此校验和。但是，与UDP对应项不同，UDP Lite校验和不能作为全零传输，也不能对IPv4禁用[5]。对于UDP，如果校验和被禁用（仅限IPv4），校验和字段将保持一个常量值，并且通常不会由报头压缩方案发送。如果启用了UDP校验和（对于IPv6是必需的），则无法压缩此类不可预测的字段，并以未压缩的方式发送。但是，UDP长度字段始终是冗余的，可以由IP模块提供。报头压缩方案通常不传输该字段的任何信息位，因为其值可以从链路层推断出来。
For UDP-Lite, the checksum also has unpredictable values, and this field must always be included as-is in the compressed header for both IPv4 and IPv6. Furthermore, as the UDP Length field is redefined as the Checksum Coverage field by UDP-Lite, this leads to different properties for this field from a header-compression perspective.
对于UDP Lite，校验和也有不可预测的值，该字段必须始终包含在IPv4和IPv6的压缩头中。此外，由于UDP Lite将UDP长度字段重新定义为校验和覆盖率字段，因此从报头压缩的角度来看，这会导致该字段具有不同的属性。
The following summarizes the relationship between UDP and UDP-Lite:
以下总结了UDP和UDP Lite之间的关系：
- UDP-Lite and UDP have different protocol identifiers. - The UDP-Lite checksum cannot be disabled for IPv4. - UDP-Lite redefines the UDP Length field as the Checksum Coverage field, with different semantics. - UDP-Lite is semantically equivalent to UDP when the Checksum Coverage field indicates the total length of the packet.
- UDP Lite和UDP具有不同的协议标识符。-无法为IPv4禁用UDP Lite校验和。-UDP Lite使用不同的语义将UDP长度字段重新定义为校验和覆盖率字段。-当校验和覆盖率字段指示数据包的总长度时，UDP Lite在语义上等同于UDP。
The next section provides a more detailed discussion of the behavior of the Checksum Coverage field of UDP-Lite in relation to header compression.
下一节将更详细地讨论UDP Lite的校验和覆盖率字段与头压缩的关系。
As mentioned in the previous section, the checksum coverage value is applied independently of other packets that may belong to the same flow. Specifically, the value of the checksum coverage may indicate that the UDP-Lite packet is either entirely covered by the checksum or covered up to some boundary less than the packet size but including the UDP-Lite header.
如前一节所述，校验和覆盖值独立于可能属于同一流的其他数据包应用。具体地，校验和覆盖率的值可以指示UDP-Lite分组或者完全被校验和覆盖，或者覆盖到小于分组大小但包括UDP-Lite报头的某个边界。
In relation to each other, UDP-Lite packets may exhibit one of three possible change patterns, where within a sequence of packets the value of the Checksum Coverage field is
就彼此而言，UDP-Lite分组可以表现出三种可能的变化模式之一，其中在分组序列中，校验和覆盖字段的值为
1. changing, while covering the entire packet; 2. unchanging, covering up to a fixed boundary within the packet; or 3. changing, but it does not follow any specific pattern.
1. 改变，同时覆盖整个包；2.不变，覆盖到包内的固定边界；或3。改变，但它不遵循任何特定的模式。
The first pattern above corresponds to the semantics of UDP, when the UDP checksum is enabled. For this case, the checksum coverage field varies according to the packet length and may be inferred from the IP header, as is the UDP Length field value.
当启用UDP校验和时，上面的第一个模式对应于UDP的语义。对于这种情况，校验和覆盖范围字段根据数据包长度而变化，并且可以从IP报头推断，UDP长度字段值也是如此。
The second pattern corresponds to the case where the coverage is the same from one packet to another within a particular sequence. For this case, the Checksum Coverage field may be a static value defined in the context, and it does not have to be sent in the compressed header. For the third case, no useful change pattern can be identified from packet to packet for the value of the checksum coverage field, and it must be included in the compressed header.
第二模式对应于在特定序列内从一个分组到另一分组的覆盖相同的情况。在这种情况下，校验和覆盖率字段可能是上下文中定义的静态值，不必在压缩头中发送。对于第三种情况，对于校验和覆盖率字段的值，不能从一个数据包到另一个数据包识别出有用的更改模式，必须将其包含在压缩报头中。
It can be expected that any one of the above change patterns for sequences of packets may be predominant at any time during the lifetime of the UDP-Lite flow. A flow that predominantly follows the first two change patterns described above may provide opportunities for compressing the Checksum Coverage field for most of the packets.
可以预期，在UDP-Lite流的生存期内的任何时间，分组序列的上述变化模式中的任何一个都可能占主导地位。主要遵循上述前两个改变模式的流可以提供压缩大多数分组的校验和覆盖字段的机会。
In relation to the header field classification of RFC 3095 [2], the first two patterns represent the case where the value of the Checksum Coverage field behavior is fixed and may be either INFERRED (pattern
关于RFC 3095[2]的标题字段分类，前两种模式表示校验和覆盖率字段行为的值是固定的，可以是推断的（模式
1) or STATIC (pattern 2). Pattern 3 is for the case where the value varies unpredictably, the field is CHANGING, and the value must be sent along with every packet.
1) 或静态（模式2）。模式3适用于值发生不可预测的变化、字段发生变化且值必须随每个数据包一起发送的情况。
Additional information regarding the analysis of the behavior of the UDP-Lite fields may be found in Appendix A.
有关UDP Lite字段行为分析的其他信息，请参见附录A。
Simplicity is a strong motivation for the design of the UDP-Lite header compression profiles. The profiles defined for UDP-Lite should entail only a few simple modifications to the corresponding profiles defined for UDP in RFC 3095 [2]. In addition, it is desirable to include some of the improvements found in the ROHC IP-Only profile [3]. Finally, whenever UDP-Lite is used in a manner that is semantically identical to UDP, the compression efficiency should be similar.
简单性是设计UDP Lite报头压缩配置文件的强大动力。为UDP Lite定义的配置文件应该只需要对RFC 3095[2]中为UDP定义的相应配置文件进行一些简单的修改。此外，希望包括ROHC纯IP配置文件中的一些改进[3]。最后，只要以与UDP语义相同的方式使用UDP Lite，压缩效率应该是相似的。
The simplest approach to the definition of ROHC profiles for UDP-Lite is to treat the Checksum Coverage field as an irregular value, and to send it uncompressed for every packet. This may be achieved simply by adding the field to the definition of the general packet format [2]. However, then the compression efficiency would always be less than for UDP.
为UDP Lite定义ROHC配置文件的最简单方法是将校验和覆盖率字段视为不规则值，并对每个数据包进行未压缩发送。这可以通过简单地将字段添加到通用分组格式的定义中来实现[2]。但是，压缩效率将始终低于UDP。
Some care should be given to achieve compression efficiency for UDP-Lite similar to that for UDP when the Checksum Coverage field behaves like the UDP Length field. This requires the possibility to infer the Checksum Coverage field when it is equal to the length of the packet. Otherwise, this would put the UDP-Lite protocol at a disadvantage over links where header compression is used, when its behavior is made similar to the semantics of UDP.
当校验和覆盖率字段的行为类似于UDP长度字段时，应注意实现与UDP类似的UDP Lite压缩效率。这需要在校验和覆盖范围字段等于数据包长度时推断出它的可能性。否则，当UDP Lite协议的行为与UDP的语义相似时，与使用报头压缩的链接相比，这将使UDP Lite协议处于劣势。
A mechanism to detect the presence of the Checksum Coverage field in compressed headers is thus needed. This is achieved by defining a new packet type with the identifiers left unused in RFC 3095 [2].
因此，需要一种机制来检测压缩头中是否存在校验和覆盖率字段。这是通过在RFC3095[2]中定义一个新的包类型，其中标识符未使用来实现的。
This section defines two ROHC profiles:
本节定义了两个ROHC配置文件：
- RTP/UDP-Lite/IP compression (profile 0x0007) - UDP-Lite/IP compression (profile 0x0008)
- RTP/UDP Lite/IP压缩（配置文件0x0007）-UDP Lite/IP压缩（配置文件0x0008）
These profiles build on the specifications found in RFC 3095 [2], with as little modification as possible. Unless it is explicitly stated otherwise, the profiles defined herein follow the specifications of ROHC UDP and ROHC RTP, respectively.
这些配置文件以RFC 3095[2]中的规范为基础，并尽可能少地进行修改。除非另有明确说明，否则本文定义的配置文件分别遵循ROHC UDP和ROHC RTP规范。
Note also that this document reuses the notation found in [2].
还要注意，本文档重用了[2]中的符号。
As described in [2], information about previous packets is maintained in a context. This includes information describing the packet stream and compression parameters. Although the UDP and UDP-Lite protocols share many commonalities, the differences in semantics as described earlier render the following parameter inapplicable:
如[2]中所述，在上下文中维护关于先前数据包的信息。这包括描述分组流和压缩参数的信息。尽管UDP和UDP Lite协议有许多共同点，但前面描述的语义差异导致以下参数不适用：
The parameter context(UDP Checksum)
参数上下文（UDP校验和）
The UDP-Lite checksum cannot be disabled, as opposed to UDP. The parameter context(UDP Checksum) defined in [2] (section 5.7) is therefore not used for compression of UDP-Lite.
与UDP相反，无法禁用UDP Lite校验和。因此，[2]（第5.7节）中定义的参数上下文（UDP校验和）不用于UDP Lite的压缩。
In addition, the UDP-Lite checksum is always sent as-is in every compressed packet. However, the Checksum Coverage field may not always be sent in each compressed packet, and the following context parameter is used to indicate whether the field is sent:
此外，UDP Lite校验和总是像在每个压缩包中一样发送。但是，校验和覆盖范围字段可能并不总是在每个压缩数据包中发送，以下上下文参数用于指示是否发送该字段：
The parameter context(UDP-Lite Coverage Field Present)
参数上下文（UDP Lite覆盖率字段存在）
Whether the UDP-Lite Checksum Coverage field is present or not in the general packet format (see section 5.3.1) is controlled by the value of the Coverage Field Present (CFP) flag in the context.
UDP Lite校验和覆盖范围字段是否以通用数据包格式存在（见第5.3.1节），由上下文中覆盖范围字段存在（CFP）标志的值控制。
If context(CFP) is nonzero, the Checksum Coverage field is not compressed, and it is present within compressed packets. If context(CFP) is zero, the Checksum Coverage field is compressed, and it is not sent. This is the case when the value of the Checksum Coverage field follows a stable inter-packet change pattern; the field has either a constant value or it has a value equal to the packet length for most packets in a sequence (see section 3.2).
如果上下文（CFP）为非零，则校验和覆盖率字段不会被压缩，并且它存在于压缩的数据包中。如果上下文（CFP）为零，则校验和覆盖率字段将被压缩，并且不会被发送。这是当校验和覆盖字段的值遵循稳定的分组间变化模式时的情况；该字段有一个常量值，或者其值等于序列中大多数数据包的数据包长度（见第3.2节）。
Finally, the following context parameter is needed to indicate whether the field should be inferred or taken from a value previously saved in the context:
最后，需要使用以下上下文参数来指示是否应推断字段或从先前保存在上下文中的值获取字段：
The parameter context(UDP-Lite Coverage Field Inferred)
参数上下文（推断的UDP Lite覆盖率字段）
When the UDP-Lite Checksum Coverage field is not present in the compressed header (CFP=0), whether it is inferred is controlled by the value of the Coverage Field Inferred (CFI) flag in the context.
当压缩头中不存在UDP Lite校验和覆盖范围字段（CFP=0）时，是否推断由上下文中的覆盖范围字段推断（CFI）标志的值控制。
If context(CFI) is nonzero, the Checksum Coverage field is inferred from the packet length, similarly as for the UDP Length field in ROHC RTP. If context(CFI) is zero, the Checksum Coverage field is decompressed by using context(UDP-Lite Checksum Coverage). Therefore, when context(CFI) is updated to a nonzero value, the value of the Checksum Coverage field stored in the context must also be updated.
如果上下文（CFI）为非零，则校验和覆盖范围字段从数据包长度推断，与ROHC RTP中的UDP长度字段类似。如果上下文（CFI）为零，则使用上下文（UDP Lite校验和覆盖率）解压缩校验和覆盖率字段。因此，当上下文（CFI）更新为非零值时，存储在上下文中的校验和覆盖率字段的值也必须更新。
Unless it is stated otherwise, the mechanisms of ROHC RTP and ROHC UDP found in [2] are used also for the ROHC RTP/UDP-Lite and the ROHC UDP-Lite profiles, respectively.
除非另有说明，否则[2]中的ROHC RTP和ROHC UDP机制也分别用于ROHC RTP/UDP Lite和ROHC UDP Lite配置文件。
In particular, the considerations of ROHC UDP regarding the UDP SN taking the role of the RTP Sequence Number apply to ROHC UDP-Lite. Also, the static context for ROHC UDP-Lite may be initialized by reusing an existing context belonging to a stream compressed by using ROHC RTP/UDP-Lite (profile 0x0007), similarly as for ROHC UDP.
特别是，ROHC UDP关于UDP SN扮演RTP序列号角色的注意事项适用于ROHC UDP Lite。此外，ROHC UDP Lite的静态上下文可以通过重用属于使用ROHC RTP/UDP Lite（概要文件0x0007）压缩的流的现有上下文来初始化，类似于ROHC UDP。
The structure of the IR and IR-DYN packets and the initialization procedures are the same as for the ROHC profiles for UDP [2], with the exception of the dynamic part as specified for UDP. A 2-octet field containing the checksum coverage is added before the Checksum field. This affects the format of dynamic chains in both IR and IR-DYN packets.
IR和IR-DYN数据包的结构和初始化过程与UDP的ROHC配置文件相同[2]，但UDP的动态部分除外。在校验和字段之前添加一个包含校验和覆盖率的2-octet字段。这会影响IR和IR-DYN数据包中动态链的格式。
Dynamic part:
动态部分：
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+
/ Checksum Coverage / 2 octets
+---+---+---+---+---+---+---+---+
/ Checksum / 2 octets
+---+---+---+---+---+---+---+---+
CRC-DYNAMIC: Checksum Coverage field, Checksum field (octets 5 - 8).
CRC-DYNAMIC：校验和覆盖域，校验和域（八位字节5-8）。
CRC-STATIC: All other fields (octets 1 - 4).
CRC-STATIC：所有其他字段（八位字节1-4）。
The following logic must be used by both the compressor and the decompressor for assigning values to the parameters context(CFP) and context(CFI) during initialization:
在初始化期间，压缩机和解压缩器必须使用以下逻辑为参数上下文（CFP）和上下文（CFI）赋值：
Context(CFP)
上下文（CFP）
During context initialization, the value of context(CFP) MUST be set to a nonzero value if the Checksum Coverage field differs from the length of the UDP-Lite packet, for any one IR or IR-DYN packet sent (compressor) or received (decompressor); otherwise, the value MUST be set to zero.
在上下文初始化期间，如果校验和覆盖范围字段不同于UDP Lite数据包的长度，则对于发送（压缩器）或接收（解压缩器）的任何一个IR或IR-DYN数据包，必须将上下文（CFP）的值设置为非零值；否则，该值必须设置为零。
Context(CFI)
上下文（CFI）
During context initialization, the value of context(CFI) MUST be set to a nonzero value if the Checksum Coverage field is equal to the length of the UDP-Lite packet within an IR or an IR-DYN packet sent (compressor) or received (decompressor); otherwise, the value MUST be set to zero.
在上下文初始化期间，如果校验和覆盖范围字段等于发送（压缩器）或接收（解压缩器）的IR或IR-DYN数据包中UDP Lite数据包的长度，则必须将上下文（CFI）的值设置为非零值；否则，该值必须设置为零。
The general packet format, as defined in RFC 3095 [2], is modified to include an additional field for the UDP-Lite checksum coverage. A packet type is also defined to handle the specific semantics and characteristics of this field.
修改RFC 3095[2]中定义的通用数据包格式，以包含UDP Lite校验和覆盖范围的附加字段。还定义了数据包类型来处理该字段的特定语义和特征。
The general packet format of a compressed ROHC UDP-Lite header is similar to the compressed ROHC RTP header ([2], section 5.7), with modifications to the Checksum field, as well as additional fields for handling multiple IP headers and for the UDP-Lite checksum coverage:
压缩ROHC UDP Lite报头的一般数据包格式类似于压缩ROHC RTP报头（[2]，第5.7节），修改了校验和字段，以及处理多个IP报头和UDP Lite校验和覆盖范围的附加字段：
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [3], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
--- --- --- --- --- --- --- ---
: List of : variable, given by static chain
/ dynamic chains / (does not include SN)
: for additional IP headers : see also [3], section 3.2.
--- --- --- --- --- --- --- ---
: : 2 octets,
+ UDP-Lite Checksum Coverage + if context(CFP) = 1 or
: : if packet type = CCE (see 5.3.2)
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum + 2 octets
: :
--- --- --- --- --- --- --- ---
The list of dynamic header chains carries the dynamic header part for each IP header in excess of the initial two, if there is any (as indicated by the presence of corresponding header parts in the static chain). Note that there is no sequence number at the end of the chain, as SN is present within compressed base headers.
动态报头链的列表包含每个IP报头的动态报头部分，如果有，则超过最初的两个（如静态链中存在相应的报头部分所示）。请注意，链的末端没有序列号，因为SN存在于压缩的基本标头中。
The order of the fields following the optional extension of the general ROHC packet format is the same as the order between the fields in the uncompressed header.
通用ROHC数据包格式的可选扩展之后的字段顺序与未压缩头中字段之间的顺序相同。
When the CRC is calculated, the Checksum Coverage field is CRC-DYNAMIC.
计算CRC时，校验和覆盖范围字段为CRC-DYNAMIC。
The ROHC profiles for UDP-Lite define a packet type to handle the various possible change patterns of the checksum coverage. This packet type may be used to manipulate the context values that control the presence of the Checksum Coverage field within the general packet format (i.e., context(CFP)) and how the field is decompressed (i.e., context(CFI)). The 2-octet Checksum Coverage field is always present within the format of this packet (see section 5.3.1).
UDP Lite的ROHC配置文件定义了一种数据包类型，以处理校验和覆盖率的各种可能变化模式。该分组类型可用于操纵上下文值，该上下文值控制通用分组格式（即，上下文（CFP））内校验和覆盖字段的存在以及该字段的解压缩方式（即，上下文（CFI））。2-octet校验和覆盖范围字段始终存在于该数据包的格式中（见第5.3.1节）。
This type of packet is named Checksum Coverage Extension, or CCE, and its updating properties depend on the final two bits of the packet type octet (see format below). A naming scheme of the form CCE(<some_property>) is used to uniquely identify the properties of a particular CCE packet.
这种类型的数据包被称为校验和覆盖扩展，或CCE，其更新属性取决于数据包类型八位字节的最后两位（见下面的格式）。形式为CCE（<some_property>）的命名方案用于唯一标识特定CCE数据包的属性。
Although this packet type defines its own format, it may be considered as an extension mechanism for packets of type 2, 1, or 0 [2]. This is achieved by substitution of the packet type identifier of the first octet of the base header (the "outer" identifier) with
尽管此数据包类型定义了自己的格式，但它可以被视为类型2、1或0[2]数据包的扩展机制。这是通过将基本报头的第一个八位组的分组类型标识符（“外部”标识符）替换为
one of the unused packet types from RFC 3095 [2]. The substituted identifier is then moved to the first octet of the remainder of the base header (the "inner" identifier).
RFC 3095[2]中未使用的数据包类型之一。然后将被替换的标识符移动到基本报头剩余部分的第一个八位字节（“内部”标识符）。
The format of the ROHC UDP-Lite CCE packet type is as follows:
ROHC UDP Lite CCE数据包类型的格式如下：
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+===+===+===+===+===+===+===+===+
: : (with inner type identifier)
/ Inner Base header / variable number of bits, given by
: : the inner packet type identifier
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Updating properties: The updating properties of the inner packet type carried within any of the CCE packets are always maintained. CCE(ON) and CCE(OFF) MUST NOT be used to extend R-0 and R-1* headers. In addition, CCE(ON) always updates context(CFP); CCE(OFF) always updates context(CFP), context(CFI), and context(UDP-Lite Checksum Coverage).
更新属性：始终保持任何CCE数据包内携带的内部数据包类型的更新属性。CCE（开）和CCE（关）不得用于扩展R-0和R-1*报头。此外，CCE（ON）总是更新上下文（CFP）；CCE（关闭）始终更新上下文（CFP）、上下文（CFI）和上下文（UDP Lite校验和覆盖率）。
Appendix B provides an expanded view of the resulting format of the CCE packet type.
附录B提供了CCE数据包类型的结果格式的扩展视图。
Aside from the updating properties of the inner packet type carried within CCE(), this packet does not update any other context values. CCE() thus is mode-agnostic; e.g., it can extend any of packet types 2, 1, and 0, regardless of the current mode of operation [2].
除了更新CCE（）中携带的内部数据包类型的属性外，此数据包不会更新任何其他上下文值。因此，CCE（）是模式不可知的；e、 例如，它可以扩展包类型2、1和0中的任何一种，而不考虑当前的操作模式[2]。
CCE() may be used when the checksum coverage deviates from the change pattern assumed by the compressor, where the field could previously be compressed. This packet is useful if the occurrence of such deviations is rare.
当校验和覆盖范围偏离压缩器假设的更改模式时，可以使用CCE（），在此之前可以压缩字段。如果此类偏差很少发生，则此数据包非常有用。
In addition to the updating properties of the inner packet type, CCE(ON) updates context(CFP) to a nonzero value; i.e., it effectively turns on the presence of the Checksum Coverage field within the
除了内部分组类型的更新属性外，CCE（ON）还将上下文（CFP）更新为非零值；i、 例如，它可以有效地打开
general packet format. This is useful when the predominant change pattern of the checksum coverage precludes its compression.
通用数据包格式。当校验和覆盖率的主要变化模式阻止其压缩时，这是有用的。
CCE(ON) can extend any of the context-updating packets of type 2, 1, and 0; that is, packets with a compressed header containing a CRC [2]. Specifically, R-0 and R-1* headers MUST NOT be extended by using CCE(ON).
CCE（ON）可以扩展类型2、1和0的任何上下文更新分组；也就是说，具有包含CRC[2]的压缩报头的数据包。具体来说，R-0和R-1*头不能通过使用CCE（ON）进行扩展。
In addition to the updating properties of the inner packet type, CCE(OFF) updates context(CFP) to a value of zero; i.e., it effectively turns off the presence of the Checksum Coverage field within the general packet format. This is useful when the change pattern of the checksum coverage seldom deviates from the pattern assumed by the compressor.
除了内部分组类型的更新属性之外，CCE（OFF）将上下文（CFP）更新为零值；i、 例如，它有效地关闭了通用数据包格式中校验和覆盖范围字段的存在。当校验和覆盖范围的变化模式很少偏离压缩器假设的模式时，这非常有用。
CCE(OFF) also updates context(CFI) to a nonzero value, if field(UDP-Lite Checksum Coverage) is equal to the packet length; otherwise, it must be set to zero. Note that when context(CFI) is updated by using packet type CCE(OFF), a match of field(Checksum Coverage) with the packet length always has precedence over a match with context(Checksum Coverage). Finally, context(UDP-Lite Checksum Coverage) is also updated by CCE(OFF).
如果字段（UDP Lite校验和覆盖率）等于数据包长度，则CCE（OFF）还将上下文（CFI）更新为非零值；否则，它必须设置为零。请注意，当使用数据包类型CCE（OFF）更新上下文（CFI）时，字段（校验和覆盖率）与数据包长度的匹配始终优先于与上下文（校验和覆盖率）的匹配。最后，上下文（UDP Lite校验和覆盖率）也由CCE更新（关闭）。
Similarly to CCE(ON), CCE(OFF) can extend any of the context updating packets of type 2, 1, and 0 [2].
与CCE（ON）类似，CCE（OFF）可以扩展类型2、1和0[2]的任何上下文更新包。
If hdr(UDP-Lite Checksum Coverage) is different from context(UDP-Lite Checksum Coverage) and different from the packet length when context(CFP) is zero, the Checksum Coverage field cannot be compressed. In addition, if hdr(UDP-Lite Checksum Coverage) is different from the packet length when context(CFP) is zero and context(CFI) is nonzero, the Checksum Coverage field cannot be compressed by either. For both cases, the field must be sent uncompressed using a CCE packet, or the context must be reinitialized by using an IR packet.
如果hdr（UDP Lite校验和覆盖率）与上下文（UDP Lite校验和覆盖率）不同，并且与上下文（CFP）为零时的数据包长度不同，则无法压缩校验和覆盖率字段。此外，当上下文（CFP）为零且上下文（CFI）为非零时，如果hdr（UDP Lite校验和覆盖率）与数据包长度不同，则校验和覆盖率字段不能由这两种方式压缩。对于这两种情况，必须使用CCE数据包以未压缩的方式发送字段，或者必须使用IR数据包重新初始化上下文。
For packet types other than IR, IR-DYN, and CCE that are received when the value of context(CFP) is zero, the Checksum Coverage field must be decompressed by using the value stored in the context if the value of context(CFI) is zero; otherwise, the field is inferred from the length of the UDP-Lite packet derived from the IP module.
对于在上下文（CFP）值为零时接收的除IR、IR-DYN和CCE以外的数据包类型，如果上下文（CFI）值为零，则必须使用存储在上下文中的值对校验和覆盖范围字段进行解压缩；否则，将根据从IP模块派生的UDP Lite数据包的长度推断该字段。
The profiles defined in this document allow the compressor to decline a mode transition requested by the decompressor. This is achieved by redefining the Mode parameter for the value mode = 0 (in packet types UOR-2, IR, and IR-DYN) as follows (see also [3], section 3.4):
本文档中定义的配置文件允许压缩机拒绝减压器请求的模式转换。这是通过如下重新定义值Mode=0（在数据包类型UOR-2、IR和IR-DYN中）的Mode参数实现的（另请参见[3]，第3.4节）：
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.
收到设置为0的模式参数后，解压器必须保持其当前操作模式，并且应避免发送拒绝模式的进一步模式转换请求。
This feedback option informs the compressor that the decompressor does not have sufficient memory resources to handle the context of the packet stream required by the current compressed structure.
此反馈选项通知压缩器，解压缩器没有足够的内存资源来处理当前压缩结构所需的数据包流上下文。
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 requiring less decompressor memory resources or stop compressing the packet stream.
当接收到CONTEXT_MEMORY选项时，压缩器应采取措施以减少解压缩器内存资源的方式压缩数据包流，或停止压缩数据包流。
The profiles for UDP-Lite support compression of the IP-ID field with constant behavior, with the addition of the Static IP Identifier (SID) flag within the dynamic part of the chain used to initialize the IPv4 header, as follows (see also [3], section 3.3):
UDP Lite的配置文件支持以恒定行为压缩IP-ID字段，并在用于初始化IPv4报头的链的动态部分中添加静态IP标识符（SID）标志，如下所示（另请参见[3]，第3.3节）：
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:
对于IR和IR-DYN数据包：
The logic is the same as that for the respective ROHC profiles for UDP, with the addition that field (SID) must be kept in the context.
逻辑与UDP的相应ROHC配置文件的逻辑相同，只是必须在上下文中保留字段（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 by using Offset IP-ID encoding (see [2], section 4.5.5) using p = 0 and default-slope(IP-ID offset) = 0.
如果值（RND）=0且上下文（SID）=0，则使用p=0和默认斜率（IP-ID偏移）=0，使用偏移IP-ID编码（见[2]，第4.5.5节）压缩hdr（IP-ID）。
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 the respective ROHC profiles for UDP [2].
注：所有其他字段与UDP的相应ROHC配置文件相同[2]。
The security considerations of RFC 3095 [2] apply integrally to this document, without modification.
RFC 3095[2]的安全注意事项完整适用于本文件，无需修改。
ROHC profile identifiers 0x0007 (ROHC RTP/UDP-Lite) and 0x0008 (ROHC UDP-Lite) have been reserved by the IANA for the profiles defined in this document (RFC 4019).
IANA已为本文件（RFC 4019）中定义的配置文件保留了ROHC配置文件标识符0x0007（ROHC RTP/UDP Lite）和0x0008（ROHC UDP Lite）。
Two ROHC profile identifiers must be reserved by the IANA for the profiles defined in this document. Since profile number 0x0006 is being saved for the TCP/IP (ROHC-TCP) profile, profile numbers 0x0007 and 0x0008 are the most suitable unused identifiers available, and should thus be used. As for previous ROHC profiles, profile numbers 0xnn07 and 0xnn08 must also be reserved for future variants of these profiles. The registration suggested for the "RObust Header Compression (ROHC) Profile Identifiers" name space:
IANA必须为本文件中定义的配置文件保留两个ROHC配置文件标识符。由于为TCP/IP（ROHC-TCP）配置文件保存了配置文件编号0x0006，因此配置文件编号0x0007和0x0008是最合适的未使用标识符，因此应使用。对于以前的ROHC配置文件，配置文件编号0xnn07和0xnn08也必须为这些配置文件的未来变体保留。建议注册“鲁棒头压缩（ROHC）配置文件标识符”名称空间：
OLD: 0x0006-0xnn7F To be Assigned by IANA
旧：0x0006-0xnn7F由IANA分配
NEW: 0xnn06 To be Assigned by IANA 0x0007 ROHC RTP/UDP-Lite [RFC4019] 0xnn07 Reserved 0x0008 ROHC UDP-Lite [RFC4019] 0xnn08 Reserved 0x0009-0xnn7F To be Assigned by IANA
新：0xnn06由IANA分配0x0007 ROHC RTP/UDP Lite[RFC4019]0xnn07保留0x0008 ROHC UDP Lite[RFC4019]0xnn08保留0x0009-0xnn7F由IANA分配
The author would like to thank Lars-Erik Jonsson, Kristofer Sandlund, Mark West, Richard Price, Gorry Fairhurst, Fredrik Linstroem and Mats Nordberg for useful reviews and discussions around this document.
作者感谢Lars Erik Jonsson、Kristofer Sandlund、Mark West、Richard Price、Gorry Fairhurst、Fredrik Linstroem和Mats Nordberg对本文件进行了有益的评论和讨论。
[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] 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.
[2] 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月。
[3] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[3] Jonsson，L-E.和G.Pelletier，“鲁棒头压缩（ROHC）：IP的压缩配置文件”，RFC 3843，2004年6月。
[4] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
[4] Larzon，L-A.，Degermark，M.，Pink，S.，Jonsson，L-E.，和G.Fairhurst，“轻量级用户数据报协议（UDP-Lite）”，RFC 38282004年7月。
[5] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[5] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[6] Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[7] Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[8] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
This section summarizes the difference from the classification found in the corresponding appendix in RFC 3095 [2] and similarly provides conclusions about how the various header fields should be handled by the header compression scheme to optimize compression and functionality. These conclusions are separated based on the behavior of the UDP-Lite Checksum Coverage field and use the expected change patterns described in section 3.2 of this document.
本节总结了与RFC 3095[2]中相应附录中的分类的差异，并类似地提供了关于报头压缩方案应如何处理各种报头字段以优化压缩和功能的结论。这些结论根据UDP Lite校验和覆盖率字段的行为分开，并使用本文档第3.2节中描述的预期更改模式。
The following table summarizes a possible classification for the UDP-Lite header fields in comparison with the classification for UDP, using the same classes as in RFC 3095 [2].
下表总结了UDP Lite头字段的可能分类，并与UDP的分类进行了比较，使用了与RFC 3095[2]中相同的类。
Header fields of UDP-Lite and UDP:
UDP Lite和UDP的头字段：
+-------------------+-------------+
| UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+
+-------------------+-------------+
| UDP-Lite | UDP |
+-------------------+--------+-------------------+-------------+
| Header | Size | Class | Class |
| Field | (bits) | | |
+-------------------+--------+-------------------+-------------+
| Source Port | 16 | STATIC-DEF | STATIC-DEF |
| Destination Port | 16 | STATIC-DEF | STATIC-DEF |
| Checksum Coverage | 16 | INFERRED | |
| | | STATIC | |
| | | CHANGING | |
| Length | 16 | | INFERRED |
| Checksum | 16 | CHANGING | CHANGING |
+-------------------+--------+-------------------+-------------+
Source and Destination Port
源和目标端口
Same as for UDP. Specifically, these fields are part of the definition of a stream and must thus be constant for all packets in the stream. The fields are therefore classified as STATIC-DEF.
与UDP相同。具体地说，这些字段是流定义的一部分，因此对于流中的所有数据包都必须是常量。因此，这些字段被分类为STATIC-DEF。
Checksum Coverage
校验和覆盖率
This field specifies which part of the UDP-Lite datagram is covered by the checksum. It may have a value of zero or be equal to the datagram length if the checksum covers the entire datagram, or it may have any value between eight octets and the length of the datagram to specify the number of octets protected by the checksum,
此字段指定校验和覆盖UDP Lite数据报的哪一部分。如果校验和覆盖整个数据报，则其值可能为零或等于数据报长度，或者其值可能在八个八位字节和数据报长度之间，以指定受校验和保护的八位字节数，
calculated from the first octet of the UDP-Lite header. The value of this field may vary for each packet, and this makes the value unpredictable from a header-compression perspective.
从UDP Lite头的第一个八位字节计算。对于每个数据包，该字段的值可能不同，这使得该值从报头压缩的角度来看是不可预测的。
Checksum
校验和
The information used for the calculation of the UDP-Lite checksum is governed by the value of the checksum coverage and minimally includes the UDP-Lite header. The checksum is a changing field that must always be sent as-is.
用于计算UDP Lite校验和的信息由校验和覆盖率的值控制，并且至少包括UDP Lite头。校验和是一个不断变化的字段，必须始终按原样发送。
The total size of the fields in each class, for each expected change pattern (see section 3.2), is summarized in the tables below:
对于每个预期的更改模式（见第3.2节），每个类中字段的总大小总结如下表所示：
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 1:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| INFERRED | 2 | Checksum Coverage
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 2:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| STATIC | 2 | Checksum Coverage
| CHANGING | 2 | Checksum
+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
Pattern 3:
+------------+---------------+
| Class | Size (octets) |
+------------+---------------+
| STATIC-DEF | 4 | Source Port / Destination Port
| CHANGING | 4 | Checksum Coverage / Checksum
+------------+---------------+
The following table revisits the corresponding table (table A.1) for UDP from [2] (section A.2) and classifies the changing fields based on the change patterns previously identified in section 3.2.
下表重新访问了[2]（第A.2节）中UDP的对应表（表A.1），并根据先前在第3.2节中确定的更改模式对更改字段进行分类。
Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
Header compression strategies for UDP-Lite:
+----------+---------+-------------+-----------+-----------+
| Field | Pattern | Value/Delta | Class | Knowledge |
+==========+=========+=============+===========+===========+
| | #1 | Value | CHANGING | INFERRED |
| Checksum |---------+-------------+-----------+-----------+
| Coverage | #2 | Value | RC | UNKNOWN |
| |---------+-------------+-----------+-----------+
| | #3 | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
| Checksum | All | Value | IRREGULAR | UNKNOWN |
+----------+---------+-------------+-----------+-----------+
UDP-Lite Checksum Coverage (Patterns #1 and #2)
UDP Lite校验和覆盖率（模式1和模式2）
UDP-Lite Checksum UDP-Lite Checksum Coverage (Pattern #3)
UDP Lite校验和UDP Lite校验和覆盖率（模式#3）
This section provides an expanded view of the format of the CCE packet, based on the general ROHC RTP compressed header [2] and the general format of a compressed header of the ROHC IP-Only profile [3]. The modifications necessary to carry the base header of a packet of type 2, 1 or 0 [2] within the CCE packet format, along with the additional fields to properly handle compression of multiple IP headers, result in the following structure for the CCE packet type:
本节根据通用ROHC RTP压缩头[2]和ROHC IP纯配置文件压缩头的通用格式[3]，提供了CCE数据包格式的扩展视图。在CCE数据包格式内携带类型2、1或0[2]的数据包的基本报头所需的修改，以及正确处理多个IP报头压缩的附加字段，导致CCE数据包类型的以下结构：
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1 - 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: Add-CID octet : If for small CIDs and CID 1 - 15
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 0 F | K | Outer packet type identifier
+---+---+---+---+---+---+---+---+
: :
/ 0, 1, or 2 octets of CID / 1 - 2 octets if large CIDs
: :
+---+---+---+---+---+---+---+---+
| First octet of base header | (with "inner" type indication)
+---+---+---+---+---+---+---+---+
/ Remainder of base header / Variable number of bits
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
--- --- --- --- --- --- --- ---
: :
/ Extension / See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of outer IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for outer list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: :
+ IP-ID of inner IPv4 header + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
/ AH data for inner list / See RFC 3095 [2], section 5.7.
--- --- --- --- --- --- --- ---
: :
+ GRE checksum + See RFC 3095 [2], section 5.7.
: :
--- --- --- --- --- --- --- ---
: List of : Variable, given by static chain
/ dynamic chains / (includes no SN).
: for additional IP headers : See [3], section 3.2.
--- --- --- --- --- --- --- ---
: :
+ UDP-Lite Checksum Coverage + 2 octets
: :
+---+---+---+---+---+---+---+---+
: :
+ UDP-Lite Checksum + 2 octets
: :
+---+---+---+---+---+---+---+---+
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
F,K: F,K = 00 is reserved at framework level (IR-DYN);
F,K = 01 indicates CCE();
F,K = 10 indicates CCE(ON);
F,K = 11 indicates CCE(OFF).
Note that this document does not define (F,K) = 00, as this would collide with the IR-DYN packet type already reserved at the ROHC framework level.
请注意，本文档未定义（F，K）=00，因为这将与ROHC框架级别上已保留的IR-DYN数据包类型相冲突。
Author's Address
作者地址
Ghyslain Pelletier Ericsson AB Box 920 SE-971 28 Lulea, Sweden
Ghyslain Pelletier Ericsson AB信箱920 SE-971 28 Lulea，瑞典
Phone: +46 840 429 43
Fax : +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Phone: +46 840 429 43
Fax : +46 920 996 21
EMail: ghyslain.pelletier@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。