Network Working Group B. Thompson
Request for Comments: 4170 T. Koren
BCP: 110 D. Wing
Category: Best Current Practice Cisco Systems
November 2005
Network Working Group B. Thompson
Request for Comments: 4170 T. Koren
BCP: 110 D. Wing
Category: Best Current Practice Cisco Systems
November 2005
Tunneling Multiplexed Compressed RTP (TCRTP)
隧道复用压缩RTP（TCRTP）
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes a method to improve the bandwidth utilization of RTP streams over network paths that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path.
本文档描述了一种通过网络路径提高RTP流带宽利用率的方法，该网络路径在两个端点之间并行传输多个实时传输协议（RTP）流，如在语音中继中。该方法结合了在网络路径上提供压缩、多路复用和隧道的标准协议，以减少在该路径上承载多个RTP流时使用的带宽。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Is Bandwidth Costly? .......................................3
1.2. Overview of Protocols ......................................3
1.3. Document Focus .............................................4
1.4. Choice of Enhanced CRTP ....................................4
1.5. Reducing TCRTP Overhead ....................................4
2. Protocol Operation and Recommended Extensions ...................4
2.1. Models .....................................................5
2.2. Header Compression: ECRTP ..................................5
2.2.1. Synchronizing ECRTP States ..........................5
2.2.2. Out-of-Order Packets ................................6
2.3. Multiplexing: PPP Multiplexing .............................6
2.3.1. PPP Multiplex Transmitter Modifications for
Tunneling ...........................................7
2.3.2. Tunneling Inefficiencies ............................8
2.4. Tunneling: L2TP ............................................8
2.4.1. Tunneling and DiffServ ..............................9
2.5. Encapsulation Formats ......................................9
3. Bandwidth Efficiency ...........................................10
3.1. Multiplexing Gains ........................................10
3.2. Packet Loss Rate ..........................................10
3.3. Bandwidth Calculation for Voice and Video Applications ....10
3.3.1. Voice Bandwidth Calculation Example ................12
3.3.2. Voice Bandwidth Comparison Table ...................13
3.3.3. Video Bandwidth Calculation Example ................13
3.3.4. TCRTP over ATM .....................................14
3.3.5. TCRTP over Non-ATM Networks ........................14
4. Example Implementation of TCRTP ................................15
4.1. Suggested PPP and L2TP Negotiation for TCRTP ..............17
4.2. PPP Negotiation TCRTP .....................................17
4.2.1. LCP Negotiation ....................................17
4.2.2. IPCP Negotiation ...................................18
4.3. L2TP Negotiation ..........................................19
4.3.1. Tunnel Establishment ...............................19
4.3.2. Session Establishment ..............................19
4.3.3. Tunnel Tear Down ...................................20
5. Security Considerations ........................................20
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................22
1. Introduction ....................................................3
1.1. Is Bandwidth Costly? .......................................3
1.2. Overview of Protocols ......................................3
1.3. Document Focus .............................................4
1.4. Choice of Enhanced CRTP ....................................4
1.5. Reducing TCRTP Overhead ....................................4
2. Protocol Operation and Recommended Extensions ...................4
2.1. Models .....................................................5
2.2. Header Compression: ECRTP ..................................5
2.2.1. Synchronizing ECRTP States ..........................5
2.2.2. Out-of-Order Packets ................................6
2.3. Multiplexing: PPP Multiplexing .............................6
2.3.1. PPP Multiplex Transmitter Modifications for
Tunneling ...........................................7
2.3.2. Tunneling Inefficiencies ............................8
2.4. Tunneling: L2TP ............................................8
2.4.1. Tunneling and DiffServ ..............................9
2.5. Encapsulation Formats ......................................9
3. Bandwidth Efficiency ...........................................10
3.1. Multiplexing Gains ........................................10
3.2. Packet Loss Rate ..........................................10
3.3. Bandwidth Calculation for Voice and Video Applications ....10
3.3.1. Voice Bandwidth Calculation Example ................12
3.3.2. Voice Bandwidth Comparison Table ...................13
3.3.3. Video Bandwidth Calculation Example ................13
3.3.4. TCRTP over ATM .....................................14
3.3.5. TCRTP over Non-ATM Networks ........................14
4. Example Implementation of TCRTP ................................15
4.1. Suggested PPP and L2TP Negotiation for TCRTP ..............17
4.2. PPP Negotiation TCRTP .....................................17
4.2.1. LCP Negotiation ....................................17
4.2.2. IPCP Negotiation ...................................18
4.3. L2TP Negotiation ..........................................19
4.3.1. Tunnel Establishment ...............................19
4.3.2. Session Establishment ..............................19
4.3.3. Tunnel Tear Down ...................................20
5. Security Considerations ........................................20
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................22
This document describes a way to combine existing protocols for compression, multiplexing, and tunneling to save bandwidth for some RTP applications.
本文档描述了一种结合现有压缩、多路复用和隧道协议的方法，以节省一些RTP应用程序的带宽。
On certain links, such as customer access links, the cost of bandwidth is widely acknowledged to be a significant concern. protocols such as CRTP (Compressed RTP, [CRTP]) are well suited to help bandwidth inefficiencies of protocols such as VoIP over these links.
在某些链路（如客户接入链路）上，带宽成本被广泛认为是一个重要问题。CRTP（Compressed RTP，[CRTP]）等协议非常适合帮助VoIP等协议在这些链路上降低带宽效率。
Unacknowledged by many, however, is the cost of long-distance WAN links. While some voice-over-packet technologies such as Voice over ATM (VoAAL2, [I.363.2]) and Voice over MPLS provide bandwidth efficiencies (because both technologies lack IP, UDP, and RTP headers), neither VoATM nor VoMPLS provide direct access to voice-over-packet services available to Voice over IP. Thus, goals of WAN link cost reduction are met at the expense of lost interconnection opportunities to other networks.
然而，许多人不承认的是长途广域网链接的成本。虽然一些分组语音技术，如ATM语音（VoAAL2，[I.363.2]）和MPLS语音提供了带宽效率（因为这两种技术都缺少IP、UDP和RTP报头），但VoATM和VoMPLS都不能直接访问IP语音可用的分组语音服务。因此，广域网链路成本降低的目标是以失去与其他网络的互连机会为代价的。
TCRTP solves the VoIP bandwidth discrepancy, especially for large, voice-trunking applications.
TCRTP解决了VoIP带宽差异，特别是对于大型语音集群应用。
Header compression is accomplished using Enhanced CRTP (ECRTP, [ECRTP]). ECRTP is an enhancement to classical CRTP [CRTP] that works better over long delay links, such as the end-to-end tunneling links described in this document. This header compression reduces the IP, UDP, and RTP headers.
使用增强型CRTP（ECRTP，[ECRTP]）完成报头压缩。ECRTP是对经典CRTP[CRTP]的增强，它在长延迟链路上工作得更好，例如本文中描述的端到端隧道链路。此标头压缩减少了IP、UDP和RTP标头。
Multiplexing is accomplished using PPP Multiplexing [PPP-MUX].
使用PPP多路复用[PPP-MUX]实现多路复用。
Tunneling PPP is accomplished by using L2TP [L2TPv3].
隧道PPP是通过使用L2TP[L2TPv3]实现的。
CRTP operates link-by-link; that is, to achieve compression over multiple router hops, CRTP must be employed twice on each router -- once on ingress, again on egress. In contrast, TCRTP described in this document does not require any additional per-router processing to achieve header compression. Instead, headers are compressed end-to-end, saving bandwidth on all intermediate links.
CRTP逐链路运行；也就是说，为了在多个路由器跳上实现压缩，必须在每个路由器上使用CRTP两次——一次在入口，另一次在出口。相反，本文档中描述的TCRTP不需要任何额外的每路由器处理来实现报头压缩。相反，报头是端到端压缩的，节省了所有中间链路的带宽。
This document is primarily concerned with bandwidth savings for Voice over IP (VoIP) applications over high-delay networks. However, the combinations of protocols described in this document can be used to provide similar bandwidth savings for other RTP applications such as video, and bandwidth savings are included for a sample video application.
本文档主要关注高延迟网络上IP语音（VoIP）应用程序的带宽节约。然而，本文档中描述的协议组合可用于为其他RTP应用（例如视频）提供类似的带宽节约，并且带宽节约包括在示例视频应用中。
CRTP [CRTP] describes the use of RTP header compression on an unspecified link layer transport, but typically PPP is used. For CRTP to compress headers, it must be implemented on each PPP link. A lot of context is required to successfully run CRTP, and memory and processing requirements are high, especially if multiple hops must implement CRTP to save bandwidth on each of the hops. At higher line rates, CRTP's processor consumption becomes prohibitively expensive.
CRTP[CRTP]描述在未指定的链路层传输上使用RTP报头压缩，但通常使用PPP。CRTP要压缩头文件，必须在每个PPP链路上实现。成功运行CRTP需要大量的上下文，并且内存和处理要求很高，特别是当多个跃点必须实现CRTP以节省每个跃点上的带宽时。在更高的线路速率下，CRTP的处理器消耗变得非常昂贵。
To avoid the per-hop expense of CRTP, a simplistic solution is to use CRTP with L2TP to achieve end-to-end CRTP. However, as described in [ECRTP], CRTP is only suitable for links with low delay and low loss. However, once multiple router hops are involved, CRTP's expectation of low delay and low loss can no longer be met. Further, packets can arrive out of order.
为了避免CRTP的每跳开销，一个简单的解决方案是将CRTP与L2TP结合使用以实现端到端CRTP。然而，如[ECRTP]所述，CRTP仅适用于低延迟和低损耗的链路。然而，一旦涉及到多个路由器跳，CRTP对低延迟和低损耗的期望就无法满足。此外，数据包可能会无序到达。
Therefore, this document describes the use of Enhanced CRTP [ECRTP], which supports high delay, both packet loss, and misordering between the compressor and decompressor.
因此，本文档描述了增强型CRTP[ECRTP]的使用，它支持高延迟、丢包和压缩机与解压缩器之间的误序。
If only one stream is tunneled (L2TP) and compressed (ECRTP), there are little bandwidth savings. Multiplexing is helpful to amortize the overhead of the tunnel header over many RTP payloads. The multiplexing format proposed by this document is PPP multiplexing [PPP-MUX]. See Section 2.3 for details.
如果只对一个流进行隧道传输（L2TP）和压缩（ECRTP），则几乎不会节省带宽。多路复用有助于将隧道头的开销分摊到许多RTP有效负载上。本文件提出的多路复用格式为PPP多路复用[PPP-MUX]。详见第2.3节。
This section describes how to combine three protocols: Enhanced CRTP, PPP Multiplexing, and L2TP Tunneling, to save bandwidth for RTP applications such as Voice over IP.
本节介绍如何组合三种协议：增强型CRTP、PPP多路复用和L2TP隧道，以节省RTP应用程序（如IP语音）的带宽。
TCRTP can typically be implemented in two ways. The most straightforward is to implement TCRTP in the gateways terminating the RTP streams:
TCRTP通常可以通过两种方式实现。最简单的方法是在终止RTP流的网关中实现TCRTP：
[voice gateway]---[voice gateway]
^
|
TCRTP over IP
[voice gateway]---[voice gateway]
^
|
TCRTP over IP
Another way TCRTP can be implemented is with an external concentration device. This device could be placed at strategic places in the network and could dynamically create and destroy TCRTP sessions without the participation of RTP-generating endpoints.
另一种实现TCRTP的方法是使用外部浓缩装置。该设备可以放置在网络中的战略位置，可以动态创建和销毁TCRTP会话，而无需RTP生成端点的参与。
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
RTP over IP TCRTP over IP RTP over IP
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
RTP over IP TCRTP over IP RTP over IP
Such a design also allows classical CRTP [CRTP] to be used on links with only a few active flows per link (where TCRTP isn't efficient; see Section 3):
这样的设计还允许在每个链路上只有少量活动流的链路上使用经典CRTP[CRTP]（其中TCRTP效率不高；参见第3节）：
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
CRTP over IP TCRTP over IP RTP over IP
[voice GW]\ /[voice GW]
[voice GW]---[concentrator]---[concentrator]---[voice GW]
[voice GW]/ \[voice GW]
^ ^ ^
| | |
CRTP over IP TCRTP over IP RTP over IP
As described in [ECRTP], classical CRTP [CRTP] is not suitable over long-delay WAN links commonly used when tunneling, as proposed by this document. Thus, ECRTP should be used instead of CRTP.
如[ECRTP]中所述，经典的CRTP[CRTP]不适用于本文件提出的隧道时常用的长延迟WAN链路。因此，应使用ECRTP代替CRTP。
When the compressor receives an RTP packet that has an unpredicted change in the RTP header, the compressor should send a COMPRESSED_UDP packet (described in [ECRTP]) to synchronize the ECRTP decompressor state. The COMPRESSED_UDP packet updates the RTP context in the decompressor.
当压缩器接收到RTP报头中有不可预测变化的RTP数据包时，压缩器应发送压缩的UDP数据包（如[ECRTP]中所述），以同步ECRTP解压器状态。压缩的UDP数据包更新解压器中的RTP上下文。
To ensure delivery of updates of context variables, COMPRESSED_UDP packets should be delivered using the robust operation described in [ECRTP].
为确保上下文变量更新的交付，应使用[ECRTP]中描述的健壮操作交付压缩的_UDP数据包。
Because the "twice" algorithm described in [ECRTP] relies on UDP checksums, the IP stack on the RTP transmitter should transmit UDP checksums. If UDP checksums are not used, the ECRTP compressor should use the CRTP Headers checksum described in [ECRTP].
因为[ECRTP]中描述的“两次”算法依赖于UDP校验和，所以RTP发送器上的IP堆栈应该传输UDP校验和。如果未使用UDP校验和，ECRTP压缩器应使用[ECRTP]中所述的CRTP头校验和。
Tunneled transport does not guarantee ordered delivery of packets. Therefore, the ECRTP decompressor must operate correctly in the presence of out of order packets.
隧道传输不能保证数据包的有序传输。因此，ECRTP解压器必须在出现无序数据包的情况下正常工作。
The order of packets for RTP is determined by the RTP sequence number. To add robustness in case of packet loss or packet reordering, ECRTP sends short deltas together with the full value when updating context variables, and repeats the updates in N packets, where N is an engineered constant tuned to the kind of pipe ECRTP is used for.
RTP的数据包顺序由RTP序列号决定。为了在数据包丢失或数据包重新排序的情况下增加稳健性，ECRTP在更新上下文变量时发送短增量和完整值，并在N个数据包中重复更新，其中N是调整到ECRTP用于的管道类型的工程常量。
By contrast, [ROHC] compresses out the sequence number and another layer is necessary for [ROHC] to handle out-of-order delivery of packets over a tunnel [REORDER].
相比之下，[ROHC]压缩序列号，[ROHC]需要另一层来处理通过隧道[REORDER]无序交付的数据包。
Both CRTP and ECRTP require a layer two protocol that allows identifying different protocols. [PPP] is suited for this.
CRTP和ECRTP都需要第二层协议，允许识别不同的协议。[PPP]正适合这种情况。
When CRTP is used inside of a tunnel, the header compression associated with CRTP will reduce the size of the IP, UDP, and IP headers of the IP packet carried in the tunnel. However, the tunnel itself has overhead due to its IP header and the tunnel header (the information necessary to identify the tunneled payload). One way to reduce the overhead of the IP header and tunnel header is to multiplex multiple RTP payloads in a single tunneled packet.
当CRTP在隧道内使用时，与CRTP相关联的报头压缩将减小隧道中承载的IP数据包的IP、UDP和IP报头的大小。然而，由于其IP报头和隧道报头（识别隧道有效载荷所需的信息），隧道本身具有开销。减少IP报头和隧道报头开销的一种方法是在单个隧道数据包中多路复用多个RTP有效负载。
[PPP-MUX] describes an encapsulation that combines multiple PPP payloads into one multiplexed payload. PPP multiplexing allows any supported PPP payload type to be multiplexed. This multiplexed frame is then carried as a single PPPMUX payload in the IP tunnel. This allows multiple RTP payloads to be carried in a single IP tunnel packet and allows the overhead of the uncompressed IP and tunnel headers to be amortized over multiple RTP payloads.
[PPP-MUX]描述了将多个PPP有效负载组合成一个多路复用有效负载的封装。PPP多路复用允许多路复用任何受支持的PPP有效负载类型。然后，该多路复用帧作为单个PPPMUX有效载荷在IP隧道中承载。这允许在单个IP隧道数据包中承载多个RTP有效负载，并允许在多个RTP有效负载上分摊未压缩IP和隧道报头的开销。
During PPP establishment of the TCRTP tunnel, only LCP and IPCP (for header compression) are required -- IP addresses do not need to be negotiated, nor is authentication necessary. See Section 4.1 for details.
在TCRTP隧道的PPP建立过程中，只需要LCP和IPCP（用于报头压缩）——不需要协商IP地址，也不需要身份验证。详见第4.1节。
Section 1.2 of [PPP-MUX] describes an example transmitter procedure that can be used to implement a PPP Multiplex transmitter. The transmission procedure described in this section includes a parameter MAX-SF-LEN that is used to limit the maximum size of a PPP Multiplex frame.
[PPP-MUX]第1.2节描述了可用于实现PPP多路传输发射机的示例发射机程序。本节中描述的传输过程包括一个参数MAX-SF-LEN，该参数用于限制PPP多路复用帧的最大大小。
There are two reasons for limiting the size of a PPP Multiplex frame. First, a PPPMUX frame should never exceed the Maximum Receive Unit (MRU) of a physical link. Second, when a PPP session and its associated flow control are bound to a physical link, the MAX-SF-LEN parameter forms an upper limit on the amount of time a multiplex packet can be held before being transmitted. When flow control for the PPP Multiplex transmitter is bound to a physical link, the clock rate of the physical link can be used to pull frames from the PPP Multiplex transmitter.
限制PPP多路复用帧的大小有两个原因。首先，PPPMUX帧不应超过物理链路的最大接收单元（MRU）。第二，当PPP会话及其相关联的流控制绑定到物理链路时，MAX-SF-LEN参数形成多路复用分组在传输之前可以保持的时间量的上限。当PPP多路复用发送器的流控制绑定到物理链路时，物理链路的时钟速率可用于从PPP多路复用发送器提取帧。
This type of flow control limits the maximum amount of time a PPP multiplex frame can be held before being transmitted to MAX-SF-LEN / Link Speed.
这种类型的流量控制限制了PPP多路复用帧在传输到MAX-SF-LEN/链路速度之前可以保持的最大时间量。
Tunnel interfaces are typically not bound to physical interfaces. Because of this, a tunnel interface has no well-known transmission rate associated with it. This means that flow control in the PPPMUX transmitter cannot rely on the clock of a physical link to pull frames from the multiplex transmitter. Instead, a timer must be used to limit the amount of time a PPPMUX frame can be held before being transmitted. The timer along with the MAX-SF-LEN parameter should be used to limit the amount of time a PPPMUX frame is held before being transmitted.
隧道接口通常不绑定到物理接口。因此，隧道接口没有与之相关的已知传输速率。这意味着PPPMUX发射机中的流量控制不能依赖物理链路的时钟从多路复用发射机中提取帧。相反，必须使用计时器来限制PPPMUX帧在传输之前可以保持的时间量。应使用定时器和MAX-SF-LEN参数来限制PPPMUX帧在传输前保持的时间量。
The following extensions to the PPPMUX transmitter logic should be made for use with tunnels. The flow control logic of the PPP transmitter should be modified to collect incoming payloads until one of two events has occurred:
PPPMUX变送器逻辑的以下扩展应用于隧道。应修改PPP变送器的流量控制逻辑，以收集传入的有效载荷，直到发生以下两个事件之一：
(1) a specific number of octets, MAX-SF-LEN, has arrived at the multiplexer, or
(1) 特定数量的八位字节MAX-SF-LEN已到达多路复用器，或
(2) a timer, called T, has expired.
(2) 一个名为T的计时器已过期。
When either condition is satisfied, the multiplexed PPP payload is transmitted.
当任一条件满足时，多路复用的PPP有效载荷被传输。
The purpose of MAX-SF-LEN is to ensure that a PPPMUX payload does not exceed the MTU size of any of the possible physical links that the tunnel can be associated with. The value of MAX-SF-LEN should be less than or equal to the minimum of MRU-2 (maximum size of length field) and 16,383 (14 bits) for all possible physical interfaces that the tunnel may be associated with.
MAX-SF-LEN的目的是确保PPPMUX有效负载不超过隧道可关联的任何可能物理链路的MTU大小。对于隧道可能关联的所有可能物理接口，MAX-SF-LEN的值应小于或等于MRU-2（长度字段的最大大小）和16383（14位）中的最小值。
The timer T provides an upper delay bound for tunnel interfaces. Timer T is reset whenever a multiplexed payload is sent to the next encapsulation layer. The behavior of this timer is similar to AAL2's Timer_CU described in [I.363.2]. Each PPPMUX transmitter should have its own Timer T.
定时器T为隧道接口提供了一个延迟上限。每当多路复用的有效载荷被发送到下一封装层时，定时器T被重置。该计时器的行为类似于[I.363.2]中描述的AAL2的计时器。每个PPPMUX发射机应有自己的定时器T。
The optimal values for T will vary depending upon the rate at which payloads are expected to arrive at the multiplexer and the delay budget for the multiplexing function. For voice applications, the value of T would typically be 5-10 milliseconds.
T的最佳值将根据预期有效负载到达复用器的速率和复用功能的延迟预算而变化。对于语音应用程序，T的值通常为5-10毫秒。
To get reasonable bandwidth efficiency using multiplexing within an L2TP tunnel, multiple RTP streams should be active between the source and destination of an L2TP tunnel.
为了在L2TP隧道内使用多路复用获得合理的带宽效率，在L2TP隧道的源和目标之间应该有多个RTP流处于活动状态。
If the source and destination of the L2TP tunnel are the same as the source and destination of the ECRTP sessions, then the source and destination must have multiple active RTP streams to get any benefit from multiplexing.
如果L2TP隧道的源和目的地与ECRTP会话的源和目的地相同，则源和目的地必须具有多个活动RTP流才能从多路复用中获益。
Because of this limitation, TCRTP is mostly useful for applications where many RTP sessions run between a pair of RTP endpoints. The number of simultaneous RTP sessions required to reduce the header overhead to the desired level depends on the size of the L2TP header. A smaller L2TP header will result in fewer simultaneous RTP sessions being required to produce bandwidth efficiencies similar to CRTP.
由于这个限制，TCRTP对于在一对RTP端点之间运行多个RTP会话的应用程序最为有用。将报头开销降低到所需水平所需的同步RTP会话数取决于L2TP报头的大小。较小的L2TP报头将导致产生类似于CRTP的带宽效率所需的同步RTP会话更少。
L2TP tunnels should be used to tunnel the ECRTP payloads end to end. L2TP includes methods for tunneling messages used in PPP session establishment, such as NCP. This allows [IPCP-HC] to negotiate ECRTP compression/decompression parameters.
L2TP隧道应用于端到端的ECRTP有效载荷隧道。L2TP包括用于PPP会话建立中使用的隧道消息的方法，例如NCP。这允许[IPCP-HC]协商ECRTP压缩/解压缩参数。
RTP streams may be marked with Expedited Forwarding (EF) bits, as described in [EF-PHB]. When such a packet is tunneled, the tunnel header must also be marked for the same EF bits, as required by [EF-PHB]. It is important to not mix EF and non-EF traffic in the same EF-marked multiplexed tunnel.
RTP流可以用加速转发（EF）位标记，如[EF-PHB]中所述。当这样的数据包被隧道化时，隧道头也必须按照[EF-PHB]的要求标记为相同的EF位。重要的是，不要在同一个EF标记的多路复用隧道中混合EF和非EF流量。
The packet format for an RTP packet, compressed with RTP header compression as defined in ECRTP, is:
按照ECRTP中的定义，使用RTP报头压缩压缩的RTP数据包的数据包格式为：
+---------+---------+-------------+-----------------------+
| | MSTI | | |
| Context | | UDP | |
| ID | Link | Checksum | RTP Data |
| | Sequence| | |
| (1-2) | (1) | (0-2) | |
+---------+---------+-------------+-----------------------+
+---------+---------+-------------+-----------------------+
| | MSTI | | |
| Context | | UDP | |
| ID | Link | Checksum | RTP Data |
| | Sequence| | |
| (1-2) | (1) | (0-2) | |
+---------+---------+-------------+-----------------------+
The packet format of a multiplexed PPP packet as defined by [PPP-MUX] is:
由[PPP-MUX]定义的多路复用PPP分组的分组格式为：
+-------+---+------+-------+-----+ +---+------+-------+-----+
| Mux |P L| | | | |P L| | | |
| PPP |F X|Len1 | PPP | | |F X|LenN | PPP | |
| Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN|
| Field | | Field1| | | |FieldN | |
| (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | |
+-------+----------+-------+-----+ +----------+-------+-----+
+-------+---+------+-------+-----+ +---+------+-------+-----+
| Mux |P L| | | | |P L| | | |
| PPP |F X|Len1 | PPP | | |F X|LenN | PPP | |
| Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN|
| Field | | Field1| | | |FieldN | |
| (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | |
+-------+----------+-------+-----+ +----------+-------+-----+
The combined format used for TCRTP with a single payload is all of the above packets concatenated. Here is an example with one payload:
用于TCRTP和单个有效负载的组合格式是将上述所有数据包连接起来的。下面是一个具有一个有效负载的示例：
+------+-------+----------+-------+-------+-----+-------+----+
| IP | Mux |P L| | | | MSTI| | |
|header| PPP |F X|Len1 | PPP |Context| | UDP |RTP |
| (20) | Proto |F T| | Proto | ID | Link| Cksum |Data|
| | Field | | Field1| | Seq | | |
| | (1) |1-2 octets| (0-2) | (1-2) | (1) | (0-2) | |
+------+-------+----------+-------+-------+-----+-------+----+
|<------------- IP payload ------------------------->|
|<----- PPPmux payload --------------------->|
+------+-------+----------+-------+-------+-----+-------+----+
| IP | Mux |P L| | | | MSTI| | |
|header| PPP |F X|Len1 | PPP |Context| | UDP |RTP |
| (20) | Proto |F T| | Proto | ID | Link| Cksum |Data|
| | Field | | Field1| | Seq | | |
| | (1) |1-2 octets| (0-2) | (1-2) | (1) | (0-2) | |
+------+-------+----------+-------+-------+-----+-------+----+
|<------------- IP payload ------------------------->|
|<----- PPPmux payload --------------------->|
If the tunnel contains multiplexed traffic, multiple "PPPMux payload"s are transmitted in one IP packet.
如果隧道包含多路复用业务，则在一个IP数据包中传输多个“PPPMux有效负载”。
The expected bandwidth efficiency attainable with TCRTP depends upon a number of factors. These factors include multiplexing gain, expected packet loss rate across the network, and rates of change of specific fields within the IP and RTP headers. This section also describes how TCRTP significantly enhances bandwidth efficiency for voice over IP over ATM.
TCRTP所能达到的预期带宽效率取决于许多因素。这些因素包括多路复用增益、网络中的预期分组丢失率以及IP和RTP报头中特定字段的变化率。本节还介绍了TCRTP如何显著提高ATM上IP语音的带宽效率。
Multiplexing reduces the overhead associated with the layer 2 and tunnel headers. Increasing the number of CRTP payloads combined into one multiplexed PPP payload increases multiplexing gain. As traffic increases within a tunnel, more payloads are combined in one multiplexed payload. This will increase multiplexing gain.
多路复用减少了与第2层和隧道头相关的开销。增加合并到一个复用PPP有效载荷中的CRTP有效载荷的数量会增加复用增益。随着隧道内通信量的增加，更多的有效负载组合在一个多路复用的有效负载中。这将增加多路复用增益。
Loss of a multiplexed packet causes packet loss for all of the flows within the multiplexed packet.
复用分组的丢失导致复用分组内的所有流的分组丢失。
When the expected loss rate in a tunnel is relatively low (less than perhaps 5%), the robust operation (described in [ECRTP]) should be sufficient to ensure delivery of state changes. This robust operation is characterized by a parameter N, which means that the probability of more than N adjacent packets getting lost on the tunnel is small.
当隧道中的预期损失率相对较低（小于5%）时，稳健运行（如[ECRTP]所述）应足以确保状态变化的交付。这种鲁棒操作的特征是参数N，这意味着在隧道中丢失N个以上相邻数据包的概率很小。
A value of N=1 will protect against the loss of a single packet within a compressed session, at the expense of bandwidth. A value of N=2 will protect against the loss of two packets in a row within a compressed session and so on. Higher values of N have higher bandwidth penalties.
N=1的值将以牺牲带宽为代价防止压缩会话中单个数据包的丢失。N=2的值将防止在压缩会话中丢失一行中的两个数据包，以此类推。N值越高，带宽损失越大。
The optimal value of N will depend on the loss rate in the tunnel. If the loss rate is high (above perhaps 5%), more advanced techniques must be employed. Those techniques are beyond the scope of this document.
N的最佳值取决于隧道中的损失率。如果损失率很高（可能超过5%），则必须采用更先进的技术。这些技术超出了本文档的范围。
The following formula uses the factors described above to model per-flow bandwidth usage for both voice and video applications. These variables are defined:
下面的公式使用上述因素对语音和视频应用程序的每流带宽使用情况进行建模。这些变量定义如下：
SOV-TCRTP, unit: octet. Per-payload overhead of ECRTP and the multiplexed PPP header. This value does not include additional overhead for updating IP ID or the RTP Time Stamp fields (see [ECRTP] for details on IP ID). The value assumes the use of the COMPRESSED_RTP payload type. It consists of 1 octet for the ECRTP context ID, 1 octet for COMPRESSED_RTP flags, 2 octets for the UDP checksum, 1 octet for PPP protocol ID, and 1 octet for the multiplexed PPP length field. The total is 6 octets.
SOV-TCRTP，单位：八位字节。ECRTP和多路复用PPP报头的每有效负载开销。此值不包括更新IP ID或RTP时间戳字段的额外开销（有关IP ID的详细信息，请参阅[ECRTP]）。该值假定使用压缩的RTP有效负载类型。它包括1个八位字节用于ECRTP上下文ID，1个八位字节用于压缩RTP标志，2个八位字节用于UDP校验和，1个八位字节用于PPP协议ID，1个八位字节用于多路传输PPP长度字段。总共是6个八位组。
POV-TCRTP, unit: octet. Per-packet overhead of tunneled ECRTP. This is the overhead for the tunnel header and the multiplexed PPP payload type. This value is 20 octets for the IP header, 4 octets for the L2TPv3 header and 1 octet for the multiplexed PPP protocol ID. The total is 25 octets.
POV-TCRTP，单位：八位字节。隧道ECRTP的每包开销。这是隧道头和多路复用PPP有效负载类型的开销。该值为IP报头20个八位字节，L2TPv3报头4个八位字节，多路传输PPP协议ID 1个八位字节。总共25个八位字节。
TRANSMIT-LENGTH, unit: milliseconds. The average duration of a transmission (such as a talk spurt for voice streams).
传输长度，单位：毫秒。传输的平均持续时间（如语音流的通话爆发）。
SOV-TSTAMP, unit: octet. Additional per-payload overhead of the COMPRESSED_UDP header that includes the absolute time stamp field. This value includes 1 octet for the extra flags field in the COMPRESSED_UDP header and 4 octets for the absolute time stamp, for a total of 5 octets.
SOV-TSTAMP，单位：八位字节。包含绝对时间戳字段的压缩_UDP报头的额外每有效负载开销。该值包括1个八位字节用于压缩的UDP报头中的额外标志字段，4个八位字节用于绝对时间戳，总共5个八位字节。
SOV-IPID, unit: octet. Additional per-payload overhead of the COMPRESSED_UDP header that includes the absolute IPID field. This value includes 2 octets for the absolute IPID. This value also includes 1 octet for the extra flags field in the COMPRESSED_UDP header. The total is 3 octets.
SOV-IPID，单位：八位字节。包括绝对IPID字段的压缩的_UDP报头的额外每有效负载开销。该值包括绝对IPID的2个八位字节。该值还包括1个八位字节，用于压缩的UDP头中的额外标志字段。总共是3个八位组。
IPID-RATIO, unit: integer values 0 or 1. Indicates the frequency at which IPID will be updated by the compressor. If IPID is changing randomly and thus always needs to be updated, then the value is 1. If IPID is changing by a fixed constant amount between payloads of a flow, then IPID-RATIO will be 0. The value of this variable does not consider the IPID value at the beginning of a voice or video transmission, as that is considered by the variable TRANSMIT-LENGTH. The implementation of the sending IP stack and RTP application controls this behavior. See Section 1.1.
IPID比率，单位：整数值0或1。指示压缩机将更新IPID的频率。如果IPID随机变化，因此始终需要更新，则该值为1。如果IPID在流的有效负载之间以固定的常量变化，则IPID比率将为0。该变量的值不考虑在语音或视频传输开始时的IPID值，如可变传输长度所考虑的。发送IP堆栈和RTP应用程序的实现控制此行为。见第1.1节。
NREP, unit: integer (usually a number between 1 and 3). This is the number of times an update field will be repeated in ECRTP headers to increase the delivery rate between the compressor and decompressor. For this example, we will assume NREP=2.
NREP，单位：整数（通常是介于1和3之间的数字）。这是在ECRTP标头中重复更新字段以增加压缩机和减压器之间的传递速率的次数。对于本例，我们假设NREP=2。
PAYLOAD-SIZE, unit: octets. The size of the RTP payload in octets.
有效载荷大小，单位：八位字节。RTP有效负载的大小（以八位字节为单位）。
MUX-SIZE, unit: count. The number of PPP payloads multiplexed into one multiplexed PPP payload.
多路复用器大小，单位：计数。多路复用到一个多路复用PPP有效负载中的PPP有效负载数。
SAMPLE-PERIOD, unit: milliseconds. The average delay between transmissions of voice or video payloads for each flow in the multiplex. For example, in voice applications the value of this variable would be 10ms if all calls have a 10ms sample period.
采样周期，单位：毫秒。多路复用中每个流的语音或视频有效负载传输之间的平均延迟。例如，在语音应用程序中，如果所有呼叫的采样周期均为10ms，则此变量的值为10ms。
The formula is:
公式是：
SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD /
TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO
SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD /
TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO
BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) *
8) / SAMPLE-PERIOD)
BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) *
8) / SAMPLE-PERIOD)
The results are:
结果是：
BANDWIDTH, unit: kilobits per second. The average amount of bandwidth used per voice or video flow.
带宽，单位：千比特每秒。每个语音或视频流使用的平均带宽量。
SOV-TOTAL = The total amount of per-payload overhead associated with tunneled ECRTP. It includes the per-payload overhead of ECRTP and PPP, timestamp update overhead, and IPID update overhead.
SOV-TOTAL=与隧道ECRTP相关的每个有效负载开销的总量。它包括ECRTP和PPP的每有效负载开销、时间戳更新开销和IPID更新开销。
To create an example for a voice application using the above formulas, we will assume the following usage scenario. Compressed voice streams using G.729 compression with a 20 millisecond packetization period. In this scenario, VAD is enabled and the average talk spurt length is 1500 milliseconds. The IPID field is changing randomly between payloads of streams. There is enough traffic in the tunnel to allow 3 multiplexed payloads. The following values apply:
为了使用上述公式为语音应用程序创建一个示例，我们将假设以下使用场景。使用G.729压缩并具有20毫秒打包周期的压缩语音流。在此场景中，VAD已启用，平均通话爆发长度为1500毫秒。IPID字段在流的有效负载之间随机变化。隧道中有足够的通信量，允许3个多路复用有效载荷。以下值适用：
SAMPLE-PERIOD = 20 milliseconds TRANSMIT-LENGTH = 1500 milliseconds IPID-RATIO = 1 PAYLOAD-SIZE = 20 octets MUX-SIZE = 3
采样周期=20毫秒传输长度=1500毫秒IPID比率=1有效负载大小=20八位字节MUX大小=3
For this example, per call bandwidth is 16.4 kbits/sec. Classical CRTP over a single HDLC link using the same factors as above yields 12.4 kbits/sec.
对于本例，每次呼叫带宽为16.4 kbits/sec。使用与上述相同的因子，单个HDLC链路上的经典CRTP产生12.4 kbits/sec。
The effect of IPID can have a large effect on per call bandwidth. If the above example is recalculated using an IPID-RATIO of 0, then the per call bandwidth is reduced to 13.8 kbits/sec. Classical CRTP over a single HDLC link, using these same factors, yields 11.2 kbits/call.
IPID的影响会对每次呼叫的带宽产生很大的影响。如果使用0的IPID比率重新计算上述示例，则每次呼叫带宽将减少到13.8 kbits/sec。使用这些相同的因素，单个HDLC链路上的经典CRTP产生11.2kbit/呼叫。
The bandwidth values are as follows when using 5 simultaneous calls, no voice activity detection (VAD), G.729 with 20ms packetization interval, and not considering RTCP overhead:
当使用5个同时呼叫、无语音活动检测（VAD）、G.729和20ms分组间隔且不考虑RTCP开销时，带宽值如下：
Normal VoIP over PPP: 124 kbps
with classical CRTP on a link: 50 kbps (savings: 59%)
with TCRTP over PPP: 62 kbps (savings: 50%)
with TCRTP over AAL5: 85 kbps (savings: 31%)
Normal VoIP over PPP: 124 kbps
with classical CRTP on a link: 50 kbps (savings: 59%)
with TCRTP over PPP: 62 kbps (savings: 50%)
with TCRTP over AAL5: 85 kbps (savings: 31%)
Since TCRTP can be used to save bandwidth on any type of RTP encapsulated flow, it can be used to save bandwidth for video applications. This section documents an example of TCRTP-based bandwidth savings for MPEG-2 encoded video.
由于TCRTP可用于在任何类型的RTP封装流上节省带宽，因此它可用于为视频应用程序节省带宽。本节介绍了基于TCRTP的MPEG-2编码视频带宽节约示例。
To create an example for a video application using the above formulas, we will assume the following usage scenario. RTP encapsulation of MPEG System and Transport Streams is performed as described in RFC 2250. Frames for MPEG-2 encoded video are sent continuously, so the TRANSMIT-LENGTH variable in the bandwidth formula is essentially infinite. The IPID field is changing randomly between payloads of streams. There is enough traffic in the tunnel to allow 3 multiplexed payloads. The following values apply:
为了使用上述公式为视频应用程序创建一个示例，我们将假设以下使用场景。MPEG系统和传输流的RTP封装如RFC 2250中所述执行。MPEG-2编码视频的帧是连续发送的，因此带宽公式中的传输长度变量本质上是无限的。IPID字段在流的有效负载之间随机变化。隧道中有足够的通信量，允许3个多路复用有效载荷。以下值适用：
SAMPLE-PERIOD = 2.8 milliseconds TRANSMIT-LENGTH = infinite IPID-RATIO = 1 PAYLOAD-SIZE = 1316 octets MUX-SIZE = 3
采样周期=2.8毫秒传输长度=无限IPID比率=1有效负载大小=1316个八位字节MUX大小=3
For this example, per flow bandwidth is 3.8 Mbits/sec. MPEG video with no header compression, using the same factors as above, yields 3.9 Mbits/sec. While TCRTP does provide some bandwidth savings for video, the ratio of transmission headers to payload is so small that the bandwidth savings are insignificant.
对于本例，每流带宽为3.8 Mbits/sec。不使用头压缩的MPEG视频，使用与上述相同的因子，产生3.9 Mbits/秒。虽然TCRTP确实为视频提供了一些带宽节约，但传输头与有效负载的比率非常小，因此带宽节约微不足道。
IP transport over AAL5 causes a quantizing effect on bandwidth utilization due to the packets always being multiples of ATM cells.
AAL5上的IP传输会对带宽利用率产生量化影响，因为数据包总是ATM信元的倍数。
For example, the payload size for G.729 using 10 millisecond packetization intervals is 10 octets. This is much smaller than the payload size of an ATM cell (48 octets). When classical CRTP [CRTP] is used on a link-by-link basis, the IP overhead to payload ratio is quite good. However, AAL5 encapsulation and its cell padding always force the minimum payload size to be one ATM cell, which results in poor bandwidth utilization.
例如，使用10毫秒打包间隔的G.729的有效负载大小是10个八位字节。这比ATM信元的有效负载大小（48个八位字节）小得多。当在逐链路的基础上使用经典的CRTP[CRTP]时，IP开销与有效负载的比率相当好。然而，AAL5封装及其信元填充总是强制最小有效负载大小为一个ATM信元，这会导致较差的带宽利用率。
Instead of wasting this padding, the multiplexing of TCRTP allows this previously wasted space in the ATM cell to contain useful data. This is one of the main reasons why multiplexing has such a large effect on bandwidth utilization with Voice over IP over ATM.
TCRTP的多路复用允许ATM信元中先前浪费的空间包含有用的数据，而不是浪费这种填充。这是复用对ATM上IP语音带宽利用率有如此大影响的主要原因之一。
This multiplexing efficiency of TCRTP is similar to AAL2 sub-cell multiplexing described in [I.363.2]. Unlike AAL2 sub-cell multiplexing, however, TCRTP's multiplexing efficiency isn't limited to only ATM networks.
TCRTP的复用效率类似于[I.363.2]中描述的AAL2子小区复用。然而，与AAL2子小区复用不同，TCRTP的复用效率不仅限于ATM网络。
When TCRTP is used with other layer 2 encapsulations that do not have a minimum PDU size, the benefit of multiplexing is not as great.
当TCRTP与其他没有最小PDU大小的第2层封装一起使用时，多路复用的好处就没有那么大了。
Depending upon the exact overhead of the layer 2 encapsulation, the benefit of multiplexing might be slightly better or worse than link-by-link CRTP header compression. The per-payload overhead of CRTP tunneling is either 4 or 6 octets. If classical CRTP plus layer 2 overhead is greater than this amount, TCRTP multiplexing will consume less bandwidth than classical CRTP when the outer IP header is amortized over a large number of payloads.
根据第2层封装的确切开销，多路复用的好处可能比逐链路CRTP报头压缩略好或略差。CRTP隧道的每有效负载开销为4或6个八位字节。如果经典CRTP加上第2层开销大于此值，则当外部IP报头在大量有效负载上摊销时，TCRTP多路复用将消耗比经典CRTP更少的带宽。
The payload breakeven point can be determined by the following formula:
有效载荷盈亏平衡点可通过以下公式确定：
POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX
* MUX-SIZE
POV-L2 * MUX-SIZE >= POV-L2 + POV-TUNNEL + POV-PPPMUX + SOV-PPPMUX
* MUX-SIZE
Where:
哪里：
POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC encapsulation
POV-L2，单位：八位字节。第2层数据包开销：5个八位字节用于HDLC封装
POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 24 octets IP header and L2TPv3 header
POV-隧道，单位：八隅体。隧道导致的数据包开销：24个八位字节的IP头和L2TPv3头
POV-PPPMUX, unit: octet. Packet overhead for the multiplexed PPP protocol ID: 1 octet
POV-PPPMUX，单位：八位字节。多路复用PPP协议ID的数据包开销：1个八位字节
SOV-PPPMUX, unit: octet. Per-payload overhead of PPPMUX, which is comprised of the payload length field and the ECRTP protocol ID. The value of SOV-PPPMUX is typically 1, 2, or 3.
SOV-PPPMUX，单位：八位字节。PPPMUX的每有效负载开销，由有效负载长度字段和ECRTP协议ID组成。SOV-PPPMUX的值通常为1、2或3。
If using HDLC as the layer 2 protocol, the breakeven point (using the above formula) is when MUX-SIZE = 7. Thus 7 voice or video flows need to be multiplexed to make TCRTP as bandwidth-efficient as link-by-link CRTP compression.
如果使用HDLC作为第2层协议，则盈亏平衡点（使用上述公式）为MUX-SIZE=7。因此，需要对7个语音或视频流进行多路复用，以使TCRTP与逐链路CRTP压缩一样具有带宽效率。
This section describes an example implementation of TCRTP. Implementations of TCRTP may be done in many ways as long as the requirements of the associated RFCs are met.
本节描述了TCRTP的一个示例实现。只要满足相关RFC的要求，就可以通过多种方式实现TCRTP。
Here is the path an RTP packet takes in this implementation:
以下是RTP数据包在此实现中的路径：
+-------------------------------+ ^
| Application | |
+-------------------------------+ |
| RTP | |
+-------------------------------+ Application and
| UDP | IP stack
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| ECRTP | |
+-------------------------------+ |
| PPPMUX | |
+-------------------------------+ Tunnel
| PPP | Interface
+-------------------------------+ |
| L2TP | |
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| Layer 2 | |
+-------------------------------+ Physical
| Physical | Interface
+-------------------------------+ V
+-------------------------------+ ^
| Application | |
+-------------------------------+ |
| RTP | |
+-------------------------------+ Application and
| UDP | IP stack
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| ECRTP | |
+-------------------------------+ |
| PPPMUX | |
+-------------------------------+ Tunnel
| PPP | Interface
+-------------------------------+ |
| L2TP | |
+-------------------------------+ |
| IP | |
+-------------------------------+ V
|
| IP forwarding
|
+-------------------------------+ ^
| Layer 2 | |
+-------------------------------+ Physical
| Physical | Interface
+-------------------------------+ V
A protocol stack is configured to create an L2TP tunnel interface to a destination host. The tunnel is configured to negotiate the PPP connection (using NCP IPCP) with ECRTP header compression and PPPMUX. IP forwarding is configured to route RTP packets to this tunnel. The destination UDP port number could distinguish RTP packets from non-RTP packets.
协议栈配置为创建到目标主机的L2TP隧道接口。隧道配置为通过ECRTP头压缩和PPPMUX协商PPP连接（使用NCP IPCP）。IP转发配置为将RTP数据包路由到此隧道。目标UDP端口号可以区分RTP数据包和非RTP数据包。
The transmitting application gathers the RTP data from one source, and formats an RTP packet. Lower level application layers add UDP and IP headers to form a complete IP packet.
传输应用程序从一个源收集RTP数据，并格式化RTP数据包。较低级别的应用程序层添加UDP和IP报头以形成完整的IP数据包。
The RTP packets are routed to the tunnel interface where headers are compressed, payloads are multiplexed, and then the packets are tunneled to the destination host.
RTP数据包被路由到隧道接口，在那里头被压缩，有效负载被多路复用，然后数据包被隧道传输到目标主机。
The operation of the receiving node is the same as the transmitting node in reverse.
接收节点的操作与发送节点的操作相反。
This section describes the necessary PPP and LT2P negotiations necessary for establishing a PPP connection and L2TP tunnel with L2TP header compression. The negotiation is between two peers: Peer1 and Peer2.
本节描述了建立PPP连接和L2TP头压缩L2TP隧道所需的PPP和LT2P协商。协商是在两个对等方之间进行的：Peer1和Peer2。
The Point-to-Point Protocol is described in [PPP].
点对点协议如[PPP]所述。
Link Control Processing (LCP) is described in [PPP].
链路控制处理（LCP）在[PPP]中描述。
Peer1 Peer2
----- -----
Configure-Request (no options) ->
<- Configure-Ack
<- Configure-Request (no options)
Configure-Ack ->
Peer1 Peer2
----- -----
Configure-Request (no options) ->
<- Configure-Ack
<- Configure-Request (no options)
Configure-Ack ->
Terminate-Request -> <- Terminate-Ack
终止请求-><-终止确认
The protocol exchange here is described in [IPHCOMP], [PPP], and [ECRTP].
[IPHCOMP]、[PPP]和[ECRTP]中描述了此处的协议交换。
Peer1 Peer2
----- -----
Configure-Request ->
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
<- Configure-Ack
<- Configure-Request
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
Configure-Ack ->
Peer1 Peer2
----- -----
Configure-Request ->
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
<- Configure-Ack
<- Configure-Request
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
Configure-Ack ->
L2TP is described in [L2TPv3].
L2TP在[L2TPv3]中进行了描述。
Peer1 Peer2
----- -----
SCCRQ ->
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
<- SCCRP
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
SCCCN ->
Mandatory AVP's:
Message Type
<- ZLB
Peer1 Peer2
----- -----
SCCRQ ->
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
<- SCCRP
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
SCCCN ->
Mandatory AVP's:
Message Type
<- ZLB
Peer1 Peer2
----- -----
ICRQ ->
Mandatory AVP's:
Message Type
Assigned Session ID
Call Serial Number
<- ICRP
Mandatory AVP's:
Message Type
Assigned Session ID
ICCN ->
Mandatory AVP's:
Message Type
Tx (Connect Speed)
Framing Type
<- ZLB
Peer1 Peer2
----- -----
ICRQ ->
Mandatory AVP's:
Message Type
Assigned Session ID
Call Serial Number
<- ICRP
Mandatory AVP's:
Message Type
Assigned Session ID
ICCN ->
Mandatory AVP's:
Message Type
Tx (Connect Speed)
Framing Type
<- ZLB
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
This document describes a method for combining several existing protocols that implement compression, multiplexing, and tunneling of RTP streams. Attacks on the component technologies of TCRTP include attacks on RTP/RTCP headers and payloads carried within a TCRTP session, attacks on the compressed headers, attacks on the multiplexing layer, or attacks on the tunneling negotiation or transport. The security issues associated individually with each of those component technologies are addressed in their respective specifications, [ECRTP], [PPP-MUX], [L2TPv3], along with the security considerations for RTP itself [RTP].
本文档描述了一种结合几种现有协议的方法，这些协议实现RTP流的压缩、多路复用和隧道传输。对TCRTP组件技术的攻击包括对RTP/RTCP头和TCRTP会话中承载的有效负载的攻击、对压缩头的攻击、对复用层的攻击或对隧道协商或传输的攻击。与这些组件技术各自相关的安全问题在各自的规范[ECRTP]、[PPP-MUX]、[L2TPv3]中以及RTP本身的安全注意事项[RTP]中进行了阐述。
However, there may be additional security considerations arising from the use of these component technologies together. For example, there may be an increased risk of unintended misdelivery of packets from one stream in the multiplex to another due to a protocol malfunction or data error because the addressing information is more condensed. This is particularly true if the tunnel is transmitted over a link-layer protocol that allows delivery of packets containing bit errors, in combination with a tunnel transport layer option that does not checksum all of the payload.
但是，在一起使用这些组件技术时可能会产生额外的安全考虑。例如，由于寻址信息更加浓缩，因此由于协议故障或数据错误，可能会增加从复用中的一个流到另一个流的分组的非预期误发的风险。如果隧道通过链路层协议传输，该协议允许传输包含比特错误的分组，并且结合不校验所有有效负载的隧道传输层选项，则这一点尤其正确。
The opportunity for malicious misdirection may be increased, relative to that for a single RTP stream transported by itself, because addressing information must be unencrypted for the header compression and multiplexing layers to function.
与自身传输的单个RTP流相比，恶意误导的机会可能会增加，因为寻址信息必须是未加密的，报头压缩层和多路复用层才能正常工作。
The primary defense against misdelivery is to make the data unusable to unintended recipients through cryptographic techniques. The basic method for encryption provided in the RTP specification [RTP] is not suitable because it encrypts the RTP and RTCP headers along with the payload. However, the RTP specification also allows alternative approaches to be defined in separate profile or payload format specifications wherein only the payload portion of the packet would be encrypted; therefore, header compression may be applied to the encrypted packets. One such profile, [SRTP], provides more
防止误发的主要防御措施是通过加密技术使数据对非预期接收者不可用。RTP规范[RTP]中提供的基本加密方法不适用，因为它将RTP和RTCP头与有效负载一起加密。然而，RTP规范还允许在单独的简档或有效载荷格式规范中定义替代方法，其中只有分组的有效载荷部分将被加密；因此，可以将报头压缩应用于加密的分组。一个这样的配置文件[SRTP]提供了更多信息
sophisticated and complete methods for encryption and message authentication than the basic approach in [RTP]. Additional methods may be developed in the future. Appropriate cryptographic protection should be incorporated into all TCRTP applications.
与[RTP]中的基本方法相比，用于加密和消息身份验证的复杂而完整的方法。将来可能会开发其他方法。应在所有TCRTP应用程序中纳入适当的加密保护。
The authors would like to thank the authors of RFC 2508, Stephen Casner and Van Jacobson, and the authors of RFC 2507, Mikael Degermark, Bjorn Nordgren, and Stephen Pink.
作者要感谢RFC 2508的作者Stephen Casner和Van Jacobson，以及RFC 2507的作者Mikael Degermark、Bjorn Nordgren和Stephen Pink。
The authors would also like to thank Dana Blair, Alex Tweedley, Paddy Ruddy, Francois Le Faucheur, Tim Gleeson, Matt Madison, Hussein Salama, Mallik Tatipamula, Mike Thomas, Mark Townsley, Andrew Valencia, Herb Wildfeuer, J. Martin Borden, John Geevarghese, and Shoou Yiu.
作者还要感谢达娜·布莱尔、亚历克斯·特威德利、帕迪·鲁迪、弗朗索瓦·勒·福彻、蒂姆·格莱森、马特·麦迪逊、侯赛因·萨拉马、马利克·塔蒂帕穆拉、迈克·托马斯、马克·汤斯利、安德鲁·巴伦西亚、赫伯·维尔德费尔、J·马丁·博登、约翰·格瓦尔盖斯和肖欧·姚。
[PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", RFC 3153, August 2001.
[PPP-MUX]Pazhyannur，R.，Ali，I.，和C.Fox，“PPP多路复用”，RFC 3153，2001年8月。
[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月。
[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月。
[IPHCOMP] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHCOMP]Degermark，M.，Nordgren，B.，和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP Header Compression over PPP", RFC 3544, July 2003.
[IPCP-HC]Engan，M.，Casner，S.，Bormann，C.，和T.Koren，“PPP上的IP头压缩”，RFC 35442003年7月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RTP]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[L2TPv3]Lau，J.，Townsley，M.，和I.Goyret，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年3月。
[I.363.2] ITU-T, "B-ISDN ATM Adaptation layer specification: Type 2 AAL", I.363.2, September 1997.
[I.363.2]ITU-T，“B-ISDN ATM适配层规范：第2类AAL”，I.363.2，1997年9月。
[EF-PHB] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
[EF-PHB]Davie，B.，Charny，A.，Bennet，J.C.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 32462002年3月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[SRTP]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[REORDER] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", Work in Progress, June 2004.
[重新排序]G.Pelletier，L.Jonsson，K.Sandlund，“鲁棒头压缩（ROHC）：可以重新排序数据包的信道上的ROHC”，正在进行的工作，2004年6月。
[ROHC] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001.
[ROHC]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP和未压缩”，RFC 3095，2001年7月。
Authors' Addresses
作者地址
Bruce Thompson 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
布鲁斯·汤普森美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1 408 527 0446
EMail: brucet@cisco.com
Phone: +1 408 527 0446
EMail: brucet@cisco.com
Tmima Koren 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: +1 408 527 6169
EMail: tmima@cisco.com
Phone: +1 408 527 6169
EMail: tmima@cisco.com
Dan Wing 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
美国加利福尼亚州圣何塞市西塔斯曼大道170号丹翼，邮编95134-1706
EMail: dwing@cisco.com
EMail: dwing@cisco.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编辑功能的资金目前由互联网协会提供。