Network Working Group J. Ash
Request for Comments: 4247 B. Goode
Category: Informational J. Hand
AT&T
R. Zhang
BT Infonet
November 2005
Network Working Group J. Ash
Request for Comments: 4247 B. Goode
Category: Informational J. Hand
AT&T
R. Zhang
BT Infonet
November 2005
Requirements for Header Compression over MPLS
MPLS上的报头压缩要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS Label Switched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario.
IP语音（VoIP）通常使用封装语音/RTP/UDP/IP。添加MPLS标签后，将成为语音/RTP/UDP/IP/MPLS标签。例如，对于MPLS VPN，数据包报头通常为48字节，而语音有效负载通常不超过30字节。头压缩可以通过各种压缩机制显著降低开销，例如增强压缩RTP（ECRTP）和健壮头压缩（ROHC）。我们考虑使用MPLS来在MPLS标签交换路径（LSP）上路由压缩分组，而在每个路由器上没有压缩/解压缩周期。这种方法可以提高带宽效率以及在每个路由器上使用报头压缩的最大并发流数的处理可伸缩性。在本文档中，我们给出了一个问题陈述、目标和需求，以及一个示例场景。
Table of Contents
目录
1. Introduction ....................................................2
2. Problem Statement ...............................................3
2.1. Specification of Requirements ..............................4
3. Goals and Requirements ..........................................5
4. Candidate Solution Methods and Needs ............................6
5. Example Scenario ................................................7
6. Security Considerations .........................................8
7. Normative References ............................................8
8. Informative References ..........................................9
9. Acknowledgements ...............................................10
1. Introduction ....................................................2
2. Problem Statement ...............................................3
2.1. Specification of Requirements ..............................4
3. Goals and Requirements ..........................................5
4. Candidate Solution Methods and Needs ............................6
5. Example Scenario ................................................7
6. Security Considerations .........................................8
7. Normative References ............................................8
8. Informative References ..........................................9
9. Acknowledgements ...............................................10
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [MPLS-ARCH] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS Virtual Private Network (VPN) (e.g., [MPLS-VPN]), the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. 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] or robust header compression [ROHC], and also to increase scalability of HC. We consider using MPLS to route compressed 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 flows that use HC at each router.
IP语音（VoIP）通常使用封装语音/RTP/UDP/IP。添加MPLS标签[MPLS-ARCH]后，将成为语音/RTP/UDP/IP/MPLS标签。例如，对于MPLS虚拟专用网络（VPN）（例如，[MPLS-VPN]），分组报头至少为48字节，而语音有效载荷通常不超过30字节。对报头压缩（HC）的兴趣在于通过各种压缩机制（例如增强的压缩RTP[ECRTP]或健壮的报头压缩[ROHC]）利用显著降低开销的可能性，并且还可以增加HC的可伸缩性。我们考虑使用MPLS来在MPLS标签交换路径（LSP）上路由压缩分组，而在每个路由器上没有压缩/解压缩周期。这种HC-over-MPLS能力可以提高带宽效率以及在每个路由器上使用HC的最大数量的同时流的处理可伸缩性。
To implement HC over MPLS, the ingress router/gateway would have to apply the HC algorithm to the IP packet, the compressed packet routed on an MPLS LSP using MPLS labels, and the compressed header would be decompressed at the egress router/gateway where the HC session terminates. Figure 1 illustrates an HC over MPLS session established on an LSP that crosses several routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where HC is performed, and R4/HD is the egress router where header decompression (HD) is done. HC 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.
为了在MPLS上实现HC，入口路由器/网关必须将HC算法应用于IP分组，压缩分组使用MPLS标签在MPLS LSP上路由，并且压缩报头将在HC会话终止的出口路由器/网关处解压缩。图1说明了在跨越多个路由器的LSP上建立的HC over MPLS会话，从R1/HC-->R2-->R3-->R4/HD开始，其中R1/HC是执行HC的入口路由器，R4/HD是执行报头解压缩（HD）的出口路由器。RTP/UDP/IP报头的HC在R1/HC处执行，并且使用MPLS标签从R1/HC到R2、到R3、最后到R4/HD路由压缩包，而无需进一步的解压缩/再压缩循环。RTP/UDP/IP报头在R4/HD进行解压缩，并可根据需要转发到其他路由器。
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
_____
| |
|R1/HC| Header Compression (HC) Performed
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R2 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
| R3 |
|_____|
|
| voice/compressed-header/MPLS-labels
V
_____
| |
|R4/HD| Header Decompression (HD) Performed
|_____|
Figure 1. Example of Header Compression over MPLS over Routers R1-->R4
图1。路由器R1-->R4上MPLS上的报头压缩示例
In the example scenario, HC therefore takes place between R1 and R4, and the MPLS path transports voice/compressed-header/MPLS-labels instead of voice/RTP/UDP/IP/MPLS-labels, typically saving 30 octets or more per packet. The MPLS label stack and link-layer headers are not compressed. A signaling method is needed to set up a correspondence between the ingress and egress routers of the HC over MPLS session.
在示例场景中，HC因此发生在R1和R4之间，并且MPLS路径传输语音/压缩报头/MPLS标签，而不是语音/RTP/UDP/IP/MPLS标签，通常每个数据包节省30个八位字节或更多。MPLS标签堆栈和链路层头不会被压缩。需要一种信令方法来建立HC over MPLS会话的入口和出口路由器之间的对应关系。
In Section 2 we give a problem statement, in Section 3 we give goals and requirements, and in Section 5 we give an example scenario.
在第2节中，我们给出了一个问题陈述，在第3节中，我们给出了目标和要求，在第5节中，我们给出了一个示例场景。
As described in the introduction, HC over MPLS can significantly reduce the header overhead through HC mechanisms. The need for HC may be important on low-speed links where bandwidth is more scarce, but it could also be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). VoIP typically will use voice compression mechanisms (e.g., G.729) on
如引言中所述，通过HC机制，HC over MPLS可以显著降低报头开销。HC的需求在带宽更为稀缺的低速链路上可能很重要，但在主干设施上也可能很重要，特别是在成本较高的情况下（例如，某些全局横截面）。VoIP通常会在网络上使用语音压缩机制（例如，g.729）
low-speed and international routes, in order to conserve bandwidth. With HC, significantly more bandwidth could be saved. For example, carrying uncompressed headers for the entire voice load of a large domestic network with 300 million or more calls per day could consume on the order of about 20-40 gigabits per second on the backbone network for headers alone. This overhead could translate into considerable bandwidth capacity.
低速和国际航线，以节省带宽。使用HC，可以节省大量带宽。例如，在一个每天有3亿或更多呼叫的大型家庭网络中，为整个语音负载承载未压缩的报头，仅在主干网络上，报头就可能消耗大约20-40千兆位每秒。这种开销可以转化为相当大的带宽容量。
The claim is often made that once fiber is in place, increasing the bandwidth capacity is inexpensive, nearly 'free'. This may be true in some cases; however, on some international cross-sections, especially, facility/transport costs are very high and saving bandwidth on such backbone links is very worthwhile. Decreasing the backbone bandwidth is needed in some areas of the world where bandwidth is very expensive. It is also important in almost all locations to decrease the bandwidth consumption on low-speed links. So although bandwidth is getting cheaper, the value of compression does not go away. It should be further noted that IPv6 will increase the size of headers, and therefore increase the importance of HC for RTP flows.
人们经常声称，一旦光纤就位，增加带宽容量是廉价的，几乎是“免费的”。这在某些情况下可能是正确的；然而，在某些国际横截面上，特别是设施/传输成本非常高，在此类主干链路上节省带宽是非常值得的。在世界上某些带宽非常昂贵的地区，需要降低主干网带宽。在几乎所有位置，降低低速链路上的带宽消耗也很重要。因此，尽管带宽越来越便宜，但压缩的价值并没有消失。应该进一步注意的是，IPv6将增加报头的大小，因此增加HC对于RTP流的重要性。
Although hop-by-hop HC could be applied to decrease bandwidth requirements, that implies a processing requirement for compression-decompression cycles at every router hop, which does not scale well for large voice traffic loads. The maximum number of compressed RTP (cRTP) flows is about 30-50 for a typical customer premise router, depending upon its uplink speed and processing power, while the need may exceed 300-500 for a high-end case. Therefore, HC over MPLS seems to be a viable alternative to get the compression benefits without introducing costly processing demands on the intermediate nodes. By using HC over MPLS, routers merely forward compressed packets without doing a decompression/recompression cycle, thereby increasing the maximum number of simultaneous compressed flows that routers can handle.
虽然逐跳HC可用于降低带宽要求，但这意味着每个路由器跳都需要压缩-解压缩周期的处理要求，这对于大的语音流量负载来说无法很好地扩展。对于典型的用户端路由器，压缩RTP（cRTP）流的最大数量约为30-50，这取决于其上行链路速度和处理能力，而对于高端路由器，需求可能超过300-500。因此，HC over MPLS似乎是一种可行的替代方案，可以在不引入昂贵的中间节点处理需求的情况下获得压缩优势。通过使用HC over MPLS，路由器仅转发压缩数据包，而不进行解压缩/再压缩循环，从而增加路由器可以处理的最大并发压缩流数。
Therefore, the proposal is to use existing HC techniques, together with MPLS labels, to make the transport of the RTP/UDP/IP headers more efficient over an MPLS network. However, at this time, there are no standards for HC over MPLS, and vendors have not implemented such techniques.
因此，建议使用现有的HC技术和MPLS标签，使RTP/UDP/IP报头在MPLS网络上的传输更加高效。然而，目前还没有针对基于MPLS的HC的标准，供应商也没有实施此类技术。
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 [KEY].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键]中所述进行解释。
The goals of HC over MPLS are as follows:
HC over MPLS的目标如下：
a. provide more efficient voice transport over MPLS networks, b. increase the scalability of HC to a large number of flows, c. not significantly increase packet delay, delay variation, or loss probability, and d. leverage existing work through use of standard protocols as much as possible.
a. 通过MPLS网络提供更高效的语音传输。增加HC对大量流的可伸缩性，c。不会显著增加数据包延迟、延迟变化或丢失概率，以及d。通过尽可能多地使用标准协议来利用现有工作。
Therefore the requirements for HC over MPLS are as follows:
因此，通过MPLS的HC要求如下：
a. MUST use existing protocols (e.g., [ECRTP], [ROHC]) to compress RTP/UDP/IP headers, in order to provide for efficient transport, tolerance to packet loss, and resistance to loss of session context. b. MUST allow HC over an MPLS LSP, and thereby avoid hop-by-hop compression/decompression cycles (e.g., [HC-MPLS-PROTO]). c. MUST minimize incremental performance degradation due to increased delay, packet loss, and jitter. d. MUST use standard protocols to signal context identification and control information (e.g., [RSVP], [RSVP-TE], [LDP]). e. Packet reordering MUST NOT cause incorrectly decompressed packets to be forwarded from the decompressor.
a. 必须使用现有协议（例如[ECRTP]、[ROHC]）来压缩RTP/UDP/IP报头，以便提供高效传输、对数据包丢失的容忍度以及对会话上下文丢失的抵抗力。B必须允许HC通过MPLS LSP，从而避免逐跳压缩/解压缩循环（例如，[HC-MPLS-PROTO]）。C必须最大限度地减少因延迟、数据包丢失和抖动增加而导致的性能增量下降。D必须使用标准协议发送上下文识别和控制信息（例如，[RSVP]、[RSVP-TE]、[LDP]）。E数据包重新排序不得导致从解压缩器转发错误解压缩的数据包。
It is necessary that the HC method be able to handle out-of-sequence packets. MPLS [MPLS-ARCH] enables 4-byte labels to be appended to IP packets to allow switching from the ingress Label Switching Router (LSR) to the egress LSP on an LSP through an MPLS network. However, MPLS does not guarantee that packets will arrive in order at the egress LSR, since a number of things could cause packets to be delivered out of sequence. For example, a link failure could cause the LSP routing to change, due perhaps to an MPLS fast reroute taking place, or to the Interior Gateway Protocol (IGP) and Label Distribution Protocol (LDP) converging to another route, among other possible reasons. Other causes could include IGP reroutes due to 'loose hops' in the LSP, or BGP route changes reflecting back into IGP reroutes. HC algorithms may be able to handle reordering magnitudes on the order of about 10 packets, which may make the time required for IGP reconvergence (typically on the order of seconds) untenable for the HC algorithm. On the other hand, MPLS fast reroute may be fast enough (on the order of 50 ms or less) for the HC algorithm to handle packet reordering. The issue of reordering needs to be further considered in the development of the HC over MPLS solution.
HC方法必须能够处理无序数据包。MPLS[MPLS-ARCH]允许将4字节标签附加到IP数据包，以允许通过MPLS网络从入口标签交换路由器（LSR）切换到LSP上的出口LSP。然而，MPLS不能保证数据包将按顺序到达出口LSR，因为许多事情可能导致数据包按顺序交付。例如，链路故障可能导致LSP路由改变，这可能是由于发生MPLS快速重路由，或者由于内部网关协议（IGP）和标签分发协议（LDP）收敛到另一路由，以及其他可能的原因。其他原因可能包括由于LSP中的“松散跳数”而导致的IGP重路由，或BGP路由更改反映回IGP重路由。HC算法可能能够处理大约10个数据包的顺序上的重新排序大小，这可能使HC算法无法维持IGP重新收敛所需的时间（通常为秒级）。另一方面，MPLS快速重路由对于HC算法处理分组重排序可能足够快（大约50ms或更少）。在开发HC over MPLS解决方案时，需要进一步考虑重新排序问题。
Resynchronization and performance also needs to be considered, since HC over MPLS can sometimes have multiple routers in the LSP. Tunneling an HC session over an MPLS LSP with multiple routers in the path will increase the round-trip delay and the chance of packet loss, and HC contexts may be invalidated due to packet loss. The HC error recovery mechanism can compound the problem when long round-trip delays are involved.
还需要考虑重新同步和性能，因为HC over MPLS有时可能在LSP中有多个路由器。在路径中有多个路由器的MPLS LSP上通过隧道传输HC会话将增加往返延迟和分组丢失的机会，并且HC上下文可能由于分组丢失而无效。当涉及长往返延迟时，HC错误恢复机制会使问题复杂化。
[cRTP] performs best with very low packet error rates on all hops of the path. When the cRTP decompressor context state gets out of synch with the compressor, it will drop packets associated with the context until the two states are resynchronized. To resynchronize context state at the two ends, the decompressor transmits the CONTEXT_STATE packet to the compressor, and the compressor transmits a FULL_HEADER packet to the decompressor.
[cRTP]在路径的所有跃点上以极低的数据包错误率表现最佳。当cRTP解压器上下文状态与压缩器不同步时，它将丢弃与上下文关联的数据包，直到这两个状态重新同步。为了在两端重新同步上下文状态，解压缩器将上下文_状态数据包发送给压缩器，压缩器将完整的_头数据包发送给解压缩器。
[ECRTP] uses mechanisms that make cRTP more tolerant to packet loss, and ECRTP thereby helps to minimize the use of feedback-based error recovery (CONTEXT_STATE packets). ECRTP is therefore a candidate method to make HC over MPLS more tolerant of packet loss and to guard against frequent resynchronizations. ECRTP may need some implementation adaptations to address the reordering requirement in Section 3 (requirement e), since a default implementation will probably not meet the requirement. ECRTP protocol extensions may be required to identify FULL_HEADER, CONTEXT_STATE, and compressed packet types. [cRTP-ENCAP] specifies a separate link-layer packet type defined for HC. Using a separate link-layer packet type avoids the need to add extra bits to the compression header to identify the packet type. However, this approach does not extend well to MPLS encapsulation conventions [MPLS-ENCAP], in which a separate link-layer packet type translates into a separate LSP for each packet type. In order to extend ECRTP to HC over MPLS, each packet type defined in [ECRTP] would need to be identified in an appended packet type field in the ECRTP header.
[ECRTP]使用使cRTP更能容忍数据包丢失的机制，因此ECRTP有助于最小化基于反馈的错误恢复（上下文状态数据包）的使用。因此，ECRTP是使HC over MPLS更能容忍数据包丢失并防止频繁重新同步的候选方法。ECRTP可能需要一些实施调整，以满足第3节（需求e）中的重新排序需求，因为默认实施可能无法满足需求。可能需要ECRTP协议扩展来识别完整_头、上下文_状态和压缩包类型。[cRTP ENCAP]指定为HC定义的单独链路层数据包类型。使用单独的链路层分组类型避免了向压缩报头添加额外比特以识别分组类型的需要。然而，这种方法不能很好地扩展到MPLS封装约定[MPLS-ENCAP]，在这种约定中，单独的链路层分组类型转换为每个分组类型的单独LSP。为了通过MPLS将ECRTP扩展到HC，需要在ECRTP报头中的附加分组类型字段中标识[ECRTP]中定义的每个分组类型。
[ROHC] is also very tolerant of packet loss, and therefore is a candidate method to guard against frequent resynchronizations. ROHC also achieves a somewhat better level of compression as compared to ECRTP. ROHC may need some implementation adaptations to address the reordering requirement in Section 3 (requirement e), since a default implementation will probably not meet the requirement (see [ROHC-REORD]). ROHC already has the capability to identify the packet type in the compression header, so no further extension is needed to identify packet type.
[ROHC]对数据包丢失也非常宽容，因此是防止频繁重新同步的候选方法。与ECRTP相比，ROHC还实现了更好的压缩级别。ROHC可能需要一些实施调整来满足第3节（要求e）中的重新排序要求，因为默认实施可能不满足要求（见[ROHC-REORD]）。ROHC已经能够识别压缩报头中的数据包类型，因此不需要进一步扩展来识别数据包类型。
Extensions to MPLS signaling may be needed to identify the LSP from HC to HD egress point, negotiate the HC algorithm used and protocol parameters, and negotiate the Session Context IDs (SCIDs) space between the ingress and egress routers on the MPLS LSP. For example, new objects may need to be defined for [RSVP-TE] to signal the SCID spaces between the ingress and egress routers, and the HC algorithm used to determine the context; these HC packets then contain the SCID identified by using the RSVP-TE objects. It is also desirable to signal HC over MPLS tunnels with the Label Distribution Protocol [LDP], since many RFC 2547 VPN [MPLS-VPN] implementations use LDP as the underlying LSP signaling mechanism, and LDP is very scalable. However, extensions to LDP may be needed to signal SCIDs between ingress and egress routers on HC over MPLS LSPs. For example, 'targeted LDP sessions' might be established for signaling SCIDs, or perhaps methods described in [LDP-PWE3] to signal pseudo-wires and multipoint-to-point LSPs might be extended to support signaling of SCIDs for HC over MPLS LSPs. The specific MPLS signaling protocol extensions to support these approved requirements need to be developed as a well-coordinated separate document in the appropriate IETF working groups. The IETF needs to support a coordinated process for the two solution documents, though they are in separate areas.
可能需要对MPLS信令进行扩展，以识别从HC到HD出口点的LSP，协商使用的HC算法和协议参数，并协商MPLS LSP上的入口和出口路由器之间的会话上下文id（scid）空间。例如，可能需要为[RSVP-TE]定义新对象，以向入口和出口路由器之间的SCID空间发送信号，以及用于确定上下文的HC算法；然后，这些HC数据包包含使用RSVP-TE对象识别的SCID。由于许多RFC 2547 VPN[MPLS-VPN]实现使用LDP作为底层LSP信令机制，并且LDP具有很强的可扩展性，因此还希望通过标签分发协议[LDP]通过MPLS隧道向HC发送信号。然而，可能需要对LDP进行扩展，以在HC over MPLS LSP上的入口和出口路由器之间发送SCID信号。例如，可以为SCID信令建立“目标LDP会话”，或者可以扩展[LDP-PWE3]中描述的用于向伪线和多点对点LSP发送信号的方法，以支持通过MPLS LSP为HC发送SCID信令。支持这些批准需求的特定MPLS信令协议扩展需要在适当的IETF工作组中作为协调良好的单独文件进行开发。IETF需要支持两个解决方案文档的协调过程，尽管它们位于不同的区域。
As illustrated in Figure 2, many VoIP flows are originated from customer sites, which are served by routers R1, R2, and R3, and terminated at several large customer call centers, which are served by R5, R6, and R7. R4 is a service-provider router, and all VoIP flows traverse R4. It is essential that the R4-R5, R4-R6, and R4-R7 low-speed links all use HC to allow a maximum number of simultaneous VoIP flows. To allow processing at R4 to handle the volume of simultaneous VoIP flows, it is desired to use HC over MPLS for these flows. With HC over MPLS, R4 does not need to do HC/HD for the flows to the call centers, enabling more scalability of the number of simultaneous VoIP flows with HC at R4.
如图2所示，许多VoIP流源自客户站点，由路由器R1、R2和R3提供服务，并在几个大型客户呼叫中心终止，这些呼叫中心由R5、R6和R7提供服务。R4是一个服务提供商路由器，所有VoIP流都通过R4。R4-R5、R4-R6和R4-R7低速链路都必须使用HC，以允许最大数量的同时VoIP流。为了允许在R4进行处理以处理同时的VoIP流的数量，需要对这些流使用HC over MPLS。有了HC over MPLS，R4不需要对呼叫中心的流执行HC/HD，从而实现了R4上HC的同时VoIP流数量的更大可扩展性。
voice/C-HDR/MPLS-labels ______ voice/C-HDR/MPLS-labels
R1/HC---------------------->| |-----------------------> R5/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R2/HC---------------------->| R4 |-----------------------> R6/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R3/HC---------------------->|______|-----------------------> R7/HD
voice/C-HDR/MPLS-labels ______ voice/C-HDR/MPLS-labels
R1/HC---------------------->| |-----------------------> R5/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R2/HC---------------------->| R4 |-----------------------> R6/HD
| |
voice/C-HDR/MPLS-labels| |voice/C-HDR/MPLS-labels
R3/HC---------------------->|______|-----------------------> R7/HD
Note: HC = header compression C-HDR = compressed header HD = header decompression
注：HC=收割台压缩C-HDR=压缩收割台HD=收割台解压缩
Figure 2. Example Scenario for Application of HC over MPLS
图2。通过MPLS应用HC的示例场景
The high processing load of HC makes HC a target for denial-of-service attacks. For example, an attacker could send a high-bandwidth data stream through a network, with the headers in the data stream marked appropriately to cause HC to be applied. This would use large amounts of processing resources on the routers performing compression and decompression, and these processing resources might then be unavailable for other important functions on the router. This threat is not a new threat for HC, but is addressed and mitigated by HC over MPLS. That is, by reducing the need for performing compression and decompression cycles, as proposed in this document, the risk of this type of denial-of-service attack is reduced.
HC的高处理负载使HC成为拒绝服务攻击的目标。例如，攻击者可以通过网络发送高带宽数据流，并在数据流中适当标记标头以应用HC。这将使用路由器上执行压缩和解压缩的大量处理资源，这些处理资源可能无法用于路由器上的其他重要功能。这种威胁不是HC的新威胁，而是由HC通过MPLS解决和缓解的。也就是说，通过减少执行压缩和解压缩周期的需要（如本文档中所述），可以降低此类拒绝服务攻击的风险。
[cRTP] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999.
[cRTP]Casner，S.和V.Jacobson，“压缩低速串行链路的IP/UDP/RTP报头”，RFC 2508，1999年2月。
[cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[cRTP ENCAP]Engan，M.，Casner，S.，Bormann，C.，和T.Koren，“PPP上的IP头压缩”，RFC 35442003年7月。
[ECRTP] 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.
[ECRTP]Koren，T.，Casner，S.，Geevarghese，J.，Thompson，B.，和P.Ruddy，“针对具有高延迟、数据包丢失和重新排序的链路的增强压缩RTP（CRTP）”，RFC 35452003年7月。
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[MPLS-ARCH]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[ROHC] Bormann, C., et al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[ROHC]Bormann，C.等人，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP、UDP、ESP和未压缩”，RFC 3095，2001年7月。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[HC-MPLS-PROTO] Ash, G., Goode, B., Hand, J., Jonsson, L-E., Malis, A., and R. Zhang, "Protocol Extensions for Header Compression over MPLS", work in progress.
[HC-MPLS-PROTO]Ash，G.，Goode，B.，Hand，J.，Jonsson，L-E.，Malis，A.，和R.Zhang，“MPLS上报头压缩的协议扩展”，正在进行中。
[LDP-PWE3] Martini, L., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", work in progress.
[LDP-PWE3]Martini，L.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议的伪线设置和维护”，正在进行中。
[MPLS-ENCAP] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-ENCAP]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[MPLS-VPN]Rosen，E.和Y.Rekhter，“BGP/MPLS VPN”，RFC 2547，1999年3月。
[ROHC-REORD] Pelletier, G., Jonsson, L-E., and K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", work in progress.
[ROHC-REORD]Pelletier，G.，Jonsson，L-E.，和K.Sandlund，“鲁棒头压缩（ROHC）：可以对数据包重新排序的信道上的ROHC”，正在进行中。
The authors wish to thank the following people (in alphabetical order) for their helpful comments and suggestions: Loa Andersson, Scott Brim, Thomas Eriksson, Victoria Fineberg, Lars-Erik Jonsson, Allison Mankin, Colin Perkins, Kristofer Sandlund, and Magnus Westerlund.
作者希望感谢以下人士（按字母顺序）提供的有用意见和建议：洛亚·安德森、斯科特·布里姆、托马斯·埃里克森、维多利亚·芬伯格、拉尔斯·埃里克·琼森、埃里森·曼金、科林·珀金斯、克里斯托弗·桑德隆德和马格纳斯·韦斯特隆德。
Authors' Addresses
作者地址
Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-4578 EMail: gash@att.com
Jerry Ash AT&T室MT D5-2A01 200美国新泽西州劳雷尔大道中城07748号电话：+1 732-420-4578电子邮件：gash@att.com
Bur Goode AT&T Phone: + 1 203-341-8705 EMail: bgoode@att.com
Bur Goode AT&T电话：+1 203-341-8705电子邮件：bgoode@att.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
Raymond Zhang BT Infonet 2160 E. Grand Ave. El Segundo, CA 90025 USA EMail: raymond.zhang@bt.infonet.com
雷蒙德·张英国电信信息网2160美国加利福尼亚州埃尔塞贡多大道东90025电子邮件：雷蒙德。zhang@bt.infonet.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。