Network Working Group C. Bormann
Request for Comments: 3241 TZI/Uni Bremen
Updates: 1332 April 2002
Category: Standards Track
Network Working Group C. Bormann
Request for Comments: 3241 TZI/Uni Bremen
Updates: 1332 April 2002
Category: Standards Track
Robust Header Compression (ROHC) over PPP
PPP上的鲁棒头压缩（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 Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over the Point-to-Point Protocol (PPP). It defines extensions to the PPP Control Protocols for IPv4 and IPv6.
本文档描述了一种在点到点协议（PPP）上传输的IP数据报上协商使用鲁棒报头压缩（ROHC）的选项。它定义了IPv4和IPv6 PPP控制协议的扩展。
Robust Header Compression (ROHC) as defined in [RFC3095] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. The initial version of ROHC focuses on compression of the packet headers in RTP streams, while supporting compression of other UDP flows; however, it also defines a framework into which further header compression mechanisms can be plugged as new profiles. Planned additions to the set of profiles supported by ROHC will be capable of compressing TCP transport protocol headers as well.
[RFC3095]中定义的健壮报头压缩（ROHC）可用于压缩IPv4和IPv6数据报或用多个IP报头封装的数据包。ROHC的初始版本侧重于RTP流中数据包头的压缩，同时支持其他UDP流的压缩；然而，它还定义了一个框架，进一步的头压缩机制可以作为新的概要文件插入其中。ROHC支持的配置文件集的计划新增内容也将能够压缩TCP传输协议头。
In order to establish compression of IP datagrams sent over a PPP link each end of the link must agree on a set of configuration parameters for the compression. The process of negotiating link parameters for network layer protocols is handled in PPP by a family of network control protocols (NCPs). Since there are separate NCPs for IPv4 and IPv6, this document defines configuration options to be used in both NCPs to negotiate parameters for the compression scheme.
为了对通过PPP链路发送的IP数据报进行压缩，链路的每一端必须就压缩的一组配置参数达成一致。网络层协议的链路参数协商过程由一系列网络控制协议（NCP）在PPP中处理。由于IPv4和IPv6有单独的NCP，因此本文档定义了两个NCP中用于协商压缩方案参数的配置选项。
ROHC does not require that the link layer be able to indicate the types of datagrams carried in the link layer frames. However, there are two basic types of ROHC headers defined in the ROHC framework: small-CID headers (zero or one bytes are used to identify the compression context) and large-CID headers (one or two bytes are used for this purpose). To keep the PPP packets self-describing, in this document two new types for the PPP Data Link Layer Protocol Field are defined, one for small-CID ROHC packets and one for large-CID ROHC packets. (This also avoids a problem that would occur if PPP were to negotiate which of the formats to use in each of IPCP and IPV6CP and the two negotiation processes were to arrive at different results.) A PPP ROHC sender may send packets in either small-CID or large-CID format at any time, i.e., the LARGE_CIDS parameter from [RFC3095] is not used. Any PPP ROHC receiver MUST be able to process both small-CID and large-CID ROHC packets, therefore no negotiation of this function is required.
ROHC不要求链路层能够指示链路层帧中承载的数据报类型。然而，ROHC框架中定义了两种基本类型的ROHC头：小CID头（零或一个字节用于标识压缩上下文）和大CID头（一个或两个字节用于此目的）。为了保持PPP数据包的自描述性，本文定义了PPP数据链路层协议字段的两种新类型，一种用于小CID ROHC数据包，另一种用于大CID ROHC数据包。（这也避免了PPP协商在IPCP和IPV6CP中使用哪种格式以及两个协商过程得到不同结果时可能出现的问题。）PPP ROHC发送方可随时发送小CID或大CID格式的数据包，即不使用[RFC3095]中的大_CIDS参数。任何PPP ROHC接收器必须能够处理小CID和大CID ROHC数据包，因此不需要协商此功能。
ROHC assumes that the link layer delivers packets in sequence. PPP normally does not reorder packets. When using reordering mechanisms such as multiclass multilink PPP [RFC2686], care must be taken so that packets that share the same compression context are not reordered. (Note that in certain cases, reordering may be acceptable to ROHC, such as within a sequence of packets that all do not change the decompression context.)
ROHC假设链路层按顺序传递数据包。PPP通常不会对数据包重新排序。当使用诸如多类多链路PPP[RFC2686]之类的重新排序机制时，必须注意不要对共享相同压缩上下文的数据包进行重新排序。（请注意，在某些情况下，ROHC可以接受重新排序，例如在一系列数据包中，所有这些数据包都不会改变解压缩上下文。）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
This document specifies a new compression protocol value for the IPCP IP-Compression-Protocol option as specified in [RFC1332]. The new value and the associated option format are described in section 2.1.
本文档为[RFC1332]中指定的IPCP IP压缩协议选项指定了一个新的压缩协议值。第2.1节描述了新值和相关选项格式。
The option format is structured to allow future extensions to the ROHC scheme.
选项格式的结构允许将来扩展ROHC方案。
It may be worth repeating [RFC1332], section 4: "The IP-Compression-Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired." I.e., the option describes the capabilities of the decompressor (receiving side) of the peer that sends the Configure-Request.
可能值得重复[RFC1332]，第4节：“IP压缩协议配置选项用于指示接收压缩数据包的能力。如果需要双向压缩，链路的每一端必须单独请求此选项。”即，该选项描述了解压缩器（接收端）的能力发送配置请求的对等方的。
NOTE: The specification of link and network layer parameter negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not prohibit multiple instances of one configuration option but states that the specification of a configuration option must explicitly allow multiple instances. From the current specification of the IPCP IP-Compression-Protocol configuration option [RFC1332] one can infer that it can only be used to select a single compression protocol at any time.
注：PPP[RFC1661]、[RFC1331]、[RFC1332]的链路和网络层参数协商规范不禁止一个配置选项的多个实例，但规定一个配置选项的规范必须明确允许多个实例。从IPCP IP压缩协议配置选项[RFC1332]的当前规范可以推断，它在任何时候都只能用于选择单个压缩协议。
This was appropriate at a time when only one header compression scheme existed. With the advent of IP header compression [RFC2507, RFC2509], this did not really change, as RFC 2507 essentially superseded RFC 1144. However, with ROHC, it may now very well be desirable to use RFC 2507 TCP compression in conjunction with RFC 3095 RTP/UDP compression.
当只有一个报头压缩方案存在时，这是合适的。随着IP报头压缩[RFC2507，RFC2509]的出现，这并没有真正改变，因为RFC2507基本上取代了RFC1144。然而，对于ROHC，现在可能非常希望将RFC2507TCP压缩与RFC3095RTP/UDP压缩结合使用。
The present document now updates RFC 1332 by explicitly allowing the sending of multiple instances of the IP-Compression-Protocol configuration option, each with a different value for IP-Compression-Protocol. Each type of compression protocol may independently establish its own parameters.
本文档现在通过明确允许发送IP压缩协议配置选项的多个实例来更新RFC 1332，每个实例都具有不同的IP压缩协议值。每种类型的压缩协议都可以独立地建立自己的参数。
This change is believed to not cause significant harm in existing PPP implementations, as they would most likely Configure-Nak or Configure-Reject the duplicate option, or simply happen to accept the one option they understand. To aid interoperability, the peer implementing the present specification SHOULD react to a Configure-Nak or Configure-Reject by reducing the number of options offered to one.
这种变化被认为不会对现有PPP实施造成重大损害，因为他们很可能会配置Nak或配置拒绝重复选项，或者只是碰巧接受他们理解的一个选项。为了帮助互操作性，实现本规范的对等方应通过减少提供给一个的选项数量来对配置Nak或配置拒绝做出反应。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header Compression parameters for their respective protocols. The format of the configuration option is the same for both IPCP and IPV6CP.
IPv4、IPCP[RFC1332]和IPv6 NCP、IPV6CP[RFC2472]的网络控制协议均可用于协商各自协议的IP报头压缩参数。IPCP和IPV6CP的配置选项格式相同。
Description
描述
This NCP configuration option is used to negotiate parameters for Robust Header Compression. The option format is summarized below. The fields are transmitted from left to right.
此NCP配置选项用于协商用于健壮报头压缩的参数。选项格式概述如下。字段从左向右传输。
Figure 1: Robust Header Compression (ROHC) Option
图1：健壮的报头压缩（ROHC）选项
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_CID | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IP-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_CID | MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
类型2
Length >= 10
长度>=10
The length may be increased if the presence of additional parameters is indicated by additional suboptions.
如果附加子选项指示存在附加参数，则长度可能会增加。
IP-Compression-Protocol 0003 (hex)
IP压缩协议0003（十六进制）
MAX_CID The MAX_CID field is two octets and indicates the maximum value of a context identifier.
MAX_CID MAX_CID字段是两个八位字节，表示上下文标识符的最大值。
Suggested value: 15
建议值：15
MAX_CID must be at least 0 and at most 16383 (The value 0 implies having one context).
MAX_CID必须至少为0，最多为16383（值0表示有一个上下文）。
MRRU The MRRU field is two octets and indicates the maximum reconstructed reception unit (see [RFC3095], section 5.1.1).
MRRU MRRU字段为两个八位字节，表示最大重构接收单元（见[RFC3095]，第5.1.1节）。
Suggested value: 0
建议值：0
MAX_HEADER The largest header size in octets that may be compressed.
MAX_HEADER可压缩的最大头大小（以八位字节为单位）。
Suggested value: 168 octets
建议值：168个八位字节
The value of MAX_HEADER should be large enough so that at least the outer network layer header can be compressed. To increase compression efficiency MAX_HEADER should be set to a value large enough to cover common combinations of network and transport layer headers.
MAX_头的值应该足够大，以便至少可以压缩外部网络层头。为了提高压缩效率，应将MAX_头设置为足够大的值，以覆盖网络和传输层头的常见组合。
NOTE: The four ROHC profiles defined in RFC 3095 do not provide for a MAX_HEADER parameter. The parameter MAX_HEADER defined by this document is therefore without consequence in these profiles. Other profiles (e.g., ones based on RFC 2507) can make use of the parameter by explicitly referencing it.
注：RFC 3095中定义的四个ROHC配置文件不提供MAX_头参数。因此，本文档定义的参数MAX_HEADER在这些配置文件中不起作用。其他配置文件（例如，基于RFC 2507的配置文件）可以通过显式引用该参数来使用该参数。
suboptions The suboptions field consists of zero or more suboptions. Each suboption consists of a type field, a length field and zero or more parameter octets, as defined by the suboption type. The value of the length field indicates the length of the suboption in its entirety, including the lengths of the type and length fields.
子选项“子选项”字段由零个或多个子选项组成。每个子选项由一个类型字段、一个长度字段和零个或多个由子选项类型定义的参数八位字节组成。长度字段的值指示子选项的整个长度，包括类型字段和长度字段的长度。
Figure 2: Suboption
图2：子选项
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Parameters...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The set of profiles to be enabled is subject to negotiation. Most initial implementations of ROHC implement profiles 0x0000 to 0x0003. This option MUST be supplied.
要启用的配置文件集有待协商。ROHC的大多数初始实现实现了配置文件0x0000到0x0003。必须提供此选项。
Description
描述
Define the set of profiles supported by the decompressor.
定义解压缩程序支持的配置文件集。
Figure 3: PROFILES suboption
图3:PROFILES子选项
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Profiles...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Profiles...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
类型1
Length 2n+2
长度2n+2
Value n octet-pairs in ascending order, each octet-pair specifying a ROHC profile supported.
按升序计算n个八位字节对，每个八位字节对指定支持的ROHC配置文件。
The ROHC protocol is able to compress both IPv6 and IPv4 datagrams. Both IPCP and IPV6CP are able to negotiate option parameter values for ROHC. The ROHC capability negotiated as a whole applies to the compression of packets where the outer header is an IPv4 header and an IPv6 header, respectively; e.g., an outer IPv6 header MUST NOT be sent if the ROHC IP-Compression-Protocol option was not negotiated for IPV6CP.
ROHC协议能够压缩IPv6和IPv4数据报。IPCP和IPV6CP都能够协商ROHC的选项参数值。整体协商的ROHC能力适用于数据包压缩，其中外部报头分别为IPv4报头和IPv6报头；e、 例如，如果未为IPV6CP协商ROHC IP压缩协议选项，则不得发送外部IPv6报头。
Offering a specific ROHC capability in a Configure-Request in either IPCP or IPV6CP indicates that the capability is provided for the entire ROHC channel formed by the PPP link. When the option has been negotiated with different values in IPCP and IPV6CP, the result is that the set of parameter values for the entire ROHC channel is the logical union of the two values, i.e., the maximum for MAX_CID, MRRU or MAX_HEADER, and the logical union of the suboptions. For the PROFILES suboption, the logical union is the union of the two sets of profiles. The unified values are kept as valid parameter values for the ROHC channel even when either of the NCPs is taken down.
在IPCP或IPV6CP中的配置请求中提供特定的ROHC功能表示该功能是为PPP链路形成的整个ROHC通道提供的。当已使用IPCP和IPV6CP中的不同值协商该选项时，结果是整个ROHC通道的参数值集是两个值的逻辑并集，即MAX_CID、MRRU或MAX_标头的最大值，以及子选项的逻辑并集。对于“配置文件”子选项，逻辑并集是两组配置文件的并集。统一值作为ROHC通道的有效参数值保留，即使其中一个NCP被取下。
Note that each new suboption for this option must define the meaning of "logical union", if the concept applies.
请注意，如果概念适用，此选项的每个新子选项必须定义“逻辑联合”的含义。
For the compression and decompression of IPv4 and IPv6 datagram headers, the context identifier space is shared. While the parameter values are independently negotiated, sharing the context identifier spaces becomes more complex when the parameter values differ. Since the compressed packets share context identifier space, the compression engine must allocate context identifiers out of a common pool; for compressed packets, the decompressor has to examine the context state to determine what parameters to use for decompression.
对于IPv4和IPv6数据报报头的压缩和解压缩，上下文标识符空间是共享的。虽然参数值是独立协商的，但当参数值不同时，共享上下文标识符空间变得更加复杂。由于压缩包共享上下文标识符空间，压缩引擎必须从公共池中分配上下文标识符；对于压缩数据包，解压缩程序必须检查上下文状态，以确定用于解压缩的参数。
In particular, the context identifier space is shared between ROHC small-CID packets and ROHC large-CID packets. From the point of view of the ROHC framework, the PPP NCP instances for IPCP and IPV6CP together constitute exactly one ROHC channel; its feedback is destined for the ROHC channel defined by the NCP instances for IPCP and IPV6CP in the reverse direction on the same PPP link.
具体而言，在ROHC小CID分组和ROHC大CID分组之间共享上下文标识符空间。从ROHC框架的角度来看，IPCP和IPV6CP的PPP NCP实例共同构成一个ROHC通道；其反馈目的地为同一PPP链路上反向的IPCP和IPV6CP的NCP实例定义的ROHC通道。
In particular, this means that taking down either of the NCPs while the other is still open means that the contexts of the channel stay active. To avoid race conditions, the same is true if both NCPs are taken down and then one or more is reopened. Taking down LCP destroys the channel, however; reopening LCP and then one or more of IPCP and IPV6CP restarts ROHC with all contexts in no-context state.
特别是，这意味着在另一个NCP仍然打开时关闭其中一个NCP意味着通道的上下文保持活动状态。为了避免竞争条件，如果两个NCP都被关闭，然后一个或多个NCP被重新打开，情况也是如此。然而，拆除LCP会破坏通道；重新打开LCP，然后一个或多个IPCP和IPV6CP在所有上下文都处于无上下文状态的情况下重新启动ROHC。
The ROHC specification [RFC3095] defines a single header format for all different types of compressed headers, with a variant for small CIDs and a variant for large CIDs. Two PPP Data Link Layer Protocol Field values are specified below.
ROHC规范[RFC3095]为所有不同类型的压缩报头定义了一种报头格式，其中一种用于小型CID，另一种用于大型CID。下面指定了两个PPP数据链路层协议字段值。
ROHC small-CIDs
ROHC小型CIDs
The frame contains a ROHC packet with small CIDs as defined in [RFC3095].
该帧包含一个ROHC数据包，其中包含[RFC3095]中定义的小CID。
Value: 0003 (hex)
值：0003（十六进制）
ROHC large-CIDs
ROHC大型CIDs
The frame contains a ROHC packet with large CIDs as defined in [RFC3095].
该帧包含具有[RFC3095]中定义的大CID的ROHC数据包。
Value: 0005 (hex)
值：0005（十六进制）
Note that this implies that all CIDs within one ROHC packet MUST be of the same size as indicated by the Data Link Layer Protocol field, either small or large. In particular, embedded feedback MUST have a CID of the same size as indicated by the Protocol field value. For piggybacking feedback, a compressor must be able to control the feedback CID size used by the associated decompressor, ensure that all CIDs are of the same size, and indicate this size with the appropriate Protocol Field value.
请注意，这意味着一个ROHC数据包中的所有CID必须与数据链路层协议字段指示的大小相同，无论大小。特别是，嵌入式反馈必须具有与协议字段值指示的相同大小的CID。对于搭载反馈，压缩机必须能够控制相关减压器使用的反馈CID大小，确保所有CID大小相同，并用适当的协议字段值指示此大小。
To make CID interpretation unambiguous when ROHC segmentation is used, all packets that contribute to a segment MUST be sent with the same Data Link Layer Protocol Field value, either 0003 or 0005, which then also applies to the CID size in the reconstructed unit. A unit reconstructed out of packets with Protocol field values that differ MUST be discarded.
当使用ROHC分段时，为了使CID解释明确，必须使用相同的数据链路层协议字段值（0003或0005）发送有助于分段的所有数据包，然后该值也适用于重构单元中的CID大小。必须丢弃由协议字段值不同的数据包重构而成的单元。
Certain considerations are required for any ROHC-over-X protocol. This section describes how some of these are handled for ROHC over PPP.
任何ROHC-over-X协议都需要考虑某些因素。本节描述了ROHC如何通过PPP处理其中一些问题。
There is no need for the ROHC uncompressed profile in ROHC over PPP, as uncompressed packets can always be sent using the PPP protocol demultiplexing method. Therefore, no consideration was given to locking down one of the context numbers for the uncompressed profile (see [RFC3095] section 5.1.2). Note, however, that according to the ROHC specification, profile 0x0000 must not be rejected [RFC3095], so it MUST be implemented by all receivers.
在ROHC over PPP中不需要ROHC未压缩配置文件，因为未压缩的数据包始终可以使用PPP协议解复用方法发送。因此，未考虑锁定未压缩配置文件的一个上下文编号（见[RFC3095]第5.1.2节）。然而，请注意，根据ROHC规范，不得拒绝配置文件0x0000[RFC3095]，因此必须由所有接收器执行。
For each of the ROHC channel parameters MAX_CID and MRRU, the value is the maximum of the respective values negotiated for the IPCP and IPv6CP instances, if any. The ROHC channel parameter FEEDBACK_FOR is set implicitly to the reverse direction on the same PPP link (see "Sharing Context Identifier Space" above). The ROHC channel parameter LARGE_CIDS is not used, instead the PPP protocol ID on the packet is used (see "Demultiplexing of Datagrams" above).
对于每个ROHC通道参数MAX_CID和MRRU，该值是IPCP和IPv6CP实例（如果有）协商的各自值的最大值。相同PPP链路上的ROHC信道参数反馈_隐式设置为反向（见上文“共享上下文标识符空间”）。不使用ROHC信道参数LARGE_CIDS，而是使用数据包上的PPP协议ID（请参阅上面的“数据报解复用”）。
A number of parameters for ROHC must be set correctly for good compression on a specific link. E.g., the parameters k_1, n_1, k_2, n_2 in section 5.3.2.2.3 of [RFC3095] need to be set based on the error characteristics of the underlying links. As PPP links are usually run with a strong error detection scheme [RFC1662], k_1 = n_1 = k_2 = n_2 = 1 is usually a good set of values. (Note that in any case k values need to be set low enough relative to n values to allow for the limited ability of the CRC to detect errors, i.e., the CRC will succeed for about 1/8 of the packets even in case of context damage, so k/n should be significantly less than 7/8.)
必须正确设置ROHC的许多参数，以便在特定链路上进行良好压缩。例如，[RFC3095]第5.3.2.2.3节中的参数k_1、n_1、k_2、n_2需要根据基础链路的错误特征进行设置。由于PPP链路通常使用强错误检测方案[RFC1662]运行，因此k_1=n_1=k_2=n_2=1通常是一组很好的值。（注意，在任何情况下，需要将k值相对于n值设置得足够低，以允许CRC检测错误的能力有限，即，即使在上下文损坏的情况下，CRC也将成功检测约1/8的数据包，因此k/n应显著小于7/8。）
Negotiation of the option defined here imposes no additional security considerations beyond those that otherwise apply to PPP [RFC1661].
此处定义的期权谈判不涉及除PPP以外的其他安全考虑因素[RFC1661]。
The security considerations of ROHC [RFC3095] apply.
ROHC[RFC3095]的安全注意事项适用。
The use of header compression can, in rare cases, cause the misdelivery of packets. If necessary, confidentiality of packet contents should be assured by encryption.
在极少数情况下，使用报头压缩会导致数据包的误发。如有必要，应通过加密确保数据包内容的机密性。
Encryption applied at the IP layer (e.g., using IPSEC mechanisms) precludes header compression of the encrypted headers, though compression of the outer IP header and authentication/security headers is still possible as described in [RFC3095]. For RTP packets, full header compression is possible if the RTP payload is encrypted by itself without encrypting the UDP or RTP headers, as described in [RFC1889]. This method is appropriate when the UDP and RTP header information need not be kept confidential.
在IP层应用的加密（例如，使用IPSEC机制）排除了加密报头的报头压缩，尽管如[RFC3095]中所述，外部IP报头和身份验证/安全报头的压缩仍然是可能的。对于RTP数据包，如[RFC1889]中所述，如果RTP有效负载在不加密UDP或RTP报头的情况下自行加密，则完全报头压缩是可能的。当UDP和RTP报头信息不需要保密时，此方法适用。
The ROHC suboption identifier is a non-negative integer. Following the policies outlined in [RFC2434], the IANA policy for assigning new values for the suboption 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. 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 value 255 is reserved for future extensibility of the present specification.
ROHC子选项标识符为非负整数。根据[RFC2434]中概述的政策，应规定为子选项标识符分配新值的IANA政策：值及其含义必须记录在RFC或其他永久性且随时可用的参考文件中，足够详细地说明独立实现之间的互操作性是可能的。0到127的范围为IETF标准轨道规范保留；128到254的范围可用于满足此要求的其他规范（如信息RFC）。值255保留用于当前规范的未来扩展。
The following suboption identifiers are already allocated:
已分配以下子选项标识符：
Suboption Document Usage identifier
子选项文档使用标识符
1 RFC3241 Profiles
1 RFC3241剖面图
The RFC 3006 compressibility hint [RFC3006] for ROHC is 0x0003pppp, where 0xpppp is the profile assumed.
ROHC的RFC 3006压缩性提示[RFC3006]为0x0003ppp，其中0xppp是假定的剖面。
(Note that the PPP protocol identifier values 0003 and 0005 were taken from a previously reserved space that exhibits inefficient transparency in the presence of asynchronous control character escaping, as it is considered rather unlikely that ROHC will be used over links with highly populated ACCMs.)
（注意，PPP协议标识符值0003和0005取自先前保留的空间，该空间在存在异步控制字符转义的情况下显示出低效的透明度，因为认为ROHC不太可能在具有高度填充的ACCM的链路上使用。）
The present document borrows heavily from [RFC2509].
本文件大量借用了[RFC2509]。
The author would like to thank Pete McCann and James Carlson for clarifying the multiple option instance issue, Craig Fox for helping with some PPP arcana, and Lars-Erik Jonsson for supplying some final clarifications.
作者要感谢皮特·麦肯（Pete McCann）和詹姆斯·卡尔森（James Carlson）澄清了多选项实例问题，克雷格·福克斯（Craig Fox）帮助了一些PPP arcana，拉尔斯·埃里克·琼森（Lars Erik Jonsson）提供了一些最终澄清。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2472] Haskin, E. and E. Allan, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472]Haskin，E.和E.Allan，“PPP上的IP版本6”，RFC 24721998年12月。
[RFC3006] Davie, B., Casner, S., Iturralde, C., Oran, D. and J. Wroclawski, "Integrated Services in the Presence of Compressible Flows", RFC 3006, November 2000.
[RFC3006]Davie，B.，Casner，S.，Iturralde，C.，Oran，D.和J.Wroclawski，“存在可压缩流的综合服务”，RFC 3006，2000年11月。
[RFC3095] 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.
[RFC3095]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月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications", RFC 1889, January 1996.
[RFC1889]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Alvestrand，H.和T.Narten，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[RFC2509] Engan, M., Casner, S. and C. Bormann, "IP Header Compression over PPP", RFC 2509, February 1999.
[RFC2509]Engan，M.，Casner，S.和C.Bormann，“PPP上的IP报头压缩”，RFC 2509，1999年2月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]Bormann，C.，“多链路PPP的多类扩展”，RFC2686，1999年9月。
Carsten Bormann Universitaet Bremen FB3 TZI Postfach 330440 D-28334 Bremen, GERMANY
德国不来梅卡斯滕·鲍曼大学FB3 TZI Postfach 330440 D-28334
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Phone: +49.421.218-7024
Fax: +49.421.218-7000
EMail: cabo@tzi.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。