Network Working Group J. Ash, Ed.
Request for Comments: 4901 J. Hand, Ed.
Category: Standards Track AT&T
A. Malis, Ed.
Verizon Communications
June 2007
Network Working Group J. Ash, Ed.
Request for Comments: 4901 J. Hand, Ed.
Category: Standards Track AT&T
A. Malis, Ed.
Verizon Communications
June 2007
Protocol Extensions for Header Compression over MPLS
MPLS上报头压缩的协议扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This specification defines how to use Multi-Protocol Label Switching (MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP. This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to-point link.
本规范定义了如何使用多协议标签交换（MPLS）在MPLS标签交换路径上路由头压缩（HC）数据包。HC可以显著降低数据包报头开销，并且结合MPLS，还可以提高带宽效率和处理可伸缩性（在每个路由器上使用HC的最大同时压缩流数量）。这里我们定义了如何使用MPLS伪线在入口和出口MPLS标签交换路由器之间传输HC上下文和控制消息。这是为一组特定的现有HC机制定义的，这些机制可能用于支持IP语音。本规范还描述了允许支持未来（尚未定义）HC协议的扩展机制。在本规范中，每个HC协议在单个伪线实例上独立运行，就像在单个点到点链路上一样。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Header Compression over MPLS Protocol Overview ..................6
4. Protocol Specifications ........................................11
4.1. MPLS Pseudowire Setup and Signaling .......................13
4.2. Header Compression Scheme Setup, Negotiation, and
Signaling .................................................14
4.2.1. Configuration Option Format [RFC3544] ..............15
4.2.2. RTP-Compression Suboption [RFC3544] ................17
4.2.3. Enhanced RTP-Compression Suboption [RFC3544] .......18
4.2.4. Negotiating Header Compression for Only TCP
or Only Non-TCP Packets [RFC3544] ..................19
4.2.5. Configuration Option Format [RFC3241] ..............20
4.2.6. PROFILES Suboption [RFC3241] .......................21
4.3. Encapsulation of Header Compressed Packets ................22
4.4. Packet Reordering .........................................23
5. HC Pseudowire Setup Example ....................................24
6. Security Considerations ........................................29
7. Acknowledgements ...............................................29
8. IANA Considerations ............................................29
9. Normative References ...........................................30
10. Informative References ........................................31
11. Contributors ..................................................33
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Header Compression over MPLS Protocol Overview ..................6
4. Protocol Specifications ........................................11
4.1. MPLS Pseudowire Setup and Signaling .......................13
4.2. Header Compression Scheme Setup, Negotiation, and
Signaling .................................................14
4.2.1. Configuration Option Format [RFC3544] ..............15
4.2.2. RTP-Compression Suboption [RFC3544] ................17
4.2.3. Enhanced RTP-Compression Suboption [RFC3544] .......18
4.2.4. Negotiating Header Compression for Only TCP
or Only Non-TCP Packets [RFC3544] ..................19
4.2.5. Configuration Option Format [RFC3241] ..............20
4.2.6. PROFILES Suboption [RFC3241] .......................21
4.3. Encapsulation of Header Compressed Packets ................22
4.4. Packet Reordering .........................................23
5. HC Pseudowire Setup Example ....................................24
6. Security Considerations ........................................29
7. Acknowledgements ...............................................29
8. IANA Considerations ............................................29
9. Normative References ...........................................30
10. Informative References ........................................31
11. Contributors ..................................................33
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [RFC3031] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. MPLS VPNs (e.g., [RFC4364]) use label stacking, and in the simplest case of IPv4 the total packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. When IPv6 is used, the relative size of the header in comparison to the payload is even greater. The interest in header compression (HC) is to exploit the possibility of significantly reducing the overhead through various compression mechanisms, such as with enhanced compressed RTP (ECRTP) [RFC3545] and robust header compression (ROHC) [RFC3095, RFC3095bis, RFC4815], and also to increase scalability of HC. MPLS is used to route HC packets over an MPLS label switched path (LSP) without compression/decompression cycles at each router. Such an HC over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous compressed flows that use HC at each router. Goals and requirements for HC over MPLS are discussed in [RFC4247]. The solution using MPLS pseudowire (PW) technology put forth in this document has been designed to address these goals and requirements.
IP语音（VoIP）通常使用封装语音/RTP/UDP/IP。当添加MPLS标签[RFC3031]时，这将成为语音/RTP/UDP/IP/MPLS标签。MPLS VPN（例如，[RFC4364]）使用标签堆叠，在IPv4的最简单情况下，总分组报头至少为48字节，而语音有效负载通常不超过30字节。使用IPv6时，与有效负载相比，报头的相对大小更大。报头压缩（HC）的兴趣在于通过各种压缩机制，如增强的压缩RTP（ECRTP）[RFC3545]和健壮的报头压缩（ROHC）[RFC3095，RFC3095bis，RFC4815]来利用显著降低开销的可能性，并提高HC的可伸缩性。MPLS用于在MPLS标签交换路径（LSP）上路由HC数据包，而无需在每个路由器上进行压缩/解压缩循环。这种HC-over-MPLS能力可以提高带宽效率以及在每个路由器上使用HC的最大数量的同时压缩流的处理可伸缩性。[RFC4247]中讨论了基于MPLS的HC的目标和要求。本文档中提出的使用MPLS伪线（PW）技术的解决方案旨在满足这些目标和要求。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Context: the state associated with a flow subject to IP header compression. While the exact nature of the context is specific to a particular HC protocol (CRTP, ECRTP, ROHC, etc.), this state typically includes:
上下文：与受IP头压缩的流关联的状态。虽然上下文的确切性质特定于特定HC协议（CRTP、ECRTP、ROHC等），但该状态通常包括：
- the values of all of the fields in all of the headers (IP, UDP, TCP, RTP, Encapsulating Security Payload (ESP), etc.) that the particular header compression protocol operates on for the last packet of the flow sent (by the compressor) or received (by the decompressor).
- 对于发送（由压缩器发送）或接收（由解压缩器接收）的流的最后一个数据包，特定报头压缩协议操作的所有报头（IP、UDP、TCP、RTP、封装安全有效负载（ESP）等）中所有字段的值。
- the change in the value of some of the fields in the IP, UDP, TCP, etc. headers between the last two consecutive sent packets (compressor) or received packets (decompressor) of the flow. Some of the fields in the header change by a constant amount between subsequent packets in the flow most of the time. Saving the changes in these fields from packet to packet allows
- 在流的最后两个连续发送的数据包（压缩器）或接收的数据包（解压缩器）之间，IP、UDP、TCP等标头中某些字段的值的变化。报头中的一些字段在流中大部分时间在后续数据包之间以恒定量变化。将这些字段中的更改从一个数据包保存到另一个数据包允许
verification that a constant rate of change is taking place, and to take appropriate action when a deviation from the normal changes are encountered.
验证是否发生了恒定的变化率，并在遇到偏离正常变化时采取适当措施。
For most HC protocols, a copy of the context of each compressed flow is maintained at both the compressor and the decompressor.
对于大多数HC协议，每个压缩流的上下文的副本都在压缩机和解压缩器处维护。
compressed Real-time Transport Protocol (CRTP): a particular HC protocol described in [RFC2508].
压缩实时传输协议（CRTP）：在[RFC2508]中描述的特定HC协议。
Context ID (CID): a small number, typically 8 or 16 bits, used to identify a particular flow, and the context associated with the flow. Most HC protocols in essence work by sending the CID across the link in place of the full header, along with any unexpected changes in the values in the various fields of the headers.
上下文ID（CID）：一个小数字，通常为8或16位，用于标识特定流以及与该流关联的上下文。大多数HC协议本质上都是通过在链路上发送CID来代替完整的报头，以及报头各个字段中的值的任何意外更改来工作的。
Enhanced Compressed Real-time Protocol (ECRTP): a particular HC protocol described in [RFC3545].
增强型压缩实时协议（ECRTP）：在[RFC3545]中描述的特定HC协议。
Forwarding Equivalence Class (FEC): a group of packets that are forwarded in the same manner (e.g., over the same LSP, with the same forwarding treatment)
转发等价类（FEC）：以相同方式转发的一组数据包（例如，通过相同的LSP，采用相同的转发处理）
Header Compression scheme (HC scheme): a particular method of performing HC and its associated protocol. Multiple methods of HC have been defined, including Robust Header Compression (ROHC [RFC3095, RFC3095bis]), compressed RTP (CRTP, [RFC2508]), enhanced CRTP (ECRTP, [RFC3545]), and IP Header Compression (IPHC, [RFC2507]). This document explicitly supports all of the HC schemes listed above, and is intended to be extensible to others that may be developed.
报头压缩方案（HC方案）：执行HC及其相关协议的特定方法。已经定义了多种HC方法，包括鲁棒报头压缩（ROHC[RFC3095，RFC3095bis]）、压缩RTP（CRTP[RFC2508]）、增强CRTP（ECRTP[RFC3545]）和IP报头压缩（IPHC[RFC2507]）。本文件明确支持上述所有HC方案，并可扩展至其他可能开发的方案。
Header Compression channel (HC channel): a session established between a header compressor and a header decompressor using a single HC scheme, over which multiple individual flows may be compressed. From this perspective, every PPP link over which HC is operating defines a single HC channel, and based on this specification, every HC PW defines a single HC channel. HC PWs are bi-directional, which means that a unidirectional leg of the PW is set up in each direction. One leg of the bi-directional PW may be set up to carry only compression feedback, not header compressed traffic. An HC channel should not be confused with the individual traffic flows that may be compressed using a single Context ID. Each HC channel manages a set of unique CIDs.
报头压缩通道（HC通道）：使用单个HC方案在报头压缩器和报头解压缩器之间建立的会话，通过该会话可以压缩多个单独的流。从这个角度来看，HC运行的每个PPP链路定义了一个HC信道，并且基于该规范，每个HC PW定义了一个HC信道。HC PW是双向的，这意味着在每个方向上设置PW的单向支腿。双向PW的一个分支可以设置为仅承载压缩反馈，而不承载报头压缩的业务。HC通道不应与可使用单个上下文ID压缩的单个交通流混淆。每个HC通道管理一组唯一的CID。
IP Header Compression (IPHC): a particular HC protocol described in [RFC2507]
IP报头压缩（IPHC）：在[RFC2507]中描述的特定HC协议
Label: a short fixed length physically contiguous identifier that is used to identify a FEC, usually of local significance
标签：一种短的固定长度的物理连续标识符，用于识别FEC，通常具有局部意义
Label Stack: an ordered set of labels
标签堆栈：一组有序的标签
Label Switched Path (LSP): the path through one or more LSRs at one level of the hierarchy followed by a packet in a particular forwarding equivalence class (FEC)
标签交换路径（LSP）：在层次结构的一个级别上通过一个或多个LSR的路径，后跟特定转发等价类（FEC）中的数据包
Label Switching Router (LSR): an MPLS node that is capable of forwarding native L3 packets
标签交换路由器（LSR）：能够转发本机L3数据包的MPLS节点
MPLS domain: a contiguous set of nodes that operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain
MPLS域：操作MPLS路由和转发的一组连续节点，它们也位于一个路由或管理域中
MPLS label: a label that is carried in a packet header, and that represents the packet's FEC
MPLS标签：包头中携带的标签，表示包的FEC
MPLS node: a node that is running MPLS. An MPLS node will be aware of MPLS control protocols, will operate one or more L3 routing protocols, and will be capable of forwarding packets based on labels. An MPLS node may also optionally be capable of forwarding native L3 packets.
MPLS节点：运行MPLS的节点。MPLS节点将知道MPLS控制协议，将操作一个或多个L3路由协议，并且将能够基于标签转发数据包。MPLS节点还可以可选地能够转发本机L3分组。
Multiprotocol Label Switching (MPLS): an IETF working group and the effort associated with the working group, including the technology (signaling, encapsulation, etc.) itself
多协议标签交换（MPLS）：IETF工作组及其相关工作，包括技术（信令、封装等）本身
Packet Switched Network (PSN): Within the context of Pseudowire PWE3, this is a network using IP or MPLS as the mechanism for packet forwarding.
分组交换网络（PSN）：在伪线PWE3的上下文中，这是一个使用IP或MPLS作为分组转发机制的网络。
Protocol Data Unit (PDU): the unit of data output to, or received from, the network by a protocol layer.
协议数据单元（PDU）：协议层向网络输出或从网络接收的数据单元。
Pseudowire (PW): a mechanism that carries the essential elements of an emulated service from one provider edge router to one or more other provider edge routers over a PSN
Pseudowire（PW）：通过PSN将模拟服务的基本元素从一个提供商边缘路由器传送到一个或多个其他提供商边缘路由器的机制
Pseudowire Emulation Edge to Edge (PWE3): a mechanism that emulates the essential attributes of service (such as a T1 leased line or Frame Relay) over a PSN
伪线仿真边到边（PWE3）：通过PSN模拟服务的基本属性（如T1专线或帧中继）的机制
Pseudowire PDU (PW-PDU): a PDU sent on the PW that contains all of the data and control information necessary to emulate the desired service
伪线PDU（PW-PDU）：在PW上发送的PDU，包含模拟所需服务所需的所有数据和控制信息
PSN Tunnel: a tunnel across a PSN, inside which one or more PWs can be carried
PSN隧道：穿过PSN的隧道，其中可承载一个或多个PW
PSN Tunnel Signaling: a protocol used to set up, maintain, and tear down the underlying PSN tunnel
PSN隧道信令：用于建立、维护和拆除基础PSN隧道的协议
PW Demultiplexer: data-plane method of identifying a PW terminating at a provider edge router
PW解复用器：识别终止于提供商边缘路由器的PW的数据平面方法
Real Time Transport Protocol (RTP): a protocol for end-to-end network transport for applications transmitting real-time data, such as audio or video [RFC3550].
实时传输协议（RTP）：用于传输实时数据（如音频或视频）的应用程序的端到端网络传输协议[RFC3550]。
Robust Header Compression (ROHC): a particular HC protocol consisting of a framework [RFC3095bis] and a number of profiles for different protocols, e.g., for RTP, UDP, ESP [RFC3095], and IP [RFC3843]
鲁棒报头压缩（ROHC）：一种特殊的HC协议，包括一个框架[RFC3095bis]和多个不同协议的配置文件，例如RTP、UDP、ESP[RFC3095]和IP[RFC3843]
Tunnel: a method of transparently carrying information over a network
隧道：一种通过网络透明地传送信息的方法
To implement HC over MPLS, after the ingress router applies the HC algorithm to the IP packet, the compressed packet is forwarded on an MPLS LSP using MPLS labels, and then the egress router restores the uncompressed header. Any of a number of HC algorithms/protocols can be used. These algorithms have generally been designed for operation over a single point-to-point link-layer hop. MPLS PWs [RFC3985], which are used to provide emulation of many point-to-point link layer services (such as frame relay permanent virtual circuits (PVCs) and ATM PVCs) are used here to provide emulation of a single, point-to-point link layer hop over which HC traffic may be transported.
为了在MPLS上实现HC，在入口路由器将HC算法应用于IP分组之后，使用MPLS标签在MPLS LSP上转发压缩分组，然后出口路由器恢复未压缩的报头。可以使用多种HC算法/协议中的任何一种。这些算法通常设计用于在单个点到点链路层上运行。MPLS PWs[RFC3985]，用于提供许多点到点链路层服务（如帧中继永久虚拟电路（PVC）和ATM PVC）的仿真，在这里用于提供HC流量可以传输的单个点到点链路层跳的仿真。
Figure 1 illustrates an HC over MPLS channel established on an LSP that traverses several LSRs, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router performing HC, and R4/HD is the egress router performing header decompression (HD). This example assumes that the packet flow being compressed has RTP/UDP/IP headers and is using a HC scheme such as ROHC, CRTP, or ECRTP. Compression of the RTP/UDP/IP header is performed at R1/HC, and the compressed packets are routed using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD, without further decompression/recompression cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded to other routers, as needed. This example assumes that the application is VoIP and that the HC algorithm operates on the RTP, UDP, and IP headers of the VoIP flows. This is an extremely common application of HC, but need not be the only one. The HC algorithms supported by the protocol extensions specified in this document may operate on TCP or IPsec ESP headers as well.
图1说明了在LSP上建立的HC over MPLS通道，该LSP从R1/HC-->R2-->R3-->R4/HD穿过多个LSR，其中R1/HC是执行HC的入口路由器，R4/HD是执行报头解压缩（HD）的出口路由器。此示例假设正在压缩的数据包流具有RTP/UDP/IP报头，并且使用HC方案，如ROHC、CRTP或ECRTP。RTP/UDP/IP报头的压缩在R1/HC处执行，并且使用MPLS标签从R1/HC到R2、到R3、最后到R4/HD路由压缩包，而无需进一步的解压缩/再压缩循环。RTP/UDP/IP报头在R4/HD进行解压缩，并可根据需要转发到其他路由器。本例假设应用程序是VoIP，并且HC算法在VoIP流的RTP、UDP和IP头上运行。这是HC非常常见的应用，但不一定是唯一的应用。本文档中指定的协议扩展支持的HC算法也可以在TCP或IPsec ESP头上运行。
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R2 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R3 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R2 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
| R3 | Label Switching
|_____| (no compression/decompression)
|
| data (e.g., voice)/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
|
| data (e.g., voice)/RTP/UDP/IP/link layer
V
Figure 1: Example of HC over MPLS over Routers R1 --> R4
Figure 1: Example of HC over MPLS over Routers R1 --> R4
In the example scenario, HC therefore takes place between R1 and R4, and the MPLS LSP transports data/compressed-header/MPLS-labels instead of data/RTP/UDP/IP/MPLS-labels, often saving more than 90% of the RTP/UDP/IP overhead. Typically there are two MPLS labels (8 octets) and a link-layer HC control parameter (2 octets). The MPLS label stack and link-layer headers are not compressed. Therefore, HC over MPLS can significantly reduce the header overhead through compression mechanisms.
在示例场景中，HC因此发生在R1和R4之间，MPLS LSP传输数据/压缩头/MPLS标签，而不是数据/RTP/UDP/IP/MPLS标签，通常节省90%以上的RTP/UDP/IP开销。通常有两个MPLS标签（8个八位字节）和一个链路层HC控制参数（2个八位字节）。MPLS标签堆栈和链路层头不会被压缩。因此，HC over MPLS可以通过压缩机制显著降低报头开销。
HC reduces the IP/UDP/RTP headers to 2-4 bytes for most packets. Half of the reduction in header size comes from the observation that half of the bytes in the IP/UDP/RTP headers remain constant over the life of the flow. After sending the uncompressed header template once, these fields may be removed from the compressed headers that
HC将大多数数据包的IP/UDP/RTP报头减少到2-4字节。头大小减少一半是因为观察到IP/UDP/RTP头中的一半字节在流的生命周期内保持不变。在发送一次未压缩的头模板后，这些字段可能会从所发送的压缩头中删除
follow. The remaining compression comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant or at least limited, and therefore the second-order difference is zero.
跟随剩余的压缩来自以下观察：尽管每个数据包中有几个字段发生变化，但数据包之间的差异通常是恒定的或至少是有限的，因此二阶差异为零。
The compressor and decompressor both maintain a context for each compressed flow. The context is the session state shared between the compressor and decompressor. The details of what is included in the context may vary between HC schemes. The context at the compressor would typically include the uncompressed headers of the last packet sent on the flow, and some measure of the differences in selected header field values between the last packet transmitted and the packet(s) transmitted just before it. The context at the decompressor would include similar information about received packets. With this information, all that must be communicated across the wire is an indication of which flow a packet is associated with (the CID), and some compact encoding of the second order differences (i.e., the harder to predict differences) between packets.
压缩器和解压缩器都为每个压缩流维护一个上下文。上下文是压缩器和解压缩器之间共享的会话状态。上下文中包含的内容的细节可能因HC计划而异。压缩器处的上下文通常将包括在流上发送的最后一个分组的未压缩报头，以及所发送的最后一个分组和在其之前发送的分组之间的所选报头字段值的差异的一些度量。解压器处的上下文将包括关于接收到的数据包的类似信息。有了这些信息，所有必须通过导线进行通信的都是指示数据包与哪个流相关联（CID），以及数据包之间的二阶差异（即，更难预测的差异）的一些紧凑编码。
MPLS PWs [RFC3985] are used to transport the HC packets between the ingress and egress MPLS LSRs. Each PW acts like a logical point-to-point link between the compressor and the decompressor. Each PW supports a single HC channel, which, from the perspective of the HC scheme operation, is similar to a single PPP link or a single frame relay PVC. One exception to this general model is that PWs carry only packets with compressed headers, and do not share the PW with uncompressed packets.
MPLS PWs[RFC3985]用于在入口和出口MPLS LSR之间传输HC数据包。每个PW就像压缩机和减压器之间的逻辑点对点链路。每个PW支持单个HC信道，从HC方案操作的角度来看，该信道类似于单个PPP链路或单个帧中继PVC。这种通用模型的一个例外是，PW只携带带有压缩头的数据包，而不与未压缩的数据包共享PW。
The PW architecture specifies the use of a label stack with at least 2 levels. The label at the bottom of the stack is called the PW label. The PW label acts as an identifier for a particular PW. With HC PWs, the compressor adds the label at the bottom of the stack and the decompressor removes this label. No LSRs between the compressor and decompressor inspect or modify this label. Labels higher in the stack are called the packet switch network (PSN) labels, and are used to forward the packet through the MPLS network as described in [RFC3031]. The decompressor uses the incoming MPLS PW label (the label at the bottom of the stack), along with the CID to locate the proper decompression context. Standard HC methods (e.g., ECRTP, ROHC, etc.) are used to determine the contexts. The CIDs are assigned by the HC as normal, and there would be no problem if duplicate CIDs are received at the HD for different PWs, which support different compressed channels. For example, if two different compressors, HCa and HCb, both assign the same CID to each of 2 separate flows destined to decompressor HDc, HDc can still differentiate the flows and locate the proper decompression context for each, because the tuples <PWlabel-HCa, CID> and <PWlabel-HCb, CID> are still unique.
PW体系结构指定使用至少具有2个级别的标签堆栈。堆栈底部的标签称为PW标签。PW标签充当特定PW的标识符。对于HC PWs，压缩机在堆栈底部添加标签，而减压器移除该标签。压缩机和减压器之间无LSR检查或修改此标签。栈中较高的标签称为分组交换网络（PSN）标签，用于通过MPLS网络转发数据包，如[RFC3031]所述。解压器使用传入的MPLS PW标签（堆栈底部的标签）以及CID来定位正确的解压上下文。标准HC方法（如ECRTP、ROHC等）用于确定上下文。CID由HC正常分配，如果HD接收到支持不同压缩信道的不同PW的重复CID，则不会出现问题。例如，如果两个不同的压缩器（HCa和HCb）都将相同的CID分配给两个单独的流中的每一个，则HDc仍然可以区分这些流并为每个流定位适当的解压缩上下文，因为元组<PWlabel HCa，CID>和<PWlabel HCb，CID>仍然是唯一的。
In addition to the PW label and PSN label(s), HC over MPLS packets also carry a HC control parameter. The HC control parameter contains both a packet type field and a packet length field. The packet type field is needed because each HC scheme supported by this specification defines multiple packet types, for example, "full header" packets, which are used to initialize and/or re-synchronize the context between compressor and decompressor, vs. normal HC packets. And most of the HC schemes require that the underlying link layer protocols provide the differentiation between packet types. Similarly, one of the assumptions that is part of most of the HC schemes is that the packet length fields in the RTP/UDP/IP, etc. headers need not be explicitly sent across the network, because the IP datagram length can be implicitly determined from the lower layers. This specification assumes that, with one exception, the length of an HC IP datagram can be determined from the link layers of the packets transmitted across the MPLS network. The exception is for packets that traverse an Ethernet link. Ethernet requires padding for packets whose payload size is less than 46 bytes in length. So the HC control parameter contains a length field of 6 bits to encode the lengths of any HC packets less than 64 bytes in length.
除了PW标签和PSN标签外，HC over MPLS数据包还带有HC控制参数。HC控制参数包含数据包类型字段和数据包长度字段。需要数据包类型字段，因为本规范支持的每个HC方案定义了多个数据包类型，例如，“完整头”数据包，用于初始化和/或重新同步压缩器和解压缩器之间的上下文，而不是普通HC数据包。大多数HC方案要求底层链路层协议提供分组类型的区分。类似地，大多数HC方案的一个假设是RTP/UDP/IP等报头中的数据包长度字段不需要通过网络显式发送，因为IP数据报长度可以从较低层隐式确定。本规范假设，除了一个例外，HC-IP数据报的长度可以从通过MPLS网络传输的分组的链路层确定。例外情况是通过以太网链路的数据包。以太网要求对有效负载长度小于46字节的数据包进行填充。因此，HC控制参数包含一个6位的长度字段，用于编码长度小于64字节的任何HC数据包的长度。
HC PWs are set up by the PW signaling protocol [RFC4447]. [RFC4447] actually defines a set of extensions to the MPLS label distribution protocol (LDP) [RFC3036]. As defined in [RFC4447], LDP signaling to set up, tear down, and manage PWs is performed directly between the PW endpoints, in this case, the compressor and the decompressor. PW signaling is used only to set up the PW label at the bottom of the stack, and is used independently of any other signaling that may be used to set up PSN labels. So, for example, in Figure 1, LDP PW signaling would be performed directly between R1/HC and R4/HD. Router R2 and R3 would not participate in PW signaling.
HC PW由PW信令协议[RFC4447]设置。[RFC4447]实际上定义了MPLS标签分发协议（LDP）[RFC3036]的一组扩展。如[RFC4447]中所定义，设置、拆除和管理PWs的LDP信令直接在PW端点之间执行，在这种情况下，压缩机和减压器。PW信令仅用于在堆栈底部设置PW标签，并独立于可用于设置PSN标签的任何其他信令使用。因此，例如，在图1中，LDP PW信令将直接在R1/HC和R4/HD之间执行。路由器R2和R3不会参与PW信令。
[RFC4447] provides extensions to LDP for PWs, and this document provides further extensions specific to HC. Since PWs provide a logical point-to-point connection over which HC can be run, the extensions specified in this document reuse elements of the protocols used to negotiate HC over the Point-to-Point Protocol [RFC1661]. [RFC3241] specifies how ROHC is used over PPP and [RFC3544] specifies how several other HC schemes (CRTP, ECRTP, IPHC) are used over PPP. Both of these RFCs provide configuration options for negotiating HC over PPP. The formats of these configuration options are reused here for setting up HC over PWs. When used in the PPP environment, these configuration options are used as extensions to PPP's IP Control Protocol [RFC1332] and the detailed PPP options negotiations process described in [RFC1661]. This is necessary because a PPP link may support multiple protocols, each with its own addressing scheme and options. Achieving interoperability requires a negotiation process
[RFC4447]提供了针对PWs的LDP扩展，本文档提供了针对HC的进一步扩展。由于PWs提供了一个逻辑点对点连接，HC可以在该连接上运行，因此本文档中指定的扩展重用了用于通过点对点协议协商HC的协议元素[RFC1661]。[RFC3241]指定如何在PPP上使用ROHC，[RFC3544]指定如何在PPP上使用其他几种HC方案（CRTP、ECRTP、IPHC）。为这两种PPP配置提供RFHC协商选项。这些配置选项的格式在此处重复使用，用于在PWs上设置HC。在PPP环境中使用时，这些配置选项用作PPP的IP控制协议[RFC1332]和[RFC1661]中描述的详细PPP选项协商过程的扩展。这是必要的，因为PPP链路可能支持多个协议，每个协议都有自己的寻址方案和选项。实现互操作性需要一个协商过程
so that the nodes at each end of the link can agree on a set of protocols and options that both support. However, a single HC PW supports only HC traffic using a single HC scheme. So while the formats of configuration options from [RFC3241] and [RFC3544] are reused here, the detailed PPP negotiation process is not. Instead, these options are reused here just as descriptors (TLVs in the specific terminology of LDP and [RFC4447]) of basic parameters of an HC PW. These parameters are further described in Section 4. The HC configuration parameters are initially generated by the decompressor and describe what the decompressor is prepared to receive.
这样，链路两端的节点就可以在一组双方都支持的协议和选项上达成一致。但是，单个HC PW仅支持使用单个HC方案的HC流量。因此，尽管[RFC3241]和[RFC3544]中的配置选项的格式在这里被重用，但详细的PPP协商过程并不是这样。相反，这些选项在这里被重用为HC PW基本参数的描述符（LDP和[RFC4447]中的TLV）。这些参数将在第4节中进一步说明。HC配置参数最初由减压器生成，并描述减压器准备接收的内容。
Most HC schemes use a feedback mechanism which requires bi-directional flow of HC packets, even if the flow of compressed IP packets is in one direction only. The basic signaling process of [RFC4447] sets up unidirectional PWs, and must be repeated in each direction in order to set up the bi-directional flow needed for HC.
大多数HC方案使用反馈机制，该机制要求HC分组的双向流，即使压缩IP分组的流仅在一个方向上。[RFC4447]的基本信号流程设置单向PWs，并且必须在每个方向重复，以便设置HC所需的双向流。
Figure 1 illustrates an example data flow set up from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header compression is performed, and R4/HD is the egress router where header decompression is done. Each router functions as an LSR and supports signaling of LSP/PWs. See Section 5 for a detailed example of how the flow depicted in Figure 1 is established.
图1说明了从R1/HC-->R2-->R3-->R4/HD设置的示例数据流，其中R1/HC是执行报头压缩的入口路由器，R4/HD是执行报头解压缩的出口路由器。每个路由器作为LSR工作，并支持LSP/PWs的信令。关于如何建立图1所示流程的详细示例，请参见第5节。
All the HC schemes used here are built so that if an uncompressible packet is seen, it should just be sent uncompressed. For some types of compression (e.g., IPHC-TCP), a non-compressed path is required. For IPHC-TCP compression, uncompressible packets occur for every TCP flow. Another way that this kind of issue can occur is if MAX_HEADER is configured lower than the longest header, in which case, compression might not be possible in some cases.
这里使用的所有HC方案都是这样构建的，如果看到不可压缩的数据包，它应该只是被不压缩地发送。对于某些类型的压缩（例如IPHC-TCP），需要非压缩路径。对于IPHC-TCP压缩，每个TCP流都会出现不可压缩的数据包。发生此类问题的另一种方式是，如果MAX_头的配置低于最长头，在这种情况下，在某些情况下可能无法进行压缩。
The uncompressed packets associated with HC flows (e.g., uncompressed IPHC-TCP packets) can be sent through the same MPLS tunnel along with all other non-HC (non-PW) IP packets. MPLS tunnels can transport many types of packets simultaneously, including non-PW IP packets, layer 3 VPN packets, and PW (e.g., HC flow) packets. In the specification, we assume that there is a path for uncompressed traffic, and it is a compressor decision as to what would or would not go in the HC-PW.
与HC流相关联的未压缩分组（例如，未压缩的IPHC-TCP分组）可以与所有其他非HC（非PW）IP分组一起通过相同的MPLS隧道发送。MPLS隧道可以同时传输多种类型的数据包，包括非PW IP数据包、第3层VPN数据包和PW（例如HC流）数据包。在规范中，我们假设存在未压缩流量的路径，这是关于HC-PW中会出现什么或不会出现什么的压缩决策。
Figure 2 illustrates the PW stack reference model to support PW emulated services.
图2说明了支持PW模拟服务的PW堆栈参考模型。
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | | Emulated |
| Services | Emulated Service | Services |
| |<==============================>| |
+-------------+ +-------------+
| HC | Pseudowire | HD |
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | | Emulated |
| Services | Emulated Service | Services |
| |<==============================>| |
+-------------+ +-------------+
| HC | Pseudowire | HD |
|Demultiplexer|<==============================>|Demultiplexer|
+-------------+ +-------------+
| PSN | PSN Tunnel | PSN |
| MPLS |<==============================>| MPLS |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
Figure 2: Pseudowire Protocol Stack Reference Model
图2:Pseudowire协议栈参考模型
Each HC-HD compressed channel is mapped to a single PW and associated with 2 PW labels, one in each direction. A single PW label MUST be used for many HC flows (could be 100's or 1000's) rather than assigning a different PW label to each flow. The latter approach would involve a complex mechanism for PW label assignment, freeing up of labels after a flow terminates, etc., for potentially 1000's of simultaneous HC flows. On the other hand, the mechanism for CID assignment, freeing up, etc., is in place and there is no need to duplicate it with PW assignment/deassignment for individual HC flows.
每个HC-HD压缩通道映射到单个PW，并与两个PW标签关联，每个方向一个。许多HC流（可能为100或1000）必须使用单个PW标签，而不是为每个流指定不同的PW标签。后一种方法将涉及一种复杂的PW标签分配机制，在流终止后释放标签等，用于可能1000的同时HC流。另一方面，CID分配、释放等机制已到位，无需将其与单个HC流的PW分配/解除分配重复。
Multiple PWs SHOULD be established in case different quality of service (QoS) requirements are needed for different compressed streams. The QoS received by the flow would be determined by the EXP bit marking in the PW label. Normally, all RTP packets would get the same EXP marking [RFC3270], equivalent to expedited forwarding (EF) treatment [RFC3246] in Diffserv. However, the protocol specified in this document applies to several different types of streams, not just RTP streams, and QoS treatment other than EF may be required for those streams.
如果不同的压缩流需要不同的服务质量（QoS）要求，则应建立多个PWs。流接收的QoS将由PW标签中的EXP位标记确定。通常，所有RTP数据包都将获得相同的EXP标记[RFC3270]，相当于Diffserv中的加速转发（EF）处理[RFC3246]。然而，本文件中规定的协议适用于几种不同类型的流，而不仅仅是RTP流，并且这些流可能需要EF以外的QoS处理。
Figure 3 shows the HC over MPLS protocol stack (with uncompressed header):
图3显示了HC over MPLS协议栈（具有未压缩的头）：
Media stream RTP UDP IP HC control parameter MPLS label stack (at least 2 labels for this application) Link layer under MPLS (PPP, PoS, Ethernet) Physical layer (SONET/SDH, fiber, copper)
媒体流RTP UDP IP HC控制参数MPLS标签堆栈（此应用程序至少有2个标签）MPLS（PPP、PoS、以太网）物理层（SONET/SDH、光纤、铜缆）下的链路层
+--------------+
| Media stream |
+--------------+
\_______ ______/
2-4 octets V
+------+--------------+
Compressed /RTP/UDP/IP/ |header| |
+------+--------------+
\__________ __________/
2 octets V
+------+---------------------+
HC Control Parameter |header| |
+------+---------------------+
\______________ _____________/
8 octets V
+------+----------------------------+
MPLS Labels |header| |
+------+----------------------------+
\_________________ _________________/
V
+------------------------------------------+
Link Layer under MPLS | |
+------------------------------------------+
\____________________ _____________________/
V
+-------------------------------------------------+
Physical Layer | |
+-------------------------------------------------+
+--------------+
| Media stream |
+--------------+
\_______ ______/
2-4 octets V
+------+--------------+
Compressed /RTP/UDP/IP/ |header| |
+------+--------------+
\__________ __________/
2 octets V
+------+---------------------+
HC Control Parameter |header| |
+------+---------------------+
\______________ _____________/
8 octets V
+------+----------------------------+
MPLS Labels |header| |
+------+----------------------------+
\_________________ _________________/
V
+------------------------------------------+
Link Layer under MPLS | |
+------------------------------------------+
\____________________ _____________________/
V
+-------------------------------------------------+
Physical Layer | |
+-------------------------------------------------+
Figure 3: Header Compression over MPLS Media Stream Transport
图3:MPLS媒体流传输上的报头压缩
The HC control parameter MUST be used to identify the packet types for the HC scheme in use. The MPLS labels technically define two layers: the PW identifier and the MPLS tunnel identifier. The PW label MUST be used as the demultiplexer field by the HD, where the PW label appears at the bottom label of an MPLS label stack. The LSR that will be performing decompression MUST ensure that the label it distributes (e.g., via LDP) for a channel is unique. There can also
HC控制参数必须用于识别正在使用的HC方案的数据包类型。MPLS标签在技术上定义了两层：PW标识符和MPLS隧道标识符。PW标签必须由HD用作解复用器字段，其中PW标签出现在MPLS标签堆栈的底部标签上。将执行解压缩的LSR必须确保其为信道分发的标签（例如，通过LDP）是唯一的。也可以
be other MPLS labels, for example, to identify an MPLS VPN. The IP/UDP/RTP headers are compressed before transmission, leaving the rest of the stack alone, as shown in Figure 3.
例如，可以使用其他MPLS标签来标识MPLS VPN。IP/UDP/RTP报头在传输之前被压缩，剩下的堆栈就剩下了，如图3所示。
PWs MUST be set up in advance for the transport of media streams using [RFC4447] control messages exchanged by the HC-HD endpoints. Furthermore, a PW type MUST be used to indicate the HC scheme being used on the PW. [RFC4447] specifies the MPLS label distribution protocol (LDP) [RFC3036] extensions to set up and maintain the PWs, and defines new LDP objects to identify and signal attributes of PWs. Any acceptable method of MPLS label distribution MAY be used for distributing the MPLS tunnel label [RFC3031]. These methods include LDP [RFC3036], RSVP-TE [RFC3209], or configuration.
必须提前设置PWs，以便使用HC-HD端点交换的[RFC4447]控制消息传输媒体流。此外，必须使用PW类型来指示PW上使用的HC方案。[RFC4447]指定用于设置和维护PWs的MPLS标签分发协议（LDP）[RFC3036]扩展，并定义新的LDP对象以识别PWs的属性并向其发送信号。任何可接受的MPLS标签分发方法均可用于分发MPLS隧道标签[RFC3031]。这些方法包括LDP[RFC3036]、RSVP-TE[RFC3209]或配置。
To assign and distribute the PW labels, an LDP session MUST be set up between the PW endpoints using the extended discovery mechanism described in [RFC3036]. The PW label bindings are distributed using the LDP downstream unsolicited mode described in [RFC3036]. An LDP label mapping message contains a FEC object, a label object, and possible other optional objects. The FEC object indicates the meaning of the label, identifies the PW type, and identifies the PW that the PW label is bound to. See [RFC4447] for further explanation of PW signaling.
要分配和分发PW标签，必须使用[RFC3036]中描述的扩展发现机制在PW端点之间建立LDP会话。PW标签绑定使用[RFC3036]中所述的LDP下游非请求模式分发。LDP标签映射消息包含FEC对象、标签对象和可能的其他可选对象。FEC对象指示标签的含义，标识PW类型，并标识PW标签绑定到的PW。有关PW信令的进一步说明，请参见[RFC4447]。
This specification defines new PW type values to be carried within the FEC object to identify HC PWs for each HC scheme. The PW type is a 15-bit parameter assigned by IANA, as specified in the [RFC4446] registry, and MUST be used to indicate the HC scheme being used on the PW. IANA has set aside the following PW type values for assignment according to the registry specified in RFC 4446, Section 3.2:
本规范定义了在FEC对象内携带的新PW类型值，以识别每个HC方案的HC PW。PW类型是由IANA分配的15位参数，如[RFC4446]注册表中所指定，必须用于指示PW上使用的HC方案。IANA已根据RFC 4446第3.2节规定的注册表留出以下PW类型值进行分配：
PW type Description Reference
=============================================================
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]
PW type Description Reference
=============================================================
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]
The HC control parameter enables distinguishing between various packets types (e.g., uncompressed, UDP compressed, RTP compressed, context-state, etc.). However, the HC control parameter indications are not unique across HC schemes, and therefore the PW type value allows the HC scheme to be identified.
HC控制参数能够区分各种数据包类型（例如，未压缩、UDP压缩、RTP压缩、上下文状态等）。然而，HC控制参数指示在HC方案中不是唯一的，因此PW类型值允许识别HC方案。
As described in the previous section, the HC PW MUST be used for compressed packets only, which is configured at PW setup. If a flow is not compressed, it MUST NOT be placed on the HC PW. HC PWs MUST be bi-directional, which means that a unidirectional leg of the PW MUST be set up in each direction. One leg of the bi-directional PW MAY be set up to carry only compression feedback, not header compressed traffic. The same PW type MUST be used for PW signaling in both directions.
如前一节所述，HC PW必须仅用于在PW设置时配置的压缩数据包。如果流量未被压缩，则不得将其置于HC PW上。HC PW必须是双向的，这意味着必须在每个方向上设置PW的单向支腿。双向PW的一个分支可以设置为仅承载压缩反馈，而不承载报头压缩的业务。两个方向的PW信号必须使用相同的PW类型。
HC scheme parameters MAY be manually configured, but if so, manual configuration MUST be done in both directions. If HC scheme parameters are signaled, the Interface Parameters Sub-TLV MUST be used on any unidirectional legs of a PW that will carry HC traffic. For a unidirectional leg of a PW that will carry only compression feedback, the components of the Interface Parameters Sub-TLV described below are not relevant and MUST NOT be used.
HC方案参数可以手动配置，但如果是，则必须在两个方向上进行手动配置。如果发送HC方案参数信号，则接口参数Sub-TLV必须用于将承载HC流量的PW的任何单向分支。对于仅承载压缩反馈的PW单向支腿，下文所述接口参数Sub-TLV的组件不相关，不得使用。
The PW HC approach relies on the PW/MPLS layer to convey HC channel configuration information. The Interface Parameters Sub-TLV [IANA, RFC4447] must be used to signal HC channel setup and specify HC parameters. That is, the configuration options specified in [RFC3241, RFC3544] are reused in this specification to specify PW-specific parameters, and to configure the HC and HD ports at the edges of the PW so that they have the necessary capabilities to interoperate with each other.
PW-HC方法依赖于PW/MPLS层来传送HC信道配置信息。接口参数子TLV[IANA，RFC4447]必须用于向HC通道设置发送信号并指定HC参数。也就是说，[RFC3241，RFC3544]中规定的配置选项在本规范中重复使用，以指定特定于PW的参数，并配置PW边缘的HC和HD端口，以便它们具有相互操作的必要能力。
Pseudowire Interface Parameter Sub-TLV type values are specified in [RFC4446]. IANA has set aside the following Pseudowire Interface Parameter Sub-TLV type values according to the registry specified in RFC 4446, Section 3.3:
[RFC4446]中规定了伪线接口参数子TLV类型值。IANA已根据RFC 4446第3.3节规定的注册表，留出以下伪导线接口参数子TLV类型值：
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544
TLVs identified in [RFC3241] and [RFC3544] MUST be encapsulated in the PW Interface Parameters Sub-TLV and used to negotiate header compression session setup and parameter negotiation for their respective protocols. The TLVs supported in this manner MUST include the following:
[RFC3241]和[RFC3544]中标识的TLV必须封装在PW接口参数子TLV中，并用于协商各自协议的报头压缩会话设置和参数协商。以这种方式支持的TLV必须包括以下内容：
o Configuration Option Format, RTP-Compression Suboption, Enhanced RTP-Compression Suboption, TCP/non-TCP Compression Suboptions, as specified in [RFC3544]
o [RFC3544]中规定的配置选项格式、RTP压缩子选项、增强RTP压缩子选项、TCP/非TCP压缩子选项
o Configuration Option Format, PROFILES Suboption, as specified in [RFC3241]
o [RFC3241]中规定的配置选项格式、配置文件子选项
These TLVs are now specified in the following sections.
这些TLV现在在以下章节中指定。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 Network Control Protocol (NCP), IPV6CP [RFC2472] may be used to negotiate IP HC parameters for their respective controlled protocols. The format of the configuration option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ECRTP, CRTP and IPHC PW types and MUST NOT be included for ROHC PW types. A decompressor MUST reject this option (if misconfigured) for ROHC PW types and send an explicit error message to the compressor [RFC3544].
IPv4网络控制协议、IPCP[RFC1332]和IPv6网络控制协议（NCP）、IPV6CP[RFC2472]都可用于协商各自控制协议的IP HC参数。IPCP和IPV6CP的配置选项格式相同。此配置选项必须包括在ECRTP、CRTP和IPHC PW类型中，不得包括在ROHC PW类型中。解压器必须拒绝ROHC PW类型的此选项（如果配置错误），并向压缩器发送明确的错误消息[RFC3544]。
Description
描述
This NCP configuration option is used to negotiate parameters for IP HC. 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 HC的参数。成功协商参数可以使用[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). This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
TCP_空间必须至少为0，最多为255（值0表示有一个上下文）。此字段不用于CRTP（PW类型0x001B）和ECRTP（PW类型0x001B）PWs。对于这些PW类型，发送方应将其设置为建议值，接收方应忽略。
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. This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
值为零意味着无穷大，即，连续压缩的非TCP头的数量没有限制。此字段不用于CRTP（PW类型0x001B）和ECRTP（PW类型0x001B）PWs。对于这些PW类型，发送方应将其设置为建议值，接收方应忽略。
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. This field is not used for CRTP (PW type 0x001B) and ECRTP (PW type 0x001B) PWs. For these PW types, it should be set to its suggested value by the sender and ignored by the receiver.
值为零意味着无穷大。此字段不用于CRTP（PW类型0x001B）和ECRTP（PW类型0x001B）PWs。对于这些PW类型，发送方应将其设置为建议值，接收方应忽略。
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. This suboption MUST be included for CRTP PWs (0x001C) and MUST NOT be included for other PW types.
如果要启用IP/UDP/RTP压缩，则IPHC的NCP IP压缩协议选项中包含RTP压缩子选项。此子选项必须包含在CRTP PWs（0x001C）中，不得包含在其他PW类型中。
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
描述
Enables the 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 HC defined in [RFC3545], a new suboption 2 is added. Suboption 2 is negotiated instead of, not in addition to, suboption 1. This suboption MUST be included for ECRTP PWs (0x001B) and MUST NOT be included for other PW types.
为了使用[RFC3545]中定义的增强型RTP HC，添加了一个子选项2。协商子方案2，而不是子方案1。此子选项必须包含在ECRTP PWs（0x001B）中，不得包含在其他PW类型中。
Note that suboption 1 refers to the RTP-Compression Suboption, as specified in Section 4.2.2, and suboption 2 refers to the Enhanced RTP-Compression Suboption, as specified in Section 4.2.3. These suboptions MUST NOT occur together. If they do (e.g., if misconfigured), a decompressor MUST reject this option and send an explicit error message to the compressor [RFC3544].
请注意，子选项1指第4.2.2节规定的RTP压缩子选项，子选项2指第4.2.3节规定的增强RTP压缩子选项。这些子选项不能同时出现。如果确实如此（例如，如果配置错误），解压缩程序必须拒绝此选项，并向压缩机发送明确的错误消息[RFC3544]。
Description
描述
Enables the use of Protocol Identifiers COMPRESSED_RTP and CONTEXT_STATE as specified in [RFC2508]. In addition, it enables the 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
4.2.4. Negotiating Header Compression for Only TCP or Only Non-TCP Packets [RFC3544]
4.2.4. 仅针对TCP或仅针对非TCP数据包协商标头压缩[RFC3544]
In [RFC3544] it was not possible to negotiate only TCP HC or only non-TCP HC because a value of 0 in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 context is negotiated.
在[RFC3544]中，无法仅协商TCP HC或仅协商非TCP HC，因为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. This suboption MUST be included for IPHC PWs (0x001C) and MUST NOT be included for other PW types.
添加了新的子选项3，以允许指定TCP_空间或非TCP_空间的上下文数为零，从而禁用相应压缩的使用。此子选项必须包含在IPHC PWs（0x001C）中，不得包含在其他PW类型中。
Description
描述
Enable HC for only TCP or only non-TCP packets.
仅为TCP或非TCP数据包启用HC。
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 HC option.
此子选项覆盖以前在IP HC选项中分配给TCP_空间和非TCP_空间的值。
If suboption 3 is included multiple times with parameter 1 and 2, compression is disabled for all packets.
如果子选项3多次包含参数1和2，则对所有数据包禁用压缩。
Both the network control protocol for IPv4, IPCP [RFC1332] and the IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP HC parameters for their respective controlled protocols. The format of the configuration option is the same for both IPCP and IPV6CP. This configuration option MUST be included for ROHC PW types and MUST NOT be included for ECRTP, CRTP, and IPHC PW types. A decompressor MUST reject this option (if misconfigured) for ECRTP, CRTP, and IPHC PW types, and send an explicit error message to the compressor [RFC3544].
IPv4、IPCP[RFC1332]和IPv6 NCP、IPV6CP[RFC2472]的网络控制协议均可用于协商各自控制协议的IP HC参数。IPCP和IPV6CP的配置选项格式相同。此配置选项必须包含在ROHC PW类型中，不得包含在ECRTP、CRTP和IPHC PW类型中。对于ECRTP、CRTP和IPHC PW类型，解压缩程序必须拒绝此选项（如果配置错误），并向压缩机发送明确的错误消息[RFC3544]。
Description
描述
This NCP configuration option is used to negotiate parameters for ROHC. The option format is summarized below. The fields are transmitted from left to right.
此NCP配置选项用于协商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 [RFC3095bis], Section 5.1.2).
MRRU MRRU字段为两个八位字节，表示最大重构接收单元（见[RFC3095bis]，第5.1.2节）。
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 because the maximum compressible header size is unspecified. 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.
子选项“子选项”字段由零个或多个子选项组成。每个子选项由一个类型字段、一个长度字段和零个或多个参数八位字节组成，如子选项类型所定义。长度字段的值指示子选项的整个长度，包括类型字段和长度字段的长度。
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.
定义解压缩程序支持的配置文件集。
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配置文件。
HC flow identification is being done now in many ways. Since there are multiple possible approaches to the problem, no specific method is specified in this document.
HC流量识别目前正在以多种方式进行。由于该问题有多种可能的解决方法，因此本文档中未指定具体方法。
The HC control parameter is used to identify the packet types for IPHC [RFC2507], CRTP [RFC2508], and ECRTP [RFC3545], as shown in Figure 4:
HC控制参数用于识别IPHC[RFC2507]、CRTP[RFC2508]和ECRTP[RFC3545]的数据包类型，如图4所示：
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|Pkt Typ| Length |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|Pkt Typ| Length |Res|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HC Control Parameter
图4:HC控制参数
where:
哪里：
"Packet Type" encoding: 0: ROHC Small-CIDs 1: ROHC Large-CIDs 2: FULL_HEADER 3: COMPRESSED_TCP 4: COMPRESSED_TCP_NODELTA 5: COMPRESSED_NON_TCP 6: COMPRESSED_RTP_8 7: COMPRESSED_RTP_16 8: COMPRESSED_UDP_8 9: COMPRESSED_UDP_16 10: CONTEXT_STATE
“数据包类型”编码：0:ROHC小型CIDs 1:ROHC大型CIDs 2:FULL_头3:COMPRESSED_TCP 4:COMPRESSED_TCP_NodeTa 5:COMPRESSED_NON_TCP 6:COMPRESSED_RTP_8 7:COMPRESSED_RTP_16 8:COMPRESSED_UDP_8 9:COMPRESSED__UDP_16 10:CONTEXT_状态
11-15: Not yet assigned. (See Section 8, "IANA Considerations", for discussion of the registration rules.)
11-15：尚未分配。（有关注册规则的讨论，请参见第8节“IANA注意事项”。）
As discussed in [ECMP-AVOID], since this MPLS payload type is not IP, the first nibble is set to 0000 to avoid being mistaken for IP. This is also consistent with the encoding of the PW MPLS control word (PWMCW) described in [RFC4385]; however, the HC control parameter is not intended to be a PWMCW.
如[ECMP-AVOIVE]中所述，由于此MPLS有效负载类型不是IP，因此将第一个半字节设置为0000以避免误认为IP。这也与[RFC4385]中描述的PW MPLS控制字（PWMCW）的编码一致；但是，HC控制参数并非用于PWMCW。
Note that ROHC [RFC3095, RFC3095bis] provides its own packet type within the protocol; however, the HC control parameter MUST still be used to avoid the problems identified above. Since the "Packet Type" will be there anyway, it is used to indicate ROHC CID size, in the same way as with PPP.
注意，ROHC[RFC3095，RFC3095bis]在协议中提供了自己的数据包类型；但是，仍然必须使用HC控制参数以避免上述问题。由于“数据包类型”无论如何都会存在，因此它用于指示ROHC CID大小，与PPP的方式相同。
The HC control parameter length field is ONLY used for short packets because padding may be appended by the Ethernet Data Link Layer. If the length is greater than or equal to 64 octets, the length field MUST be set to zero. If the MPLS payload is less than 64 bytes, then the length field MUST be set to the length of the PW payload plus the length of the HC control parameter. Note that the last 2 bits in the HC control parameter are reserved.
HC控制参数长度字段仅用于短数据包，因为填充可以由以太网数据链路层附加。如果长度大于或等于64个八位字节，则长度字段必须设置为零。如果MPLS有效负载小于64字节，则长度字段必须设置为PW有效负载的长度加上HC控制参数的长度。请注意，HC控制参数中的最后2位是保留的。
Packet reordering for ROHC is discussed in [RFC4224], which is a useful source of information. In case of lossy links and other reasons for reordering, implementation adaptations are needed to allow all the schemes to be used in this case. Although CRTP is viewed as having risks for a number of PW environments due to reordering and loss, it is still the protocol of choice in many cases. CRTP was designed for reliable point to point links with short delays. It does not perform well over links with a high rate of packet loss, packet reordering, and long delays. In such cases, ECRTP [RFC3545] may be considered to increase robustness to both packet loss and misordering between the compressor and the decompressor. This is achieved by repeating updates and sending of absolute (uncompressed) values in addition to delta values for selected context parameters. IPHC should use TCP_NODELTA, ECRTP should send absolute values, ROHC should be adapted as discussed in [RFC4224]. An evaluation and simulation of ECRTP and ROHC reordering is given in [REORDER-EVAL].
[RFC4224]中讨论了ROHC的数据包重新排序，这是一个有用的信息源。在有损链路和其他原因导致重新排序的情况下，需要进行实现调整，以允许在这种情况下使用所有方案。尽管CRTP被视为由于重新排序和丢失而对许多PW环境具有风险，但在许多情况下它仍然是首选协议。CRTP设计用于具有短延迟的可靠点对点链路。它在数据包丢失率高、数据包重新排序和长延迟的链路上性能不佳。在这种情况下，可以认为ECRTP[RFC3545]增加了对压缩器和解压缩器之间的分组丢失和误序的鲁棒性。这是通过重复更新和发送绝对（未压缩）值以及选定上下文参数的增量值来实现的。IPHC应使用TCP_NODELTA，ECRTP应发送绝对值，ROHC应按照[RFC4224]中的讨论进行调整。[REORDER-EVAL]中给出了ECRTP和ROHC重新排序的评估和模拟。
This example will trace the setup of an MPLS PW supporting bi-directional ECRTP [RFC3545] traffic. The example assumes the topology shown in Figure 1. The PW will be set up between LSRs R1/HC and R4/HD. LSRs R2 and R3 have no direct involvement in the signaling for this PW, other than to transport the signaling traffic.
此示例将跟踪支持双向ECRTP[RFC3545]通信的MPLS PW的设置。该示例假设拓扑如图1所示。PW将设置在LSR R1/HC和R4/HD之间。LSR R2和R3不直接参与此PW的信令，只是用于传输信令业务。
For this example, it is assumed that R1/HC has already obtained the IP address of R4/HD used for LDP signaling, and vice versa, that both R1/HC and R4/HD have been configured with the same 32-bit PW ID, as described in Section 5.2 of [RFC4447], and that R1/HC has been configured to initiate the LDP discovery process. Furthermore, we assume that R1/HC has been configured to receive a maximum of 200 simultaneous ECRTP flows from R4/HD, and R4/HD has been configured to receive a maximum of 255 ECRTP flows from R1/HC.
对于该示例，假设R1/HC已经获得了用于LDP信令的R4/HD的IP地址，反之亦然，R1/HC和R4/HD都配置了相同的32位PW ID，如[RFC4447]第5.2节所述，并且R1/HC已经配置为启动LDP发现过程。此外，我们假设R1/HC已配置为从R4/HD同时接收最多200个ECRTP流，并且R4/HD已配置为从R1/HC接收最多255个ECRTP流。
Assuming that there is no existing LDP session between R1/HC and R4/HD, the PW signaling must start by setting up an LDP session between them. As described earlier in this document, LDP extended discovery is used between HC over MPLS LSRs. Since R1/HC has been configured to initiate extended discovery, it will send LDP Targeted Hello messages to R4/HD's IP address at UDP port 646. The Targeted Hello messages sent by R1/HC will have the "R" bit set in the Common Hello Parameters TLV, requesting R4/HD to send Targeted Hello messages back to R1/HC. Since R4/HD has been configured to set up an HC PW with R1/HD, R4/HD will do as requested and send LDP Targeted Hello messages as unicast UDP packets to UDP port 646 of R1/HC's IP address.
假设R1/HC和R4/HD之间不存在LDP会话，PW信令必须通过在它们之间建立LDP会话来启动。如本文档前面所述，在HC over MPLS LSR之间使用LDP扩展发现。由于R1/HC已配置为启动扩展发现，它将向UDP端口646处的R4/HD的IP地址发送LDP目标Hello消息。R1/HC发送的目标Hello消息将在公共Hello参数TLV中设置“R”位，请求R4/HD将目标Hello消息发送回R1/HC。由于R4/HD已配置为使用R1/HD设置HC PW，因此R4/HD将按照请求执行，并将LDP目标Hello消息作为单播UDP数据包发送到R1/HC IP地址的UDP端口646。
When R1/HC receives a Targeted Hello message from R4/HD, it may begin establishing an LDP session to R4/HD. It starts this by initiating a TCP connection on port 646 to R4/HD's signaling IP address. After successful TCP connection establishment, R1/HC sends an LDP Initialization message to R4/HD with the following characteristics:
当R1/HC从R4/HD接收到目标Hello消息时，它可以开始建立到R4/HD的LDP会话。它通过在端口646上启动到R4/HD的信令IP地址的TCP连接来启动。成功建立TCP连接后，R1/HC向R4/HD发送LDP初始化消息，具有以下特征：
When R1/HC receives a Targeted Hello message from R4/HD, it may begin establishing an LDP session to R4/HD. The procedure described in Section 2.5.2 of [RFC3036] is used to determine which LSR is the active LSR and which is the passive LSR. Assume that R1/HC has the numerically higher IP address and therefore takes the active role. R1/HC starts by initiating a TCP connection on port 646 to R4/HD's signaling IP address. After successful TCP connection establishment, R1/HC sends an LDP Initialization message to R4/HD with the following characteristics:
当R1/HC从R4/HD接收到目标Hello消息时，它可以开始建立到R4/HD的LDP会话。[RFC3036]第2.5.2节中描述的程序用于确定哪个LSR是主动LSR，哪个是被动LSR。假设R1/HC具有数字较高的IP地址，因此担任主动角色。R1/HC通过在端口646上启动到R4/HD的信令IP地址的TCP连接启动。成功建立TCP连接后，R1/HC向R4/HD发送LDP初始化消息，具有以下特征：
o Common Session Parameters TLV: - A bit = 0 (Downstream Unsolicited Mode) - D bit = 0 (Loop Detection Disabled) - PVLim = 0 (required when D bit = 0) - Receive LDP identifier (taken from R4/HD's Hello message) > 4 octets LSR identifier (typically an IP address with IPv4) > 2 octet Label space identifier (typically 0) o No Optional Parameters TLV
o 公共会话参数TLV:-A位=0（下游非请求模式）-D位=0（禁用环路检测）-PVLim=0（当D位=0时需要）-接收LDP标识符（取自R4/HD的Hello消息）>4个八位LSR标识符（通常为IPv4的IP地址）>2个八位标签空间标识符（通常为0）o无可选参数TLV
Following the LDP session initialization state machine of Section 2.5.4 of [RFC3036], R4/HD would send a similar Initialization message to R1/HD. The primary difference would be that R4/HD would use the LDP identifier it received in R1/HC's Hello message(s) as the Receive LDP identifier. Assuming that all other fields in the Common Session Parameters TLV were acceptable to both sides, R1/HC would send an LDP Keepalive message to R4/HD, R4/HD would send a LDP Keepalive message to R1/HC, and the LDP session would become operational.
在[RFC3036]第2.5.4节的LDP会话初始化状态机之后，R4/HD将向R1/HD发送类似的初始化消息。主要区别在于R4/HD将使用它在R1/HC的Hello消息中接收到的LDP标识符作为接收LDP标识符。假设公共会话参数TLV中的所有其他字段都为双方所接受，R1/HC将向R4/HD发送LDP Keepalive消息，R4/HD将向R1/HC发送LDP Keepalive消息，LDP会话将开始工作。
At this point, either R1/HC or R4/HD may send LDP Label Mapping messages to configure the PW. The Label Mapping message sent by a particular router advertises the label that should be used at the bottom of the MPLS label stack for all packets sent to that router and associated with the particular PW. The Label Mapping message sent from R1/HC to R4/HD would have the following characteristics:
此时，R1/HC或R4/HD可以发送LDP标签映射消息来配置PW。特定路由器发送的标签映射消息播发应在MPLS标签堆栈底部用于发送到该路由器并与特定PW关联的所有数据包的标签。从R1/HC发送到R4/HD的标签映射消息将具有以下特征：
o FEC TLV - FEC Element type 0x80 (PWid FEC Element, as defined in [RFC4447] - Control Parameter bit = 1 (Control Parameter present) - PW type = 0x001B (ECRTP [RFC3545]) - Group ID as chosen by R1/HC - PW ID = the configured value for this PW, which must be the same as that sent in the Label Mapping message by R4/HD - Interface Parameter Sub-TLVs > Interface MTU sub-TLV (Type 0x01) > CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV (Type 0x0F) + Type = 2 (From RFC 3544) + Length = 16 + TCP_SPACE = Don't Care (leave at suggested value = 15) + NON_TCP_SPACE = 200 (configured on R1) + F_MAX_PERIOD = Don't Care (leave at suggested value = 256) + F_MAX_TIME = Don't Care (leave at suggested value = 5 seconds) + MAX_HEADER = 168 (Suggested Value) + Enhanced RTP-Compression Suboption & Type = 2 & Length = 2 o Label TLV - contains label selected by R1, Lr1 o No Optional Parameters
o FEC TLV-FEC元件类型0x80（PWid FEC元件，如[RFC4447]中所定义）-控制参数位=1（存在控制参数）-PW类型=0x001B（ECRTP[RFC3545]）-由R1/HC选择的组ID-PW ID=此PW的配置值，必须与R4/HD在标签映射消息中发送的值相同-接口参数子TLV>接口MTU子TLV（类型0x01）>CRTP/ECRTP/IPHC over MPLS配置子TLV（类型0x0F）+类型=2（来自RFC 3544）+长度=16+TCP_空间=不在乎（按建议值保留=15）+非\u TCP\u空间=200（在R1上配置）+F\u最大\u时段=不在乎（按建议值保留=256）+F\u最大\u时间=不在乎（按建议值保留=5秒）+最大\u标头=168（建议值）+增强型RTP压缩子选项&Type=2&Length=2 o标签TLV-包含R1选择的标签，Lr1 o无可选参数
The Label Mapping message sent from R4/HD to R1/HC would be almost identical to the one sent in the opposite direction, with the following exceptions:
从R4/HD发送到R1/HC的标签映射消息与从相反方向发送的标签映射消息几乎相同，但以下情况除外：
o R4/HD could select a different Group ID o The Value of NON_TCP_SPACE in the CRTP/ECRTP/IPHC HC over MPLS configuration sub-TLV would be 255 instead of 200, as configured on R4/HD o R4/HD would choose its own value for the Label TLV, Lr4
o R4/HD可以选择不同的组ID。CRTP/ECRTP/IPHC over MPLS配置子TLV中的非TCP_空间值将为255而不是200，正如R4/HD上配置的那样。R4/HD将为标签TLV选择自己的值，Lr4
As soon as either R1/HC or R4/HD has both transmitted and received Label Mapping Messages with the same PW Type and PW ID, that HC endpoint considers the PW established. R1/HC could send ECRTP packets using the label it received in the Label Mapping Message from R4/HD, Lr4, and could identify received ECRTP packets by the label it had sent to R4/HD, Lr1. And vice versa.
只要R1/HC或R4/HD发送和接收到具有相同PW类型和PW ID的标签映射消息，HC端点就会认为PW已建立。R1/HC可以使用它在来自R4/HD，Lr4的标签映射消息中接收到的标签发送ECRTP数据包，并且可以通过它发送给R4/HD，Lr1的标签识别接收到的ECRTP数据包。反之亦然。
In this case, assume that R1/HC has an IPv4 RTP flow to send to R4/HD that it wishes to compress using the ECRTP PW just set up. The RTP flow is G.729 media with 20 bytes of payload in each RTP packet. In this particular case, the IPv4 identifier changes by a small constant value between consecutive packets in the stream. In the RTP layer of the flow, the Contributing Source Identifiers count is 0. R1/HC decides to use 8-bit Context Identifiers for the compressed flow. Also, R1/HC determines that compression in this particular flow should be able to recover from the loss of 2 consecutive packets without requiring re-synchronization of the context (i.e., the "N" value from [RFC3545] is 2).
在这种情况下，假设R1/HC有一个IPv4 RTP流要发送到它希望使用刚刚设置的ECRTP PW压缩的R4/HD。RTP流是G.729媒体，每个RTP数据包中有20字节的有效负载。在这种特定情况下，IPv4标识符在流中的连续数据包之间改变一个小的常量值。在流的RTP层中，贡献源标识符计数为0。R1/HC决定对压缩流使用8位上下文标识符。此外，R1/HC确定该特定流中的压缩应该能够从2个连续分组的丢失中恢复，而不需要重新同步上下文（即，[RFC3545]中的“N”值为2）。
The first 3 (N + 1) packets of this flow would be sent as FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would be formatted as follows:
此流的前3（N+1）个数据包将作为完整的_头数据包发送。这些数据包开头的MPLS和PW报头的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 2 | 62 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 2 == FULL_HEADER
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 2 | 62 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 2 == FULL_HEADER
where XX signifies either a. value determined by the MPLS routing layer b. don't care
其中XX表示a。由MPLS路由层b确定的值。不在乎
Immediately following the above header would come the FULL_HEADER packet as defined in [RFC3545], which basically consists of the IP/UDP/RTP header, with the IP and UDP length field replaced by values encoding the CID, sequence number, and "generation", as defined in [RFC3545]. The length field value of 62 comprises:
紧跟在上述报头之后的是[RFC3545]中定义的完整_报头数据包，它基本上由IP/UDP/RTP报头组成，IP和UDP长度字段替换为编码CID、序列号和“生成”的值，如[RFC3545]中所定义。长度字段值62包括：
o 2 bytes of HC control parameter (included in the above diagram)
o 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER
o 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER
o 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER
o 20 bytes of G.729 payload
o 2 bytes of HC control parameter (included in the above diagram)
o 20 bytes of the IP header portion of the RFC 3545 FULL_HEADER
o 8 bytes of the UDP header portion of the RFC 3545 FULL_HEADER
o 12 bytes of the RTP header portion of the RFC 3545 FULL_HEADER
o 20 bytes of G.729 payload
The next 3 RTP packets from this flow would be sent as COMPRESSED_UDP_8, to establish the absolute and delta values of the IPv4 identifier and RTP timestamp fields. These packets would use the same ECRTP CID as the previous 3 FULL_HEADER packets. The MPLS and PW headers at the beginning of these packets would be formatted as follows:
来自该流的下3个RTP数据包将作为压缩的_UDP_8发送，以建立IPv4标识符和RTP时间戳字段的绝对值和增量值。这些数据包将使用与前3个完整_头数据包相同的ECRTP CID。这些数据包开头的MPLS和PW报头的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 8 | 36 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 8 == COMPRESSED_UDP_8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 8 | 36 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 8 == COMPRESSED_UDP_8
There is no change in the MPLS label stack between the FULL_HEADER packets and the COMPRESSED_UDP packets. The HC control parameter changes to reflect another ECRTP packet type following the control parameter, and a change of packet length. The length changes because the new packet type more compactly encodes the headers. The length field value of 36 comprises:
完整的_头数据包和压缩的_UDP数据包之间的MPLS标签堆栈没有变化。HC控制参数改变以反映控制参数之后的另一ECRTP分组类型和分组长度的改变。长度改变是因为新的数据包类型对报头进行了更紧凑的编码。长度字段值36包括：
o 2 bytes of HC control parameter (included in the above diagram)
o 1 byte of CID
o 2 bytes of COMPRESSED_UDP fields that are not octet-aligned:
- 4 bits of COMPRESSED_UDP flags
- 4 bits of sequence number
- 5 bits of COMPRESSED UDP extension flags
- 3 bits MUST_BE_ZERO
o 2 bytes of UDP checksum or HDRCKSUM
o 1 byte of delta IPv4 ID
o 2 bytes of delta RTP timestamp (changes by 160 in this case,
differential encoding will encode as 2 bytes)
o 2 bytes of absolute IPv4 ID
o 4 bytes of absolute RTP timestamp
o 20 bytes of G.729 payload
o 2 bytes of HC control parameter (included in the above diagram)
o 1 byte of CID
o 2 bytes of COMPRESSED_UDP fields that are not octet-aligned:
- 4 bits of COMPRESSED_UDP flags
- 4 bits of sequence number
- 5 bits of COMPRESSED UDP extension flags
- 3 bits MUST_BE_ZERO
o 2 bytes of UDP checksum or HDRCKSUM
o 1 byte of delta IPv4 ID
o 2 bytes of delta RTP timestamp (changes by 160 in this case,
differential encoding will encode as 2 bytes)
o 2 bytes of absolute IPv4 ID
o 4 bytes of absolute RTP timestamp
o 20 bytes of G.729 payload
After the context for the IPv4 ID and RTP timestamp is initialized. Subsequent packets on this flow, at least until the end of the talk spurt or until there is some other unexpected change in the IP/UDP/RTP headers, may be sent as COMPRESSED_RTP_8 packets. Again, the same MPLS stack would be used for these packets, and the same value of the CID would be used in this case as for the packets described above. The MPLS and PW headers at the beginning of these packets would be formatted as follows:
在初始化IPv4 ID和RTP时间戳的上下文之后。该流上的后续数据包，至少在通话结束之前，或者在IP/UDP/RTP报头中出现一些其他意外变化之前，可以作为压缩的RTP 8数据包发送。同样，相同的MPLS堆栈将用于这些分组，并且在这种情况下，将使用与上述分组相同的CID值。这些数据包开头的MPLS和PW报头的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 6 | 26 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 6 == COMPRESSED_RTP_8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| XX | XX |0| XX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | Exp |S| TTL |
| Lr4 | XX |1| >0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Pkt Typ| Length |Res|
|0 0 0 0| 6 | 26 |0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
^
|
-- 6 == COMPRESSED_RTP_8
The HC control parameter again changes to reflect another ECRTP packet type following the control parameter, and shorter length associated with an even more compact encoding of headers. The length field value of 26 comprises:
HC控制参数再次改变以反映控制参数之后的另一种ECRTP分组类型，以及与更紧凑的报头编码相关联的更短的长度。长度字段值26包括：
o 2 bytes of HC control parameter (included in the above diagram)
o 1 byte of CID
o 1 byte COMPRESSED_UDP fields that are not octet-aligned:
- 4 bits of COMPRESSED_RTP flags
- 4 bits of sequence number
o 2 bytes of UDP checksum or HDRCKSUM
o 20 bytes of G.729 payload
o 2 bytes of HC control parameter (included in the above diagram)
o 1 byte of CID
o 1 byte COMPRESSED_UDP fields that are not octet-aligned:
- 4 bits of COMPRESSED_RTP flags
- 4 bits of sequence number
o 2 bytes of UDP checksum or HDRCKSUM
o 20 bytes of G.729 payload
Additional flows in the same direction may be compressed using the same basic encapsulation, including the same PW label. The CID that is part of the HC protocol is used to differentiate flows. For traffic in the opposite direction, the primary change would be the PW label, Lr4, used in the example above would be replaced by the label Lr1 that R1/HC provides to R4/HD.
可以使用相同的基本封装（包括相同的PW标签）压缩相同方向的附加流。作为HC协议一部分的CID用于区分流量。对于相反方向的交通，主要变化是上述示例中使用的PW标签Lr4将由R1/HC提供给R4/HD的标签Lr1代替。
MPLS PW security considerations in general are discussed in [RFC3985] and [RFC4447], and those considerations also apply to this document. This document specifies an encapsulation and not the protocols that may be used to carry the encapsulated packets across the PSN, or the protocols being encapsulated. Each such protocol may have its own set of security issues, but those issues are not affected by the encapsulations specified herein.
[RFC3985]和[RFC4447]中讨论了一般的MPLS PW安全注意事项，这些注意事项也适用于本文档。本文档指定了封装，而不是可用于在PSN上传输封装数据包的协议，或正在封装的协议。每个这样的协议可能有其自己的一组安全问题，但是这些问题不受本文指定的封装的影响。
The security considerations of the supported HC protocols [RFC2507, RFC2508, RFC3095, RFC3095bis, RFC3545] all apply to this document as well.
支持的HC协议[RFC2507、RFC2508、RFC3095、RFC3095bis、RFC3545]的安全注意事项也适用于本文档。
The authors appreciate valuable inputs and suggestions from Loa Andersson, Scott Brim, Stewart Bryant, Spencer Dawkins, Adrian Farrel, Victoria Fineberg, Eric Gray, Allison Mankin, Luca Martini, Colin Perkins, Kristofer Sandlund, Yaakov Stein, George Swallow, Mark Townsley, Curtis Villamizar, and Magnus Westerlund.
作者感谢Loa Andersson、Scott Brim、Stewart Bryant、Spencer Dawkins、Adrian Farrel、Victoria Fineberg、Eric Gray、Allison Mankin、Luca Martini、Colin Perkins、Kristofer Sandlund、Yaakov Stein、George Swallow、Mark Townsley、Curtis Villamizar和Magnus Westerlund的宝贵意见和建议。
As discussed in Section 4.1, PW type values have been assigned by IANA, as follows:
As discussed in Section 4.1, PW type values have been assigned by IANA, as follows:translate error, please retry
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]
0x001A ROHC Transport Header-compressed Packets [RFC3095bis]
0x001B ECRTP Transport Header-compressed Packets [RFC3545]
0x001C IPHC Transport Header-compressed Packets [RFC2507]
0x001D CRTP Transport Header-compressed Packets [RFC2508]
Procedures for registering new PW type values are given in [RFC4446].
[RFC4446]中给出了注册新PW类型值的程序。
As discussed in Section 4.2, Pseudowire Interface Parameter Sub-TLV type values have been specified by IANA, as follows:
如第4.2节所述，IANA规定了伪线接口参数子TLV类型值，如下所示：
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544
Parameter ID Length Description Reference
--------- --------------- ---------------------------- ---------
0x0D up to 256 bytes ROHC over MPLS configuration RFC 4901
RFC 3241
0x0F up to 256 bytes CRTP/ECRTP/IPHC HC over MPLS RFC 4901
configuration RFC 3544
As discussed in Section 4.3, IANA has defined a new registry, "Header Compression Over MPLS HC Control Parameter Packet Type". This is a four-bit value. Packet Types 0 through 10 are defined in Section 4.3 of this document. Packet Types 11 to 15 are to be assigned by IANA using the "Expert Review" policy defined in [RFC2434].
如第4.3节所述，IANA定义了一个新的注册表，“MPLS HC控制参数数据包类型上的报头压缩”。这是一个四位值。本文件第4.3节定义了数据包类型0至10。IANA将使用[RFC2434]中定义的“专家评审”策略分配数据包类型11至15。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", RFC 3241, April 2002.
[RFC3241]Bormann，C.，“PPP上的鲁棒头压缩（ROHC）”，RFC 32412002年4月。
[RFC3544] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[RFC3544]Engan，M.，Casner，S.，Bormann，C.，和T.Koren，“PPP上的IP头压缩”，RFC 35442003年7月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[ECMP-AVOID] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", Work in Progress, February 2007.
[ECMP-AVOID]Swallow，G.，Bryant，S.，和L.Andersson，“避免MPLS网络中的等成本多路径处理”，正在进行的工作，2007年2月。
[REORDER-EVAL] Knutsson, C., "Evaluation and Implementation of Header Compression Algorithm ECRTP", http://epubl.luth.se/ 1402-1617/2004/286/LTU-EX-04286-SE.pdf.
[REORDER-EVAL]Knutsson，C.，“头压缩算法ECRTP的评估和实现”，http://epubl.luth.se/ 1402-1617/2004/286/LTU-EX-04286-SE.pdf。
[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月。
[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月。
[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, "IP Header Compression", 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月。
[RFC3095] Bormann, C., et al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.等人，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP、UDP、ESP和未压缩”，RFC 3095，2001年7月。
[RFC3095bis] Jonsson, L-E. Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", Work in Progress, November 2006.
[RFC3095bis]Jonsson，L-E.Pelletier，G.和K.Sandlund，“鲁棒头压缩（ROHC）框架”，正在进行的工作，2006年11月。
[RFC3209] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.
[RFC3209]Awduche，D.等人，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3544] Koren, T., et al., "IP Header Compression over PPP," RFC 3544, July 2003.
[RFC3544]Koren，T.等人，“PPP上的IP报头压缩”，RFC 3544，2003年7月。
[RFC3545] Koren, T., et al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.
[RFC3545]Koren，T.，等人，“在具有高延迟、数据包丢失和重新排序的链路上压缩IP/UDP/RTP报头”，RFC 35452003年7月。
[RFC3246] Davie, B., et al., "An Expedited Forwarding PHB (Per-Hop Behavior)," RFC 3246, March 2002.
[RFC3246]Davie，B.等人，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[RFC3270] Le Faucheur, F., et al., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services," RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.等人，“区分服务的多协议标签交换（MPLS）支持”，RFC 3270，2002年5月。
[RFC3550] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-Time Applications," RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.等人，“RTP：实时应用的传输协议”，RFC3550，2003年7月。
[RFC3843] Jonsson, L-E. and G. Pelletier, "RObust Header Compression (ROHC): A Compression Profile for IP", RFC 3843, June 2004.
[RFC3843]Jonsson，L-E.和G.Pelletier，“鲁棒头压缩（ROHC）：IP的压缩配置文件”，RFC 38432004年6月。
[RFC3985] Bryant, S., Pate, P., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture," RFC 3985, March 2005.
[RFC3985]Bryant，S.，Pate，P.，“伪线仿真边到边（PWE3）架构”，RFC 39852005年3月。
[RFC4224] Pelletier, G., et al., "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets," RFC 4224, January 2006.
[RFC4224]Pelletier，G.等人，“鲁棒报头压缩（ROHC）：可以对数据包重新排序的信道上的ROHC”，RFC 42242006年1月。
[RFC4247] Ash, G., Goode, B., Hand, J., "Requirements for Header Compression over MPLS", RFC 4247, November 2005.
[RFC4247]Ash，G.，Goode，B.，Hand，J.，“MPLS上的报头压缩要求”，RFC 4247，2005年11月。
[RFC4364] Rosen, E., Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPN)s", RFC 4364, February 2006.
[RFC4364]Rosen，E.，Rekhter，Y.，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4385] Bryant, S., et al., "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN," RFC 4385, February 2006.
[RFC4385]Bryant，S.等人，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，2006年2月。
[RFC4446] Martini, L., et al., "IANA Allocations for Pseudo Wire Edge To Edge Emulation (PWE3)," RFC 4446, April 2006.
[RFC4446]Martini，L.等人，“伪线边到边仿真（PWE3）的IANA分配”，RFC 4446，2006年4月。
[RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007.
[RFC4815]Jonsson，L-E.，Sandlund，K.，Pelletier，G.，和P.Kremer，“鲁棒头压缩（ROHC）：对RFC 3095的更正和澄清”，RFC 4815，2007年2月。
Besides the editors listed below, the following people contributed to the document:
除了下面列出的编辑外，以下人员对该文件作出了贡献：
Bur Goode AT&T Phone: +1 203-341-8705 EMail: bgoode@att.com
Bur Goode AT&T电话：+1 203-341-8705电子邮件：bgoode@att.com
Lars-Erik Jonsson Optand 737 SE-831 92 Ostersund, Sweden Phone: +46 70 365 20 58 EMail: lars-erik@lejonsson.com
Lars Erik Jonsson Optand 737 SE-831 92 Ostersund，瑞典电话：+46 70 365 20 58电子邮件：Lars-erik@lejonsson.com
Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA EMail: zhangr@bt.infonet.com
Raymond Zhang信息网服务公司美国加利福尼亚州埃尔塞贡多大道东2160号邮编90025电子邮件：zhangr@bt.infonet.com
Editors' Addresses
编辑地址
Jerry Ash AT&T Email: gash5107@yahoo.com
Jerry Ash AT&T电子邮件：gash5107@yahoo.com
Jim Hand AT&T Room MT A2-1A03 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-3017 EMail: jameshand@att.com
Jim Hand AT&T室MT A2-1A03 200美国新泽西州劳雷尔大道中城07748号电话：+1 732-420-3017电子邮件：jameshand@att.com
Andrew G. Malis Verizon Communications 40 Sylvan Road Waltham, MA 02451 USA EMail: andrew.g.malis@verizon.com
Andrew G.Malis Verizon Communications 40 Sylvan Road Waltham，马萨诸塞州02451美国电子邮件：Andrew.G。malis@verizon.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。