Network Working Group T. Koren
Request for Comments: 3544 Cisco Systems
Obsoletes: 2509 S. Casner
Category: Standards Track Packet Design
C. Bormann
Universitaet Bremen TZI
July 2003
Network Working Group T. Koren
Request for Comments: 3544 Cisco Systems
Obsoletes: 2509 S. Casner
Category: Standards Track Packet Design
C. Bormann
Universitaet Bremen TZI
July 2003
IP Header Compression over PPP
基于PPP的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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-Point Protocol (RFC 1661). It defines extensions to the PPP Control Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545.
本文档描述了一种用于协商在点到点协议（RFC 1661）上传输的IP数据报上使用报头压缩的选项。它定义了IPv4和IPv6（RFC 1332、RFC 2472）PPP控制协议的扩展。报头压缩可与RFC 2507、RFC 2508和RFC 3545中规定的TCP、UDP和RTP传输协议结合应用于IPv4和IPv6数据报。
The IP Header Compression (IPHC) defined in [RFC2507] may be used for compression of both IPv4 and IPv6 datagrams or packets encapsulated with multiple IP headers. IPHC is also capable of compressing both TCP and UDP transport protocol headers. The IP/UDP/RTP header compression defined in [RFC2508] and [RFC3545] fits within the framework defined by IPHC so that it may also be applied to both IPv4 and IPv6 packets.
[RFC2507]中定义的IP报头压缩（IPHC）可用于压缩IPv4和IPv6数据报或用多个IP报头封装的数据包。IPHC还能够压缩TCP和UDP传输协议头。[RFC2508]和[RFC3545]中定义的IP/UDP/RTP报头压缩符合IPHC定义的框架，因此它也可以应用于IPv4和IPv6数据包。
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中用于协商压缩方案参数的配置选项。
This document obsoletes RFC 2509, adding two new suboptions to the IP header compression configuration option. One suboption negotiates usage of Enhanced RTP-Compression (specified in [RFC3545]), and the other suboption negotiates header compression for only TCP or only non-TCP packets.
本文档淘汰了RFC 2509，在IP报头压缩配置选项中添加了两个新的子选项。一个子选项协商增强RTP压缩（在[RFC3545]中指定）的使用，另一个子选项协商仅针对TCP或仅针对非TCP数据包的报头压缩。
IPHC relies on the link layer's ability to indicate the types of datagrams carried in the link layer frames. In this document nine new types for the PPP Data Link Layer Protocol Field are defined along with their meaning.
IPHC依赖于链路层指示链路层帧中承载的数据报类型的能力。本文定义了PPP数据链路层协议字段的九种新类型及其含义。
In general, header compression schemes that use delta encoding of compressed packets require that the lower layer does not reorder packets between compressor and decompressor. IPHC uses delta encoding of compressed packets for TCP and RTP. The IPHC specification [RFC2507] includes methods that allow link layers that may reorder packets to be used with IPHC. Since PPP does not reorder packets these mechanisms are disabled by default. 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.
通常，使用压缩数据包的增量编码的报头压缩方案要求较低层不在压缩器和解压缩器之间重新排序数据包。IPHC对TCP和RTP使用压缩数据包的增量编码。IPHC规范[RFC2507]包括允许链路层对IPHC使用的数据包重新排序的方法。由于PPP不会对数据包重新排序，因此默认情况下禁用这些机制。当使用诸如多类多链路PPP[RFC2686]之类的重新排序机制时，必须注意不要对共享相同压缩上下文的数据包进行重新排序。
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 IPHC scheme.
选项格式的结构允许将来扩展到IPHC方案。
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. [RFC3241] 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.
注：PPP[RFC1661]、[RFC1331]、[RFC1332]的链路和网络层参数协商规范不禁止一个配置选项的多个实例，但规定一个配置选项的规范必须明确允许多个实例。[RFC3241]通过显式允许发送IP压缩协议配置选项的多个实例来更新RFC 1332，每个实例具有不同的IP压缩协议值。每种类型的压缩协议都可以独立地建立自己的参数。
NOTE: [RFC1332] is not explicit about whether the option negotiates the capabilities of the receiver or of the sender. In keeping with current practice, we assume that the option describes the capabilities of the decompressor (receiving side) of the peer that sends the Config-Req.
注意：[RFC1332]未明确说明该选项是协商接收方还是发送方的能力。根据当前的实践，我们假设该选项描述发送配置请求的对等方的解压缩器（接收端）的功能。
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 IP Header Compression. Successful negotiation of parameters enables the use of Protocol Identifiers FULL_HEADER, COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and CONTEXT_STATE as specified in [RFC2507]. The option format is summarized below. The fields are transmitted from left to right.
此NCP配置选项用于协商IP标头压缩的参数。成功协商参数可以使用[RFC2507]中规定的协议标识符FULL_头、压缩_TCP、压缩_TCP_节点、压缩_非_TCP和上下文_状态。选项格式概述如下。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TCP_SPACE | NON_TCP_SPACE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F_MAX_PERIOD | F_MAX_TIME |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX_HEADER | suboptions...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
类型2
Length >= 14
长度>=14
The length may be increased if the presence of additional parameters is indicated by additional suboptions.
如果附加子选项指示存在附加参数，则长度可能会增加。
IP-Compression-Protocol 0061 (hex)
IP压缩协议0061（十六进制）
TCP_SPACE The TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for TCP.
TCP_SPACE TCP_SPACE字段是两个八位字节，表示在为TCP分配的上下文标识符空间中上下文标识符的最大值。
Suggested value: 15
建议值：15
TCP_SPACE must be at least 0 and at most 255 (the value 0 implies having one context).
TCP_空间必须至少为0，最多为255（值0表示有一个上下文）。
NON_TCP_SPACE The NON_TCP_SPACE field is two octets and indicates the maximum value of a context identifier in the space of context identifiers allocated for non-TCP. These context identifiers are carried in COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet headers.
NON_TCP_SPACE NON_TCP_SPACE字段是两个八位字节，表示分配给非TCP的上下文标识符空间中上下文标识符的最大值。这些上下文标识符包含在压缩的\u非\u TCP、压缩的\u UDP和压缩的\u RTP数据包头中。
Suggested value: 15
建议值：15
NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0 implies having one context).
非TCP_空间必须至少为0，最多为65535（值0表示有一个上下文）。
F_MAX_PERIOD Maximum interval between full headers. No more than F_MAX_PERIOD COMPRESSED_NON_TCP headers may be sent between FULL_HEADER headers.
F_MAX_PERIOD完整标题之间的最大间隔。在完整的\u头标头之间发送的压缩\u非\u TCP头不得超过F_MAX \u PERIOD。
Suggested value: 256
建议值：256
A value of zero implies infinity, i.e. there is no limit to the number of consecutive COMPRESSED_NON_TCP headers.
值为零意味着无穷大，即对连续压缩的\u非\u TCP头的数量没有限制。
F_MAX_TIME Maximum time interval between full headers. COMPRESSED_NON_TCP headers may not be sent more than F_MAX_TIME seconds after sending the last FULL_HEADER header.
F_MAX_TIME完整标头之间的最大时间间隔。在发送最后一个完整的\u头后，压缩的\u非\u TCP头的发送时间不得超过F_MAX \u时间秒。
Suggested value: 5 seconds
建议值：5秒
A value of zero implies infinity.
值为零意味着无穷大。
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_头设置为足够大的值，以覆盖网络和传输层头的常见组合。
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.
子选项“子选项”字段由零个或多个子选项组成。每个子选项由一个类型字段、一个长度字段和零个或多个由子选项类型定义的参数八位字节组成。长度字段的值指示子选项的整个长度，包括类型字段和长度字段的长度。
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 RTP-Compression suboption is included in the NCP IP-Compression-Protocol option for IPHC if IP/UDP/RTP compression is to be enabled.
如果要启用IP/UDP/RTP压缩，则IPHC的NCP IP压缩协议选项中包含RTP压缩子选项。
Inclusion of the RTP-Compression suboption enables use of additional Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with additional forms of CONTEXT_STATE as specified in [RFC2508].
如[RFC2508]中所述，包含RTP压缩子选项可以使用额外的协议标识符COMPRESSED_RTP和COMPRESSED_UDP以及其他形式的上下文_状态。
Description
描述
Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP and CONTEXT_STATE as specified in [RFC2508].
允许使用[RFC2508]中指定的协议标识符COMPRESSED_RTP、COMPRESSED_UDP和CONTEXT_STATE。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1
类型1
Length 2
长度2
To use the enhanced RTP header compression defined in [RFC3545], a new sub-option 2 is added. Sub-option 2 is negotiated instead of, not in addition to, sub-option 1.
为了使用[RFC3545]中定义的增强RTP报头压缩，添加了一个新的子选项2。子选项2是谈判而非补充子选项1。
Description
描述
Enable use of Protocol Identifiers COMPRESSED_RTP and CONTEXT_STATE as specified in [RFC2508]. In addition, enable use of [RFC3545] compliant compression including the use of Protocol Identifier COMPRESSED_UDP with additional flags and use of the C flag with the FULL_HEADER Protocol Identifier to indicate use of HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets.
允许使用[RFC2508]中指定的协议标识符压缩\u RTP和上下文\u状态。此外，允许使用[RFC3545]兼容压缩，包括使用带有附加标志的协议标识符COMPRESSED_UDP，以及使用带有完整_头协议标识符的C标志，以指示使用带有压缩_RTP和压缩_UDP数据包的HDRCKSUM。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
类型2
Length 2
长度2
2.4. Negotiating header compression for only TCP or only non-TCP packets
2.4. 仅针对TCP或仅针对非TCP数据包协商标头压缩
In RFC 2509 it was not possible to negotiate only TCP header compression or only non-TCP header compression because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 context is negotiated.
在RFC 2509中，无法仅协商TCP头压缩或仅协商非TCP头压缩，因为TCP_空间或非TCP_空间字段中的值为0实际上意味着协商1个上下文。
A new suboption 3 is added to allow specifying that the number of contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the corresponding compression.
添加了新的子选项3，以允许指定TCP_空间或非TCP_空间的上下文数为零，从而禁用相应压缩的使用。
Description
描述
Enable header compression for only TCP or only non-TCP packets.
仅对TCP或非TCP数据包启用标头压缩。
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 | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 3
类型3
Length 3
长度3
Parameter
参数
The parameter is 1 byte with one of the following values:
该参数为1字节，具有以下值之一：
1 = the number of contexts for TCP_SPACE is 0 2 = the number of contexts for NON_TCP_SPACE is 0
1=TCP_空间的上下文数为0 2=非TCP_空间的上下文数为0
This suboption overrides the values that were previously assigned to TCP_SPACE and NON_TCP_SPACE in the IP Header Compression option.
此子选项覆盖以前在IP标头压缩选项中分配给TCP_空间和非TCP_空间的值。
If suboption 3 is included multiple times with parameter 1 and 2, compression is disabled for all packets.
如果子选项3多次包含参数1和2，则对所有数据包禁用压缩。
The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. Both IPCP and IPV6CP are able to negotiate option parameter values for IPHC. These values apply to the compression of packets where the outer header is an IPv4 header and an IPv6 header, respectively.
IPHC协议能够压缩IPv6和IPv4数据报。IPCP和IPV6CP都能够协商IPHC的选项参数值。这些值适用于数据包的压缩，其中外部报头分别是IPv4报头和IPv6报头。
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数据报报头的压缩和解压缩，上下文标识符空间是共享的。虽然参数值是独立协商的，但当参数值不同时，共享上下文标识符空间变得更加复杂。由于压缩包共享上下文标识符空间，压缩引擎必须从公共池中分配上下文标识符；对于压缩数据包，解压缩程序必须检查上下文状态，以确定用于解压缩的参数。
Context identifier spaces are not shared between TCP and non-TCP/UDP/RTP. Doing so would require additional mechanisms to ensure that no error can occur when switching from using a context identifier for TCP to non-TCP.
TCP和非TCP/UDP/RTP之间不共享上下文标识符空间。这样做需要额外的机制来确保从使用TCP上下文标识符切换到非TCP时不会发生错误。
The IPHC specification [RFC2507] defines four header formats for different types of compressed headers. They are compressed TCP, compressed TCP with no delta encoding, compressed non-TCP with 8 bit CID and compressed non-TCP with 16 bit CID. The two non-TCP formats may be distinguished by their contents so both may use the same link-level identifier. A fifth header format, the full header is distinct from a regular header in that it carries additional information to establish shared context between the compressor and decompressor.
IPHC规范[RFC2507]为不同类型的压缩头定义了四种头格式。它们是压缩TCP、无增量编码的压缩TCP、具有8位CID的压缩非TCP和具有16位CID的压缩非TCP。这两种非TCP格式可以通过其内容来区分，因此两者可以使用相同的链路级标识符。第五种报头格式，完整报头不同于常规报头，因为它携带附加信息以在压缩器和解压缩器之间建立共享上下文。
The specification of IP/UDP/RTP Header Compression [RFC2508] defines four additional formats of compressed headers. They are for compressed UDP and compressed RTP (on top of UDP), both with either 8- or 16-bit CIDs. In addition, there is an explicit error message from the decompressor to the compressor.
IP/UDP/RTP报头压缩规范[RFC2508]定义了四种额外的压缩报头格式。它们用于压缩UDP和压缩RTP（在UDP之上），两者都具有8位或16位CID。此外，从解压器到压缩器还有一条明确的错误消息。
The link layer must be able to indicate these header formats with distinct values. Nine PPP Data Link Layer Protocol Field values are specified below.
链接层必须能够用不同的值指示这些标题格式。下面指定了九个PPP数据链路层协议字段值。
FULL_HEADER The frame contains a full header as specified in [RFC2508] Section 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507] Section 5.3. Value: 0061 (hex)
完整标题框架包含[RFC2508]第3.3.1节规定的完整标题。这与[RFC2507]第5.3节中规定的完整_标题相同。值：0061（十六进制）
COMPRESSED_TCP The frame contains a datagram with a compressed header with the format as specified in [RFC2507] Section 6a. Value: 0063 (hex)
压缩的\u TCP帧包含具有[RFC2507]第6a节规定格式的压缩头的数据报。值：0063（十六进制）
COMPRESSED_TCP_NODELTA The frame contains a datagram with a compressed header with the format as specified in [RFC2507] Section 6b. Value: 2063 (hex)
压缩的_TCP_NODELTA帧包含一个数据报，该数据报具有[RFC2507]第6b节规定格式的压缩头。值：2063（十六进制）
COMPRESSED_NON_TCP The frame contains a datagram with a compressed header with the format as specified in either Section 6c or Section 6d of [RFC2507]. Value: 0065 (hex)
压缩\u非\u TCP帧包含一个数据报，该数据报具有[RFC2507]第6c节或第6d节规定格式的压缩头。值：0065（十六进制）
COMPRESSED_RTP_8 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.2, using 8-bit CIDs. Value: 0069 (hex)
COMPRESSED_RTP_8该帧包含一个数据报，该数据报具有[RFC2508]第3.3.2节规定格式的压缩头，使用8位CID。值：0069（十六进制）
COMPRESSED_RTP_16 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.2, using 16-bit CIDs. Value: 2069 (hex)
压缩_RTP_16该帧包含一个数据报，该数据报具有[RFC2508]第3.3.2节规定格式的压缩头，使用16位CID。值：2069（十六进制）
COMPRESSED_UDP_8 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.3 or as specified in [RFC3545] Section 2.1, using 8-bit CIDs. Value: 0067 (hex)
压缩_UDP_8该帧包含一个数据报，该数据报具有[RFC2508]第3.3.3节或[RFC3545]第2.1节规定格式的压缩头，使用8位CID。值：0067（十六进制）
COMPRESSED_UDP_16 The frame contains a datagram with a compressed header with the format as specified in [RFC2508] Section 3.3.3 or as specified in [RFC3545] Section 2.1, using 16-bit CIDs. Value: 2067 (hex)
压缩_UDP_16该帧包含一个数据报，该数据报具有[RFC2508]第3.3.3节或[RFC3545]第2.1节规定的格式的压缩报头，使用16位CID。值：2067（十六进制）
CONTEXT_STATE The frame is a link-level message sent from the decompressor to the compressor as specified in [RFC2508] Section 3.3.5. Value: 2065 (hex)
CONTEXT_STATE帧是一条链路级消息，按照[RFC2508]第3.3.5节的规定，从解压器发送到压缩器。值：2065（十六进制）
Two new suboptions are specified. See Sections 2.3 and 2.4.
指定了两个新的子选项。见第2.3节和第2.4节。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for low-speed serial links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP报头”，RFC1144，1990年2月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]McGregor，G.“PPP互联网协议控制协议（IPCP）”，RFC1332，1992年5月。
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998.
[RFC2472]Haskin，D.和E.Allen，“PPP上的IP版本6”，RFC 24721998年12月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for IP", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP的报头压缩”，RFC 2507，1999年2月。
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[RFC2508]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering", RFC 3545, July 2003.
[RFC3545]Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.和P.Ruddy，“用于具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 35452003年7月。
[RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]辛普森，W.，编辑，“点对点协议（PPP）”，标准51，RFC1661，1994年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]Bormann，C.，“多链路PPP的多类扩展”，RFC2686，1999年9月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 35502003年7月。
This document does not require any additional allocations from existing namespaces in the IANA Point-to-Point Protocol Field Assignments registry. However, there are three namespaces that were defined by RFC 1332, RFC 2472, and RFC 2509 but not created in the registry. Those three namespaces, described below, have been added to the PPP registry. This document specifies two additional allocations in the third one.
本文档不需要IANA点到点协议字段分配注册表中现有名称空间的任何额外分配。但是，有三个名称空间是由RFC 1332、RFC 2472和RFC 2509定义的，但没有在注册表中创建。下面描述的这三个名称空间已添加到PPP注册表中。本文件在第三次分配中指定了两次额外分配。
Section 3.2 of RFC 1332 specifies an IP-Compression-Protocol Configuration Option for the PPP IP Control Protocol and defines one value for the IP-Compression-Protocol type field in that option. An IANA registry has been created to allocate additional values for that type field. As stated in RFC 1332, the values for the IP-Compression-Protocol type field are always the same as the (primary) PPP DLL Protocol Number assigned to packets of the particular compression protocol. Assignment of additional IP-Compression-Protocol type values is through the IETF consensus procedure as specified in [RFC2434].
RFC 1332第3.2节规定了PPP IP控制协议的IP压缩协议配置选项，并为该选项中的IP压缩协议类型字段定义了一个值。已创建IANA注册表，以便为该类型字段分配其他值。如RFC 1332中所述，IP压缩协议类型字段的值始终与分配给特定压缩协议的数据包的（主）PPP DLL协议编号相同。按照[RFC2434]中的规定，通过IETF共识程序分配额外的IP压缩协议类型值。
Section 4.2 of RFC 2472 specifies an IPv6-Compression-Protocol Configuration Option for the PPP IPv6 Control Protocol and defines one value for the IPv6-Compression-Protocol type field in that option. An IANA registry has been created to allocate additional values for that type field. The IPv6-Compression-Protocol Configuration Option has the same structure as the IP-Compression-Protocol Configuration Option defined in RFC 1332, but the set of values defined for the type field may be different. As stated in RFC 2472, the values for the IPv6-Compression-Protocol type field are always the same as the (primary) PPP DLL Protocol Number assigned to packets of the particular compression protocol. Assignment of additional IPv6-Compression-Protocol type values is through the IETF consensus procedure as specified in [RFC2434].
RFC 2472的第4.2节规定了PPP IPv6控制协议的IPv6压缩协议配置选项，并为该选项中的IPv6压缩协议类型字段定义了一个值。已创建IANA注册表，以便为该类型字段分配其他值。IPv6压缩协议配置选项的结构与RFC 1332中定义的IP压缩协议配置选项相同，但为类型字段定义的值集可能不同。如RFC 2472中所述，IPv6压缩协议类型字段的值始终与分配给特定压缩协议的数据包的（主）PPP DLL协议号相同。按照[RFC2434]中的规定，通过IETF共识程序分配额外的IPv6压缩协议类型值。
Section 2.1 of RFC 2509 specifies an additional type value to be registered for both the IP-Compression-Protocol Configuration Option and the IPv6-Compression-Protocol Configuration Option to indicate use of the "IP Header Compression" protocol. The specification of that type value is repeated in Section 2.1 of this document which obsoletes RFC 2509. In conjunction with the additional type value, the format for the variable-length option is specified. The format includes a suboption field that may contain one or more suboptions. Each suboption begins with a suboption type value. An IANA registry has been created for the suboption type values; and is titled, "IP Header Compression Configuration Option Suboption Types".
RFC 2509第2.1节规定了为IP压缩协议配置选项和IPv6压缩协议配置选项注册的附加类型值，以指示“IP头压缩”协议的使用。本文件第2.1节重复了该类型值的规范，该节废除了RFC 2509。与附加类型值一起指定可变长度选项的格式。该格式包含可能包含一个或多个子选项的子选项字段。每个子选项都以一个子选项类型值开始。已为子选项类型值创建IANA注册表；标题为“IP头压缩配置选项子选项类型”。
Section 2.2 of RFC 2509 (and this document) defines one suboption type. Sections 2.3 and 2.4 of this document define two additional suboption types. It is expected that the number of additional suboptions that will need to be defined is small. Therefore, anyone wishing to define new suboptions is required to produce a revision of this document to be vetted through the normal Internet Standards process, as specified in [RFC2434].
RFC 2509（以及本文件）第2.2节定义了一种子选项类型。本文件第2.3节和第2.4节定义了两个额外的子选项类型。预计需要定义的附加子选项数量较少。因此，如[RFC2434]所述，任何希望定义新子选项的人都需要对本文件进行修订，以通过正常的互联网标准流程进行审查。
RFC 2509 also defines nine PPP Data Link Layer Protocol Field values which are already listed in the IANA registry of Point-to-Point Protocol Field Assignments. Section 4 of this document repeats the specification of those values without change.
RFC 2509还定义了九个PPP数据链路层协议字段值，这些值已在IANA点到点协议字段分配注册表中列出。本文件第4节重复了这些值的规范，未作任何更改。
Negotiation of the option defined here imposes no additional security considerations beyond those that otherwise apply to PPP [RFC1661].
此处定义的期权谈判不涉及除PPP以外的其他安全考虑因素[RFC1661]。
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 [RFC2507]. 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 [RFC3550]. This method is appropriate when the UDP and RTP header information need not be kept confidential.
在IP层应用的加密（例如，使用IPSEC机制）排除了加密报头的报头压缩，尽管如[RFC2507]中所述，外部IP报头和认证/安全报头的压缩仍然是可能的。对于RTP数据包，如[RFC3550]中所述，如果RTP有效负载在不加密UDP或RTP报头的情况下自行加密，则完全报头压缩是可能的。当UDP和RTP报头信息不需要保密时，此方法适用。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Mathias Engan was the primary author of RFC 2509, of which this document is a revision.
Mathias Engan是RFC 2509的主要作者，本文件是RFC 2509的修订版。
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号，Tmima科伦思科系统有限公司，邮编95134-1706
EMail: tmima@cisco.com
EMail: tmima@cisco.com
Stephen L. Casner Packet Design 3400 Hillview Avenue, Building 3 Palo Alto, CA 94304 United States
Stephen L.Casner Packet Design美国加利福尼亚州帕洛阿尔托市Hillview大道3400号3号楼，邮编94304
EMail: casner@packetdesign.com
EMail: casner@packetdesign.com
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。