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)
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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）音声トランクのように、2つのエンドポイント間に並列ストリームを搬送するネットワーク経路上にストリームを向上させる方法が記載されています。方法は、複数の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
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（圧縮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.
多くによって未確認は、しかし、長距離WANリンクのコストです。 （両方の技術は、IP、UDP、およびRTPヘッダを欠いているため）、帯域幅効率を提供し、このようなMPLSオーバーATMボイスオーバー（するVoAAL2、[I. 363.2]）や音声などの一部のボイス・オーバー・パケット・テクノロジーが、VoATMのもVoMPLSどちらも直接アクセスを提供しますボイスオーバーパケットにボイスオーバーIPが利用できるサービスを。このように、WANリンクのコスト削減の目標は、他のネットワークへの失われた相互接続の機会を犠牲にして満たされています。
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.
1つのストリームだけが（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.
こうしたIPボイスオーバーなどのRTPアプリケーションのために帯域幅を節約するために、強化されたCRTP、PPP多重化、およびL2TPトンネリング：このセクションでは、3つのプロトコルを結合する方法を説明します。
TCRTP can typically be implemented in two ways. The most straightforward is to implement TCRTP in the gateways terminating the RTP streams:
TCRTPは、典型的には2つの方法で実装することができます。最も簡単にはRTPストリームを終端ゲートウェイでTCRTPを実装することです：
[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を実現することができるもう一つの方法は、外部の濃縮装置です。このデバイスは、ネットワーク内の戦略的な場所に配置することができ、動的に作成し、RTP生成エンドポイントの参加なしにTCRTPセッションを破壊する可能性があります。
[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):
：;（セクション3参照TCRTPは効率的ではない）、このような設計は、古典的なCRTPは[CRTP]リンクあたりわずか数アクティブなフローを有するリンクで使用されることを可能にします
[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パケットを受信した場合、圧縮機は、ECRTP伸張状態を同期させるために（[ECRTP]に記載）COMPRESSED_UDPパケットを送信すべきです。 COMPRESSED_UDPパケットは、デコンプレッサでRTPコンテキストを更新します。
To ensure delivery of updates of context variables, COMPRESSED_UDP packets should be delivered using the robust operation described in [ECRTP].
コンテキスト変数の更新の配信を確実にするために、COMPRESSED_UDPパケットは[ECRTP]に記載のロバストな動作を用いて送達されなければなりません。
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両方が異なるプロトコルを識別することができレイヤ2つのプロトコルを必要とします。 [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ヘッダおよびトンネルヘッダのオーバーヘッドを低減する1つの方法は、単一のトンネリングされたパケット内の複数の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ペイロードタイプが多重化されることを可能にします。この多重化されたフレームは、次に、IPトンネル内の単一PPPMUXペイロードとして運ばれます。これは、複数のRTPペイロードは、単一のIPトンネルのパケットで運ばれることを可能にする非圧縮IPトンネルヘッダのオーバーヘッドは、複数のRTPペイロードにわたって償却されることを可能にします。
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マルチプレックス送信機を実装するために使用することができる例示的な送信手順を記載しています。このセクションで説明する送信手順は、PPP多重化フレームの最大サイズを制限するために使用されるパラメータMAX-SF-LENを含みます。
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多重フレームのサイズを制限するための2つの理由があります。まず、PPPMUX枠は最大で物理リンクの受信ユニット（MRU）を超えてはなりません。 PPPセッションおよびその関連するフロー制御が物理リンクに結合されているときに、第2、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
(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及び16,383（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のTimer_CUに似ています。各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トンネル内で多重化を使用して、合理的な帯域幅効率を得るために、複数のRTPストリームは、L2TPトンネルの送信元と宛先の間でアクティブであるべきです。
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は、NCPなどのPPPセッションの確立に使用されるトンネリング・メッセージのための方法を含みます。これは、[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.
[EF-PHB]で説明されるようにRTPストリームは、緊急転送（EF）ビットでマークされてもよいです。そのようなパケットがトンネリングされたときに[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) | |
+---------+---------+-------------+-----------------------+
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) | |
+-------+----------+-------+-----+ +----------+-------+-----+
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ために使用される合成形式は、連結上全てのパケットです。ここでは1つのペイロードを持つ例です。
+------+-------+----------+-------+-------+-----+-------+----+
| 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.
トンネルは多重トラフィックが含まれている場合は、複数の「PPPMuxペイロード」sが1つのIPパケットで送信されています。
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トンネルヘッダに関連するオーバーヘッドを低減します。 1つの多重化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の値は、圧縮されたセッション等内の行に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]を参照）追加のオーバーヘッドが含まれていません。値はCOMPRESSED_RTPペイロードタイプを使用することを想定しています。これは、ECRTPコンテキストIDの1つのオクテット、COMPRESSED_RTPフラグ、UDPチェックサムのための2つのオクテット、PPPプロトコルIDのための1つのオクテット、および多重化PPPの長さフィールドは1つのオクテットを1つのオクテットで構成されています。合計は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ペイロードタイプのオーバーヘッドです。この値は、L2TPv3ヘッダーと多重PPPプロトコルIDは1つのオクテットのIPヘッダは20オクテット、4つのオクテットです。合計が25オクテットです。
TRANSMIT-LENGTH, unit: milliseconds. The average duration of a transmission (such as a talk spurt for voice streams).
TRANSMIT-LENGTH、単位：ミリ秒。送信の平均持続時間（例えば、音声ストリームのトーク・スパートとして）。
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、単位：オクテット。絶対タイムスタンプフィールドを含むCOMPRESSED_UDPヘッダの追加ごとのペイロードのオーバーヘッド。この値は、5つのオクテットの合計、COMPRESSED_UDPヘッダ内の余分なフラグフィールドは1つのオクテットの絶対タイムスタンプのための4つのオクテットを含みます。
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フィールドを含むCOMPRESSED_UDPヘッダの追加ごとのペイロードのオーバーヘッド。この値は、絶対IPIDのための2つのオクテットを含んでいます。この値は、COMPRESSED_UDPヘッダ内の余分なフラグフィールドは1つのオクテットを含みます。合計は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がIPIDフローのペイロードの間に固定された一定量だけ変化している場合、IPID比は、この変数の値は0になり、常に更新する必要がある場合、値は1であり、ランダムに、したがって変化している場合は考慮していません音声や映像伝送の開始時にIPID値、その変数TRANSMIT-LENGTHによって考慮されます。送信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.
PAYLOAD-SIZE、単位：オクテット。オクテット内のRTPペイロードのサイズ。
MUX-SIZE, unit: count. The number of PPP payloads multiplexed into one multiplexed PPP payload.
MUX-SIZE、単位：回数。 PPPペイロードの数は、1つの多重化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.
SAMPLE期間、単位：ミリ秒。マルチプレックス内の各流れのための音声またはビデオペイロードの送信の平均遅延。すべてのコールが10msのサンプル周期を持っている場合たとえば、音声アプリケーションでは、この変数の値は10ミリ秒になります。
The formula is:
式は次のとおりです。
SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD / TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO
SLEEP TOTAL = SLEEP TCRTP + SLEEP TSTAMP（NREP *サンプル期間/ TRANSMIT長）+ SLEEP IPID * IPID比
BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) * 8) / SAMPLE-PERIOD)
帯域幅=（（PAYLOAD-SIZE + SOV-TOTAL +（POV-TCRTP / MUX-SIZE））* 8）/サンプル周期）
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:
上記の式を使用して音声アプリケーションのための例を作成するには、以下の使用シナリオを想定します。 20ミリ秒のパケット化期間とG.729圧縮を用いて圧縮音声ストリーム。このシナリオでは、VADが有効化され、平均トークスパートの長さは1500ミリ秒です。 IPIDフィールドは、ストリームのペイロードの間でランダムに変化しています。 3つの多重化ペイロードを可能にするためにトンネル内の十分なトラフィックがあります。次の値が適用されます。
SAMPLE-PERIOD = 20 milliseconds
TRANSMIT-LENGTH = 1500 milliseconds
IPID-RATIO = 1
PAYLOAD-SIZE = 20 octets
MUX-SIZE = 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キロビット/秒です。収率12.4キロビット/秒以上のように同じ係数を使用して、単一のHDLCリンクを介して古典CRTP。
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キロビット/秒に低減されます。これらと同じ要因、利回り11.2キロビット/コールを使用して、単一のHDLCリンクを介しクラシックCRTP、。
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:
20msのパケット化間隔で、G.729 5つの同時コール、無音声アクティビティ検出（VAD）を使用して、及び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%)
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カプセル化されたフローのいずれかのタイプの帯域幅を節約するために使用することができますので、ビデオアプリケーションのための帯域幅を節約するために使用することができます。このセクションでは、MPEG-2エンコードされたビデオのためのTCRTPベースの帯域幅の節約の例を説明します。
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-2エンコードされたビデオのためのRFC 2250フレームで説明したようにMPEGシステムとトランスポートストリームのRTPカプセル化が行われるので、帯域幅式TRANSMIT長変数は、本質的に無限です。 IPIDフィールドは、ストリームのペイロードの間でランダムに変化しています。 3つの多重化ペイロードを可能にするためにトンネル内の十分なトラフィックがあります。次の値が適用されます。
SAMPLE-PERIOD = 2.8 milliseconds
TRANSMIT-LENGTH = infinite
IPID-RATIO = 1
PAYLOAD-SIZE = 1316 octets
MUX-SIZE = 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メガビット/秒です。無ヘッダ圧縮とMPEGビデオは、上記と同様の因子を用いて、3.9メガビット/秒が得られます。 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カプセル化し、そのセルのパディングは常に貧しい帯域幅の利用につながる1つの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パケットオーバーヘッド：HDLCカプセル化のための5つのオクテット
POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 24 octets IP header and L2TPv3 header
POV-TUNNEL、単位：オクテット。トンネリングによるパケットオーバーヘッド：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、単位：オクテット。ペイロード長フィールドとECRTPプロトコルIDで構成されPPPMUXごとのペイロードオーバーヘッド。 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.
MUX-SIZE = 7こうして7音声またはビデオフローのようにTCRTPを作るために多重化する必要がある場合に、レイヤ2プロトコルとしてHDLCを使用する場合、（上記の式を使用して）損益分岐点は、帯域幅効率の良いリンクバイリンク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の実装例を示します。 TCRTPの実装は、限り、関連するRFCの要件が満たされているとして、多くの方法で行うことができます。
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
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と（NCP IPCPを使用して）PPP接続をネゴシエートするように構成されています。 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.
送信側アプリケーションは、1つのソースからRTPデータを収集し、RTPパケットをフォーマットします。下位レベルのアプリケーション層は、完全なIPパケットを形成するために、UDPおよび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.
このセクションでは、L2TPヘッダ圧縮とのPPP接続とL2TPトンネルを確立するために必要な必要なPPPとLT2P交渉を記述する。ピア1およびピア2：交渉は、2つのピア間です。
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 ->
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 ->
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
----- -----
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
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セッション内で運ば、圧縮ヘッダへの攻撃、多重層への攻撃、またはトンネリングネゴシエーションまたは輸送への攻撃に対する攻撃を含みます。これらの構成要素の技術の各々と個々に関連するセキュリティ問題は、RTP自体[RTP]のセキュリティ上の考慮事項とともに、[L2TPv3の]、[PPP-MUX]、[ECRTP]、それぞれの仕様に対処されます。
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.
しかし、一緒にこれらの要素技術の使用に起因する追加のセキュリティに関する考慮事項があるかもしれません。アドレッシング情報がより凝縮されるので、例えば、プロトコルの誤動作やデータのエラーによる別のマルチプレックス内の1つのストリームからのパケットの意図しない誤配の危険性の増大が存在してもよいです。トンネルは、ペイロードのすべてをチェックサムをしないトンネル輸送層のオプションと組み合わせて、ビットエラーを含むパケットの送達を可能にするリンク層プロトコルを介して送信される場合、これは特に当てはまります。
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とRTCPヘッダを暗号化するので、RTP仕様[RTP]内に設けられた暗号化のための基本的な方法は適していません。しかし、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、スティーブンCasnerとバン・ジェイコブソンの著者、およびRFC 2507、ミカエルDegermark、ビョルンNordgren、およびスティーブンピンクの作者に感謝したいと思います。
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.
著者らはまた、ダナ・ブレア、アレックスTweedley、水田ルディ、フランソワ・ルFaucheur、ティムグリーソン、マット・マディソン、フセインサラマ、Mallik Tatipamula、マイク・トーマス、マークTownsley、アンドリュー・バレンシア、ハーブWildfeuer、J.マーティン・ボーデン、ジョンに感謝したいと思いますGeevarghese、およびShoou耀輝。
[PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", RFC 3153, August 2001.
[PPP-MUX] Pazhyannur、R.、アリ、I.、およびC.フォックス、 "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.
、RFC 3545、 "高遅延、パケットロス・順序付きリンクの拡張圧縮RTP（CRTP）" [ECRTP]コレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、およびP.ルディ、 2003年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.ヤコブソン、RFC 2508、1999年2月 "低速シリアルリンクのIP / UDP / RTPヘッダの圧縮"。
[IPHCOMP] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[IPHCOMP] Degermark、M.、Nordgren、B.、およびS.ピンク、 "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.、ボルマン、C.、およびT.コレン、 "PPP上のIPヘッダー圧縮"、RFC 3544、2003年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"、STD 64、RFC 3550、2003年7月[RTP] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
【のL2TPv3]ラウ、J.、Townsley、M.、およびI. Goyret、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"、RFC 3931、2005年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]デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、 "緊急転送PHB（ホップ単位動作）"、RFC 3246、2002月。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[PPP]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年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.、マグリュー、D.、Naslund、M.、カララ、E.、およびK. Norrman、 "セキュアリアルタイム転送プロトコル（SRTP）"、RFC 3711、2004年3月。
[REORDER] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", Work in Progress, June 2004.
[REORDER] G.ペルティエ、L.ヨンソン、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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：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西タスマン・ドライブサンノゼ、CAアメリカの95134-1706米国
Phone: +1 408 527 0446 EMail: brucet@cisco.com
電話：+1 408 527 0446 Eメール：brucet@cisco.com
Tmima Koren 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
Tmimaコレン170西タスマン・ドライブサンノゼ、CAアメリカの95134-1706米国
Phone: +1 408 527 6169 EMail: tmima@cisco.com
電話：+1 408 527 6169 Eメール：tmima@cisco.com
Dan Wing 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
ダン・ウィング170西タスマン・ドライブサンノゼ、CAアメリカの95134-1706米国
EMail: dwing@cisco.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。