[要約] RFC 4170は、複数の圧縮されたRTPストリームをトンネリングするためのプロトコルであり、効率的なネットワークリソースの使用を目的としています。
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、音声トランキングのように、2つのエンドポイント間で複数のリアルタイムトランスポートプロトコル（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
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リンクのコストです。Voice over ATM（VoAal2、[I.363.2]）やMPLSの音声などのいくつかのボイスオーバーパケットテクノロジーは、帯域幅の効率を提供しますが（両方のテクノロジーにはIP、UDP、およびRTPヘッダーがないため）、VoATMもVomplsも直接アクセスを提供しませんIPオーバー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を2回使用する必要があります。対照的に、このドキュメントで説明されている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.
このドキュメントは、主に高級ネットワーク上のVoice over 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のホップごとの費用を回避するために、単純なソリューションは、L2TPでCRTPを使用してエンドツーエンドの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）のみが1つのストリームのみがある場合、帯域幅の節約はほとんどありません。多重化は、多くの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.
このセクションでは、Voice Over 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
[Voice Gateway] --- [Voice Gateway] ^ |IP上のTCRTP
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):
このような設計により、古典的な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
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]で説明されているように、このドキュメントで提案されているように、トンネリング時に一般的に使用される長い遅延WANリンクには、古典的なCRTP [CRTP]が適切ではありません。したがって、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パケットを受信した場合、コンプレッサーはcompressed_udpパケット（[ecrtp]で説明）を送信してECRTP分解器状態を同期する必要があります。Compressed_udpパケットは、減圧器のRTPコンテキストを更新します。
To ensure delivery of updates of context variables, COMPRESSED_UDP packets should be delivered using the robust operation described in [ECRTP].
コンテキスト変数の更新の配信を確保するには、[ECRTP]で説明されている堅牢な操作を使用して、Compressed_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]で説明されている「2回」アルゴリズムは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減圧装置は、Out Aut Orme Packetの存在下で正しく動作する必要があります。
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パケットの更新を繰り返します。。
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パケットのサイズ、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ペイロードを1つの多重ペイロードに組み合わせたカプセル化を説明しています。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セッションとそれに関連するフロー制御が物理リンクにバインドされると、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:
Tunnelsで使用するために、PPPMuxトランスミッターロジックの次の拡張機能を作成する必要があります。PPPトランスミッターのフロー制御ロジックは、2つのイベントのいずれかが発生するまで、着信ペイロードを収集するように変更する必要があります。
(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（長さフィールドの最大サイズ）と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トンネル内で多重化を使用して合理的な帯域幅効率を得るには、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には、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.
RTPストリームは、[EF-PHB]で説明されているように、迅速な転送（EF）ビットでマークされる場合があります。このようなパケットがトンネルに登録されている場合、[EF-PHB]で要求されているように、トンネルヘッダーも同じEFビットに対してマークする必要があります。同じEFマークされた多重化されたトンネルにEFと非EFトラフィックを混合しないことが重要です。
The packet format for an RTP packet, compressed with RTP header compression as defined in ECRTP, is:
RTPパケットのパケット形式は、ECRTPで定義されている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ペイロード」が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とトンネルヘッダーに関連付けられたオーバーヘッドが減少します。CRTPペイロードの数を増やすと、1つの多重化されたPPPペイロードに合わせて増加すると、多重化ゲインが増加します。トンネル内でトラフィックが増加すると、1つの多重化ペイロードでより多くのペイロードが組み合わされます。これにより、多重化ゲインが増加します。
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によって特徴付けられます。つまり、トンネルで隣接するパケットを超える確率が小さいことを意味します。
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、unit：octetの定義です。ECRTPおよび多重化されたPPPヘッダーの支払いごとのオーバーヘッド。この値には、IP IDまたはRTPタイムスタンプフィールドを更新するための追加のオーバーヘッドは含まれていません（IP IDの詳細については[ECRTP]を参照）。値は、Compressed_RTPペイロードタイプの使用を想定しています。これは、ECRTPコンテキストIDの1オクテット、圧縮_RTPフラグに1オクテット、UDPチェックサムに2オクテット、PPPプロトコルIDの1オクテット、多重化されたPPP長さフィールドに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、ユニット：Octet。トンネル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、unit：octet。絶対タイムスタンプフィールドを含むCompressed_udpヘッダーの追加の給与ごとのオーバーヘッド。この値には、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、ユニット：Octet。絶対的な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-ratio、ユニット：整数値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.
Mux-size、unit：count。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.
サンプル期間、ユニット：ミリ秒。マルチプレックスの各フローの音声またはビデオペイロードの送信間の平均遅延。たとえば、音声アプリケーションでは、すべての呼び出しに10msのサンプル期間がある場合、この変数の値は10msになります。
The formula is:
式は次のとおりです。
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)
The results are:
結果は次のとおりです。
BANDWIDTH, unit: kilobits per second. The average amount of bandwidth used per voice or video flow.
帯域幅、ユニット：1秒あたりのキロビット。音声またはビデオフローごとに使用される帯域幅の平均量。
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
サンプル期間= 20ミリ秒送信-length = 1500ミリ秒Ipid-ratio = 1ペイロードサイズ= 20オクテット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 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.2 kbits/callを生成します。
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）、20msパケット化間隔を持つG.729を使用し、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システムと輸送ストリームの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ミリ秒送信-length = infinite ipid-ratio = 1 payload-size = 1316オクツーnux-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 mbits/秒です。ヘッダー圧縮のないMPEGビデオは、上記と同じ要因を使用して、3.9 MBITS/SECを生成します。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セル内のこの以前に無駄になったスペースが有用なデータを含めることができます。これは、MultiplexingがVoice over IP over ATMを使用して帯域幅の利用に非常に大きな影響を与える主な理由の1つです。
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 Plusレイヤー2のオーバーヘッドがこの量よりも大きい場合、TCRTP多重化は、外側のIPヘッダーが多数のペイロードで償却されると、古典的な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
Where:
ただし：
POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC encapsulation
POV-L2、ユニット：Octet。レイヤー2パケットオーバーヘッド：HDLCカプセル化用の5オクテット
POV-TUNNEL, unit: octet. Packet overhead due to tunneling: 24 octets IP header and L2TPv3 header
POV-Tunnel、ユニット：Octet。トンネリングによるパケットオーバーヘッド：24オクテットIPヘッダーとL2TPV3ヘッダー
POV-PPPMUX, unit: octet. Packet overhead for the multiplexed PPP protocol ID: 1 octet
POV-PPPMUX、ユニット：Octet。多重化された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、unit：octet。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プロトコルとして使用する場合、Breakeven Point（上記の式を使用）はMux-Size = 7の場合です。圧縮。
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パケットをフォーマットします。低レベルのアプリケーションレイヤーが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.
このセクションでは、L2TPヘッダー圧縮を備えたPPP接続とL2TPトンネルを確立するために必要な必要なPPPおよびLT2Pの交渉について説明します。交渉は、PEER1とPEER2の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のコンポーネントテクノロジーへの攻撃には、TCRTPセッション内で運ばれるRTP/RTCPヘッダーとペイロードに対する攻撃、圧縮ヘッダーへの攻撃、多重化層の攻撃、またはトンネル交渉または輸送への攻撃が含まれます。これらのコンポーネントテクノロジーのそれぞれに個別に関連するセキュリティの問題は、それぞれの仕様[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 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仕様[RTP]で提供される暗号化の基本的な方法は、RTPおよびRTCPヘッダーをペイロードとともに暗号化するため適していません。ただし、RTP仕様により、パケットのペイロード部分のみが暗号化される別のプロファイルまたはペイロード形式の仕様で代替アプローチを定義することもできます。したがって、ヘッダー圧縮は暗号化されたパケットに適用される場合があります。そのようなプロファイル[SRTP]は、[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・マーティン・ボルデンに感謝したいと思います。Geevarghese、およびShoou Yiu。
[PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing", RFC 3153, August 2001.
[PPP-Mux] Pazhyannur、R.、Ali、I。、およびC. Fox、「PPP Multiplexing」、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 3545、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. 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 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] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年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、「レイヤー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] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis、「迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[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.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「The Secure Leal-Time Transport Protocol（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. Pelletier、L。Jonsson、K。Sandlund、「Robust Header Compression（ROHC）：Packetsを並べ替えることができる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、Liu、Z.、Martensson、A.、Miyazaki、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH. Zheng、 "堅牢なヘッダー圧縮（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ウェストタスマンドライブサンノゼ、カリフォルニア95134-1706アメリカ合衆国
Phone: +1 408 527 0446
EMail: brucet@cisco.com
Tmima Koren 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
Tmima Koren 170 West Tasman Drive San Jose、CA 95134-1706アメリカ合衆国アメリカ
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。