RFC4170 日本語訳
4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T.Koren, D. Wing. November 2005. (Format: TXT=48990 bytes) (Also BCP0110) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Thompson
Request for Comments: 4170 T. Koren
BCP: 110 D. Wing
Category: Best Current Practice Cisco Systems
November 2005
コメントを求めるワーキンググループB.トンプソン要求をネットワークでつないでください: 4170T.コーレンBCP: 110 D. カテゴリに翼をつけさせてください: 最も良い現在の練習シスコシステムズ2005年11月
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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントは2つの終点の間で複数のレアル-時間Transportプロトコル(RTP)の流れを平行まで運ぶネットワーク経路の上のRTPの流れの帯域幅利用を改良する方法を説明します、声の中継方式のように。 方法は圧縮を提供する標準プロトコルを結合します、複数のRTP小川がその経路の上まで運ばれるとき使用される帯域幅を減少させる目的のためにネットワーク経路の上で多重送信して、トンネルを堀って。
Thompson, et al. Best Current Practice [Page 1] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[1ページ]RFC4170トンネリング
Table of Contents
目次
1. Introduction ....................................................3
1.1. Is Bandwidth Costly? .......................................3
1.2. Overview of Protocols ......................................3
1.3. Document Focus .............................................4
1.4. Choice of Enhanced CRTP ....................................4
1.5. Reducing TCRTP Overhead ....................................4
2. Protocol Operation and Recommended Extensions ...................4
2.1. Models .....................................................5
2.2. Header Compression: ECRTP ..................................5
2.2.1. Synchronizing ECRTP States ..........................5
2.2.2. Out-of-Order Packets ................................6
2.3. Multiplexing: PPP Multiplexing .............................6
2.3.1. PPP Multiplex Transmitter Modifications for
Tunneling ...........................................7
2.3.2. Tunneling Inefficiencies ............................8
2.4. Tunneling: L2TP ............................................8
2.4.1. Tunneling and DiffServ ..............................9
2.5. Encapsulation Formats ......................................9
3. Bandwidth Efficiency ...........................................10
3.1. Multiplexing Gains ........................................10
3.2. Packet Loss Rate ..........................................10
3.3. Bandwidth Calculation for Voice and Video Applications ....10
3.3.1. Voice Bandwidth Calculation Example ................12
3.3.2. Voice Bandwidth Comparison Table ...................13
3.3.3. Video Bandwidth Calculation Example ................13
3.3.4. TCRTP over ATM .....................................14
3.3.5. TCRTP over Non-ATM Networks ........................14
4. Example Implementation of TCRTP ................................15
4.1. Suggested PPP and L2TP Negotiation for TCRTP ..............17
4.2. PPP Negotiation TCRTP .....................................17
4.2.1. LCP Negotiation ....................................17
4.2.2. IPCP Negotiation ...................................18
4.3. L2TP Negotiation ..........................................19
4.3.1. Tunnel Establishment ...............................19
4.3.2. Session Establishment ..............................19
4.3.3. Tunnel Tear Down ...................................20
5. Security Considerations ........................................20
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................22
1. 序論…3 1.1. 帯域幅は高価ですか? .......................................3 1.2. プロトコルの概観…3 1.3. 焦点を記録してください…4 1.4. 高められたCRTPの選択…4 1.5. TCRTPオーバーヘッドを下げます…4 2. 操作とお勧めの拡大について議定書の中で述べてください…4 2.1. モデル…5 2.2. ヘッダー圧縮: ECRTP…5 2.2.1. ECRTP州を連動させます…5 2.2.2. 故障しているパケット…6 2.3. マルチプレクシング: pppマルチプレクシング…6 2.3.1. pppはトンネリングのための送信機変更を多重送信します…7 2.3.2. トンネリング非能率…8 2.4. トンネリング: L2TP…8 2.4.1. トンネリングとDiffServ…9 2.5. カプセル化形式…9 3. 帯域幅効率…10 3.1. マルチプレクシングは獲得されます…10 3.2. パケット損失率…10 3.3. 声とビデオ・アプリケーションのための帯域幅計算…10 3.3.1. 帯域幅計算の例を声に出してください…12 3.3.2. 帯域幅比較テーブルを声に出してください…13 3.3.3. ビデオ帯域幅計算の例…13 3.3.4. 気圧でのTCRTP…14 3.3.5. 非気圧ネットワークの上のTCRTP…14 4. TCRTPの例の実現…15 4.1. TCRTPのためにpppとL2TP交渉を示します…17 4.2. ppp交渉TCRTP…17 4.2.1. LCP交渉…17 4.2.2. IPCP交渉…18 4.3. L2TP交渉…19 4.3.1. 設立にトンネルを堀ってください…19 4.3.2. セッション設立…19 4.3.3. トンネル裂け目はダウンします…20 5. セキュリティ問題…20 6. 承認…21 7. 参照…21 7.1. 標準の参照…21 7.2. 有益な参照…22
Thompson, et al. Best Current Practice [Page 2] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[2ページ]RFC4170トンネリング
1. Introduction
1. 序論
This document describes a way to combine existing protocols for compression, multiplexing, and tunneling to save bandwidth for some RTP applications.
このドキュメントは圧縮のために既存のプロトコルを結合する方法を述べます、いくつかのRTPアプリケーションのために帯域幅を貯蓄するために多重送信して、トンネルを堀って。
1.1. Is Bandwidth Costly?
1.1. 帯域幅は高価ですか?
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リンクの費用です。 ATM(VoAAL2、[I.363.2])の上のVoiceやMPLSの上のVoiceなどのいくつかのナレーターの声パケット技術が帯域幅効率を提供している間(両方の技術がIP、UDP、およびRTPヘッダーを欠いているので)、VoATMもVoMPLSもボイス・オーバー IPに利用可能な声の過剰パケットサービスに直接アクセスを提供しません。 したがって、WANリンクコスト削減の目標は他のネットワークへの無くなっているインタコネクトの機会を犠牲にして達成されます。
TCRTP solves the VoIP bandwidth discrepancy, especially for large, voice-trunking applications.
TCRTPは特に大きい声中継方式アプリケーションのためのVoIP帯域幅食い違いを解決します。
1.2. Overview of Protocols
1.2. プロトコルの概観
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.
ヘッダー圧縮はEnhanced CRTP(ECRTP、[ECRTP])を使用するのに優れています。 ECRTPは長時間の遅延リンクの上にうまくいく古典的なCRTP[CRTP]への増進です、終わりから終わりへのトンネリング本書では説明されたリンクなどのように。 このヘッダー圧縮はIP、UDP、およびRTPヘッダーを減少させます。
Multiplexing is accomplished using PPP Multiplexing [PPP-MUX].
マルチプレクシングはPPP Multiplexing[PPP-多重化装置]を使用するのに優れています。
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は、ヘッダー圧縮を達成するために少しの1ルータあたりの追加処理も必要としません。 代わりに、ヘッダーはすべての中間的リンクにおける圧縮された終わりの終わりの、そして、節約している帯域幅です。
Thompson, et al. Best Current Practice [Page 3] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[3ページ]RFC4170トンネリング
1.3. Document Focus
1.3. ドキュメント焦点
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アプリケーションのための同様の帯域幅貯蓄を提供するのに本書では説明されたプロトコルの組み合わせを使用できます、そして、帯域幅貯蓄はサンプルビデオアプリケーションのために含まれています。
1.4. Choice of Enhanced CRTP
1.4. 高められたCRTPの選択
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の1ホップあたりの費用を避けるなら、安易な解決策は終わりから終わりへの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.
したがって、このドキュメントはEnhanced CRTP[ECRTP]の使用について説明します。(Enhanced CRTPは高い遅れ、パケット損失とコンプレッサーと減圧装置の間でmisorderingする両方を支持します)。
1.5. Reducing TCRTP Overhead
1.5. TCRTPオーバーヘッドを下げます。
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です。 詳細に関してセクション2.3を見てください。
2. Protocol Operation and Recommended Extensions
2. プロトコル操作とお勧めの拡大
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.
このセクションは3つのプロトコルを結合する方法を説明します: ボイス・オーバー IPなどのRTPアプリケーションのために帯域幅を貯蓄するためにCRTP、PPP Multiplexing、およびL2TP Tunnelingを高めました。
Thompson, et al. Best Current Practice [Page 4] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[4ページ]RFC4170トンネリング
2.1. Models
2.1. モデル
TCRTP can typically be implemented in two ways. The most straightforward is to implement TCRTP in the gateways terminating the RTP streams:
2つの方法でTCRTPを通常実行できます。 最も簡単であるのは、RTPの流れを終えながらゲートウェイでTCRTPを実行することです:
[voice gateway]---[voice gateway]
^
|
TCRTP over IP
[声のゲートウェイ]---[声のゲートウェイ] ^| 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
[声のGW] \/[声のGW][声のGW]---[集中装置]---[集中装置]---[声のGW] [声のGW]/\[声のGW]^ ^ ^| | | IPの上のIP RTPの上のIP TCRTPの上のRTP
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]がほんのいくつかの1リンクあたりのアクティブな流れとのリンクの上に使用されるのを許容します(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
[声のGW] \/[声のGW][声のGW]---[集中装置]---[集中装置]---[声のGW] [声のGW]/\[声のGW]^ ^ ^| | | IPの上のIP RTPの上のIP TCRTPの上のCRTP
2.2. Header Compression: ECRTP
2.2. ヘッダー圧縮: ECRTP
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の代わりに使用されるべきです。
2.2.1. Synchronizing ECRTP States
2.2.1. ECRTP州を連動させます。
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減圧装置状態を同期させるように、COMPRESSED_UDPパケット([ECRTP]では、説明される)を送るはずです。 COMPRESSED_UDPパケットは減圧装置におけるRTP文脈をアップデートします。
Thompson, et al. Best Current Practice [Page 5] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[5ページ]RFC4170トンネリング
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]で説明されたアルゴリズムがUDPチェックサムを当てにするので、RTP送信機の上のIPスタックはUDPチェックサムを伝えるはずです。UDPチェックサムが使用されていないなら、ECRTPコンプレッサーは[ECRTP]で説明されたCRTP Headersチェックサムを使用するはずです。
2.2.2. Out-of-Order Packets
2.2.2. 故障しているパケット
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]の上の不適切なパケットの配信を扱うのに別の層が必要です。
2.3. Multiplexing: PPP Multiplexing
2.3. マルチプレクシング: pppマルチプレクシング
Both CRTP and ECRTP require a layer two protocol that allows identifying different protocols. [PPP] is suited for this.
CRTPとECRTPの両方が異なったプロトコルを特定する層twoのプロトコルを必要とします。 [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-多重化装置]は複数のPPPペイロードを1個の多重送信されたペイロードに結合するカプセル化について説明します。 PPPマルチプレクシングは、どんな支持されたPPPペイロードタイプも多重送信されるのを許容します。 そして、この多重送信されたフレームはただ一つのPPPMUXペイロードとしてIPトンネルで運ばれます。 これは、複数のRTPペイロードが単一のIPトンネルパケットで運ばれるのを許容して、解凍されたIPとトンネルヘッダーのオーバーヘッドが複数のRTPペイロードの上清算されるのを許容します。
Thompson, et al. Best Current Practice [Page 6] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[6ページ]RFC4170トンネリング
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を見てください。
2.3.1. PPP Multiplex Transmitter Modifications for Tunneling
2.3.1. トンネリングのためのpppマルチプレックス送信機変更
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-多重化装置]のセクション1.2はPPP Multiplex送信機を実行するのに用いることができる例の送信機手順について説明します。 このセクションで説明されたトランスミッション手順はPPP Multiplexフレームの最大サイズを制限するのに使用されるパラメタ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 Multiplexフレームのサイズを制限する2つの理由があります。 まず最初に、PPPMUXフレームは物理的なリンクのMaximum Receive Unit(MRU)を決して、超えているはずがありません。 PPPセッションとその関連フロー制御が伝えられる前にマルチプレックスパケットを開催できる時間に物理的なリンクに縛られるとき、2番目に、MAX-SF-LENパラメタは上限を形成します。 PPP Multiplex送信機のためのフロー制御が物理的なリンクに縛られるとき、PPP Multiplex送信機からフレームを引くのに物理的なリンクのクロックレートを使用できます。
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.
フロー制御のこのタイプはMAX-SF-LEN/リンクSpeedに伝えられる前にPPPマルチプレックスフレームを持つことができる最大の時間を制限します。
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送信機のフロー制御論理は2回の出来事の1つが起こるまで入って来るペイロードを集めるように変更されるべきです:
(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と呼ばれるタイマは期限が切れました。
Thompson, et al. Best Current Practice [Page 7] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[7ページ]RFC4170トンネリング
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の、より最小限(長さの分野の最大サイズ)とトンネルが関連しているかもしれないすべての可能な物理インターフェースへの1万6383であるべきです(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送信機には、それ自身のTimer 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ミリセカンドでしょう。
2.3.2. Tunneling Inefficiencies
2.3.2. トンネリング非能率
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セッションが1組のRTP終点の間で行われるアプリケーションの役に立ちます。 セッションが必要なレベルにヘッダーオーバーヘッドを引き下げるのを必要とした同時のRTPの数はL2TPヘッダーのサイズに依存します。 より小さいL2TPヘッダーはCRTPと同様の帯域幅効率を生産するのに必要であるより少ない同時のRTPセッションのときに結果になるでしょう。
2.4. Tunneling: L2TP
2.4. トンネリング: L2TP
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圧縮/減圧パラメタを交渉できます。
Thompson, et al. Best Current Practice [Page 8] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[8ページ]RFC4170トンネリング
2.4.1. Tunneling and DiffServ
2.4.1. トンネリングとDiffServ
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]で説明されるようにExpedited Forwarding(EF)ビットでマークされるかもしれません。 また、そのようなパケットがトンネルを堀られるとき、[EF-PHB]は必要に応じてトンネルヘッダーを同じEFビットマークしなければなりません。 同じEFが著しい多重送信されたトンネルのEFと非EF交通を混合しないのは重要です。
2.5. Encapsulation Formats
2.5. カプセル化形式
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) | |
+---------+---------+-------------+-----------------------+
+---------+---------+-------------+-----------------------+ | | MSTI| | | | 文脈| | UDP| | | ID| リンク| チェックサム| RTPデータ| | | 系列| | | | (1-2) | (1) | (0-2) | | +---------+---------+-------------+-----------------------+
The packet format of a multiplexed PPP packet as defined by [PPP-MUX] is:
[PPP-多重化装置]による定義されるとしての多重送信されたPPPパケットのパケット・フォーマットは以下の通りです。
+-------+---+------+-------+-----+ +---+------+-------+-----+
| Mux |P L| | | | |P L| | | |
| PPP |F X|Len1 | PPP | | |F X|LenN | PPP | |
| Prot. |F T| | Prot. |Info1| ~ |F T| | Prot. |InfoN|
| Field | | Field1| | | |FieldN | |
| (1) |1-2 octets| (0-2) | | |1-2 octets| (0-2) | |
+-------+----------+-------+-----+ +----------+-------+-----+
+-------+---+------+-------+-----+ +---+------+-------+-----+ | Mux|P L| | | | |P L| | | | | ppp|F X|Len1| ppp| | |F X|LenN| ppp| | | Prot。 |F T| | Prot。 |Info1| ~ |F T| | Prot。 |InfoN| | 分野| | Field1| | | |FieldN| | | (1) |1-2 八重奏| (0-2) | | |1-2 八重奏| (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 --------------------->|
+------+-------+----------+-------+-------+-----+-------+----+ | IP| Mux|P L| | | | MSTI| | | |ヘッダー| ppp|F X|Len1| ppp|文脈| | UDP|RTP| | (20) | プロト|F T| | プロト| ID| リンク| Cksum|データ| | | 分野| | Field1| | Seq| | | | | (1) |1-2 八重奏| (0-2) | (1-2) | (1) | (0-2) | | +------+-------+----------+-------+-------+-----+-------+----+ | <、-、-、-、-、-、-、-、-、-、-、-、-- IPペイロード------------------------->| | <、-、-、-、-- PPPmuxペイロード--------------------->|
If the tunnel contains multiplexed traffic, multiple "PPPMux payload"s are transmitted in one IP packet.
トンネルが多重送信された交通を含んでいるなら、複数の「PPPMuxペイロード」sは1つのIPパケットで伝えられます。
Thompson, et al. Best Current Practice [Page 9] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[9ページ]RFC4170トンネリング
3. Bandwidth Efficiency
3. 帯域幅効率
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の上でどう帯域幅効率をかなり高めるかを説明します。
3.1. Multiplexing Gains
3.1. マルチプレクシング利得
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つに結合されたCRTPペイロードについて数を増やすのは、利得を多重送信しながら、PPPペイロード増加を多重送信しました。 交通がトンネルの中で増加するのに従って、より多くのペイロードが1個の多重送信されたペイロードで結合されます。 これは、利得を多重送信しながら、増加するでしょう。
3.2. Packet Loss Rate
3.2. パケット損失率
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%より上における)、より高度なテクニックを使わなければなりません。 それらのテクニックはこのドキュメントの範囲を超えています。
3.3. Bandwidth Calculation for Voice and Video Applications
3.3. 声とビデオ・アプリケーションのための帯域幅計算
The following formula uses the factors described above to model per- flow bandwidth usage for both voice and video applications. These variables are defined:
以下の公式がモデル化するのに上で説明された要素を使用する、-、声とビデオ・アプリケーションの両方のための流れ帯域幅用法。 これらの変数は定義されます:
Thompson, et al. Best Current Practice [Page 10] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[10ページ]RFC4170トンネリング
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の1ペイロードあたりのオーバーヘッドと多重送信されたPPPヘッダー。 この値はIP IDかRTP Time Stamp分野(IP IDに関する詳細に関して[ECRTP]を見る)をアップデートするための追加オーバーヘッドを含んでいません。 値はCOMPRESSED_RTPペイロードタイプの使用を仮定します。 それはECRTP文脈IDのための1つの八重奏、COMPRESSED_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、ユニット: 八重奏。 トンネルを堀られたECRTPの1パケットあたりのオーバーヘッド。 これはトンネルヘッダーと多重送信された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).
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ヘッダーの1ペイロードあたりの追加オーバーヘッド。 この値はCOMPRESSED_UDPヘッダーの分野と絶対時間の4つの八重奏が押し込む余分な旗のための1つの八重奏を含んでいます、合計5つの八重奏のために。
SOV-IPID, unit: octet. Additional per-payload overhead of the
COMPRESSED_UDP header that includes the absolute IPID field.
This value includes 2 octets for the absolute IPID. This
value also includes 1 octet for the extra flags field in the
COMPRESSED_UDP header. The total is 3 octets.
SOV-IPID、ユニット: 八重奏。 絶対IPID分野を含んでいるCOMPRESSED_UDPヘッダーの1ペイロードあたりの追加オーバーヘッド。 この値は絶対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-RATIOは0歳になるでしょう。 この変数の値は、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.
有効搭載量SIZE、ユニット: 八重奏。 八重奏における、RTPペイロードのサイズ。
Thompson, et al. Best Current Practice [Page 11] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[11ページ]RFC4170トンネリング
MUX-SIZE, unit: count. The number of PPP payloads multiplexed into
one multiplexed PPP payload.
多重化装置-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-PERIOD、ユニット: ミリセカンド。 声の送信の間の平均した遅れかそれぞれのためのビデオペイロードがマルチプレックスを流れます。 例えば、音声アプリケーションでは、すべての呼び出しに10msサンプルの期間があるなら、この変数の値は10msでしょう。
The formula is:
公式は以下の通りです。
SOV-TOTAL = SOV-TCRTP + SOV-TSTAMP * (NREP * SAMPLE-PERIOD /
TRANSMIT-LENGTH) + SOV-IPID * IPID-RATIO
SOV-合計=SOV-TCRTP+SOV-TSTAMP*(長さをNREP*サンプル期間/伝えます)の+SOV-IPID*IPID-比
BANDWIDTH = ((PAYLOAD-SIZE + SOV-TOTAL + (POV-TCRTP / MUX-SIZE)) *
8) / SAMPLE-PERIOD)
帯域幅=((多重化装置POV-TCRTP/サイズ) *8)/サンプルSOVペイロード-サイズ+合計+期間)
The results are:
結果は以下の通りです。
BANDWIDTH, unit: kilobits per second. The average amount of
bandwidth used per voice or video flow.
BANDWIDTH、ユニット: 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に関連している1ペイロードあたりのオーバーヘッドの総量と等しいです。 それはECRTPとPPPの1ペイロードあたりのオーバーヘッド、タイムスタンプアップデートオーバーヘッド、およびIPIDアップデートオーバーヘッドを含んでいます。
3.3.1. Voice Bandwidth Calculation Example
3.3.1. 声の帯域幅計算の例
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ミリセカンドのpacketizationの期間がある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八重奏多重化装置1有効搭載量1500 20SAMPLE-PERIOD=ミリセカンドのTRANSMIT-LENGTH=ミリセカンドのIPID-RATIO=SIZE=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.
この例に関しては、1呼び出しあたり、帯域幅は16.4kbits/秒です。 上記の同じ要素を使用する単一のHDLCリンクの上の古典的なCRTPは12.4kbits/秒もたらします。
Thompson, et al. Best Current Practice [Page 12] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[12ページ]RFC4170トンネリング
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-RATIOを使用することで再計算される、呼び出しに従って、帯域幅は13.8kbits/秒まで減少します。 これらの同じ要素を使用して、単一のHDLCリンクの上の古典的なCRTPは11.2kbits/呼び出しをもたらします。
3.3.2. Voice Bandwidth Comparison Table
3.3.2. 音声帯域幅比較テーブル
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 packetization間隔がある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%)
pppの上の正常なVoIP: リンクの上に古典的なCRTPがある124キロビット毎秒: PPPの上にTCRTPがある50キロビット毎秒(貯蓄: 59%): AAL5の上にTCRTPがある62キロビット毎秒(貯蓄: 50%): 85キロビット毎秒(貯蓄: 31%)
3.3.3. Video Bandwidth Calculation Example
3.3.3. ビデオ帯域幅計算の例
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 SystemとTransport StreamsのRTPカプセル化はRFC2250で説明されるように実行されます。 絶え間なくMPEG-2のコード化されたビデオのためのフレームを送るので、帯域幅公式のTRANSMIT-LENGTH変数は本質的には無限です。 IPID分野は流れのペイロードの間で手当たりしだいに変化します。交通がトンネルに3個の多重送信されたペイロードを許容するほどあります。 以下の値は適用されます:
SAMPLE-PERIOD = 2.8 milliseconds
TRANSMIT-LENGTH = infinite
IPID-RATIO = 1
PAYLOAD-SIZE = 1316 octets
MUX-SIZE = 3
1有効搭載量無限の2.8SAMPLE-PERIOD=ミリセカンドのTRANSMIT-LENGTH=IPID-RATIO=SIZE=1316八重奏多重化装置-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.
この例に関しては、1流れあたり、帯域幅は3.8メガビット/秒です。 上記の同じ要素を使用して、ヘッダー圧縮のないMPEGビデオは3.9メガビット/秒もたらします。 TCRTPがいくつかの帯域幅貯蓄をビデオに供給しますが、トランスミッションヘッダー対ペイロードの比率が非常にわずかであるので、帯域幅貯蓄は意味をなしません。
Thompson, et al. Best Current Practice [Page 13] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[13ページ]RFC4170トンネリング
3.3.4. TCRTP over ATM
3.3.4. 気圧での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ミリセカンドのpacketization間隔を費やす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.
この詰め物を浪費することの代わりに、ATMセルのこの以前に無駄なスペースはTCRTPのマルチプレクシングで役に立つデータを含むことができます。 これはATMの上にボイス・オーバー IPがある状態でマルチプレクシングがそのような大きい影響を帯域幅利用に与える主な理由の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ネットワークだけに制限されません。
3.3.5. TCRTP over Non-ATM Networks
3.3.5. 非気圧ネットワークの上のTCRTP
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トンネリングの1ペイロードあたりのオーバーヘッドは4か6つの八重奏です。 外側のIPヘッダーが多くのペイロードの上清算されるとき、古典的なCRTPと層2のオーバーヘッドがこの量より大きいなら、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*多重化装置サイズ>はPOV-トンネル+POV-PPPMUX+SOV-PPPMUX*多重化装置POV-L2+サイズと等しいです。
Where:
どこ:
POV-L2, unit: octet. Layer 2 packet overhead: 5 octets for HDLC
encapsulation
POV-L2、ユニット: 八重奏。 層2のパケットオーバーヘッド: HDLCカプセル化のための5つの八重奏
Thompson, et al. Best Current Practice [Page 14] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[14ページ]RFC4170トンネリング
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、ユニット: 八重奏。 PPPMUXの1ペイロードあたりのオーバーヘッド。(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.
層2が議定書を作るのでHDLCを使用するなら、損益分岐点(上の公式を使用する)はいつ多重化装置-SIZE=7であるか。 したがって、7声かビデオ流れが、リンクのそばでのリンクCRTP圧縮として帯域幅効率的であるとしてのTCRTPを作るために多重送信される必要があります。
4. Example Implementation of TCRTP
4. TCRTPの例の実現
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の例の実現について説明します。 関連RFCsに関する必要条件が満たされる限り、様々な意味でTCRTPの実現をするかもしれません。
Here is the path an RTP packet takes in this implementation:
ここに、RTPパケットがこの実現で取る経路があります:
Thompson, et al. Best Current Practice [Page 15] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[15ページ]RFC4170トンネリング
+-------------------------------+ ^
| 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
+-------------------------------+ ^ | アプリケーション| | +-------------------------------+ | | RTP| | +-------------------------------そして+ アプリケーション。| UDP| IPスタック+-------------------------------+ | | IP| | +-------------------------------+ V| | IP推進| +-------------------------------+ ^ | ECRTP| | +-------------------------------+ | | PPPMUX| | +-------------------------------+ トンネル| ppp| インタフェース+-------------------------------+ | | L2TP| | +-------------------------------+ | | IP| | +-------------------------------+ V| | IP推進| +-------------------------------+ ^ | 層2| | +-------------------------------+物理的です。| 物理的| インタフェース+-------------------------------+ V
A protocol stack is configured to create an L2TP tunnel interface to a destination host. The tunnel is configured to negotiate the PPP connection (using NCP IPCP) with ECRTP header compression and PPPMUX. IP forwarding is configured to route RTP packets to this tunnel. The destination UDP port number could distinguish RTP packets from non- RTP packets.
プロトコル・スタックは、L2TPトンネルのインタフェースをあて先ホストに作成するために構成されます。 トンネルは、ECRTPヘッダー圧縮とPPPMUXとPPP接続を交渉する(NCP IPCPを使用する)ために構成されます。 IP推進は、RTPパケットをこのトンネルに発送するために構成されます。 目的地UDPポートナンバーは非RTPのパケットとRTPパケットを区別するかもしれません。
The transmitting application gathers the RTP data from one source, and formats an RTP packet. Lower level application layers add UDP and IP headers to form a complete IP packet.
伝えるアプリケーションは、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パケットを発送します、そして、ペイロードを多重送信します、そして、次に、あて先ホストにパケットにトンネルを堀ります。
Thompson, et al. Best Current Practice [Page 16] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[16ページ]RFC4170トンネリング
The operation of the receiving node is the same as the transmitting node in reverse.
受信ノードの操作は伝えるノードと逆であり同じです。
4.1. Suggested PPP and L2TP Negotiation for TCRTP
4.1. TCRTPのための提案されたpppとL2TP交渉
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交渉について説明します。 2人の同輩の間には、交渉があります: Peer1とPeer2。
4.2. PPP Negotiation TCRTP
4.2. ppp交渉TCRTP
The Point-to-Point Protocol is described in [PPP].
Pointからポイントへのプロトコルは[PPP]で説明されます。
4.2.1. LCP Negotiation
4.2.1. LCP交渉
Link Control Processing (LCP) is described in [PPP].
リンクControl Processing(LCP)は[PPP]で説明されます。
4.2.1.1. Link Establishment
4.2.1.1. リンク設立
Peer1 Peer2
----- -----
Configure-Request (no options) ->
<- Configure-Ack
<- Configure-Request (no options)
Configure-Ack ->
Peer1 Peer2----- ----- 要求を構成している(オプションがありません)-><Ackを構成している<要求を構成している(オプションがありません)Ackを構成している->。
4.2.1.2. Link Tear Down
4.2.1.2. リンク裂け目はダウンします。
Terminate-Request ->
<- Terminate-Ack
要求を終えている-><、Ackを終えます。
Thompson, et al. Best Current Practice [Page 17] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[17ページ]RFC4170トンネリング
4.2.2. IPCP Negotiation
4.2.2. IPCP交渉
The protocol exchange here is described in [IPHCOMP], [PPP], and [ECRTP].
ここでのプロトコル交換は[IPHCOMP]、[PPP]、および[ECRTP]で説明されます。
Peer1 Peer2
----- -----
Configure-Request ->
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
<- Configure-Ack
<- Configure-Request
Options:
IP-Compression-Protocol
Use protocol 0x61
and sub-parameters
as described in
[IPCP-HC] and [ECRTP]
Configure-Ack ->
Peer1 Peer2----- ----- 要求を構成している->オプション: IP圧縮プロトコルUseは要求を構成している[IPCP-HC]とAckを構成している[ECRTP]<<Optionsで説明されるように0×61とサブパラメタについて議定書の中で述べます: [IPCP-HC]とAckを構成している[ECRTP]->で説明されるIP圧縮プロトコルUseプロトコル0x61とサブパラメタ
Thompson, et al. Best Current Practice [Page 18] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[18ページ]RFC4170トンネリング
4.3. L2TP Negotiation
4.3. L2TP交渉
L2TP is described in [L2TPv3].
L2TPは[L2TPv3]で説明されます。
4.3.1. Tunnel Establishment
4.3.1. トンネル設立
Peer1 Peer2
----- -----
SCCRQ ->
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
<- SCCRP
Mandatory AVP's:
Message Type
Protocol Version
Host Name
Framing Capabilities
Assigned Tunnel ID
SCCCN ->
Mandatory AVP's:
Message Type
<- ZLB
Peer1 Peer2----- ----- SCCRQ->義務的なAVPのもの: メッセージタイププロトコルバージョンホスト名縁どり能力は<SCCRP義務的なAVPのTunnel IDものを割り当てました: メッセージタイププロトコルバージョンホスト名縁どり能力はトンネルID SCCCN->義務的なAVPのものを割り当てました: メッセージタイプ<ZLB
4.3.2. Session Establishment
4.3.2. セッション設立
Peer1 Peer2
----- -----
ICRQ ->
Mandatory AVP's:
Message Type
Assigned Session ID
Call Serial Number
<- ICRP
Mandatory AVP's:
Message Type
Assigned Session ID
ICCN ->
Mandatory AVP's:
Message Type
Tx (Connect Speed)
Framing Type
<- ZLB
Peer1 Peer2----- ----- ICRQ->義務的なAVPのもの: Session IDが割り当てられたメッセージタイプは、通し番号<ICRPを義務的なAVPのものと呼びます: メッセージタイプはID ICCN->義務的なAVPのセッションものを割り当てました: メッセージタイプTx(速度を接続する)縁どりタイプ<ZLB
Thompson, et al. Best Current Practice [Page 19] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[19ページ]RFC4170トンネリング
4.3.3. Tunnel Tear Down
4.3.3. トンネル裂け目はダウンします。
Peer1 Peer2
----- -----
StopCCN ->
Mandatory AVP's:
Message Type
Assigned Tunnel ID
Result Code
<- ZLB
Peer1 Peer2----- ----- StopCCN->義務的なAVPのもの: トンネルID結果コード<ZLBが割り当てられたメッセージタイプ
5. Security Considerations
5. セキュリティ問題
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-多重化装置]、[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.
しかしながら、これらのコンポーネント技術の使用から一緒に起こる追加担保問題があるかもしれません。 例えば、アドレス指定情報がさらに凝縮して、マルチプレックスにおける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仕様は、代替的アプローチがパケットのペイロード部分だけがコード化される別々のプロフィールかペイロード書式仕様で定義されるのを許容します。 したがって、ヘッダー圧縮はコード化されたパケットに適用されるかもしれません。 そのようなプロフィールの1つ[SRTP]はさらに提供されます。
Thompson, et al. Best Current Practice [Page 20] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[20ページ]RFC4170トンネリング
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アプリケーションに組み入れられるべきです。
6. Acknowledgements
6. 承認
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.
作者はRFC2508、スティーブンCasner、およびヴァン・ジェーコブソンの作者、およびRFC2507、マイケル・デーゲルマルク、ビヨンNordgren、およびスティーブン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.
また、作者はダナ・ブレア、アレックスTweedley、Paddy Ruddy、フランソアLe Faucheur、ティム・グリーソン、マット・マディソン、フセイン・サラマ、Mallik Tatipamula、マイク・トーマス、マークTownsley、アンドリュー・バレンシア、Herb Wildfeuer、J.マーチンボーデン、ジョンGeevarghese、およびShoou Yiuに感謝したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[PPP-MUX] Pazhyannur, R., Ali, I., and C. Fox, "PPP Multiplexing",
RFC 3153, August 2001.
[ppp多重化装置] PazhyannurとR.とアリ、I.とC.フォックス、「pppマルチプレクシング」、RFC3153、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]コーレン、T.、Casner、S.、Geevarghese、J.、トンプソン、B.、P. 非常に、「パケット損失とReordering、高値とのリンクへの高められた圧縮されたRTP(CRTP)は延着します」、RFC3545、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.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[IPHCOMP] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[IPHCOMP] デーゲルマルクとM.とNordgren、B.とS.ピンク、「IPヘッダー圧縮」、RFC2507、1999年2月。
[IPCP-HC] Engan, M., Casner, S., Bormann, C., and T. Koren, "IP
Header Compression over PPP", RFC 3544, July 2003.
2003年7月の[IPCP-HC]EnganとM.とCasnerとS.とボルマン、C.とT.コーレン、「pppの上のIPヘッダー圧縮」RFC3544。
[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.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[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)」、RFC3931、3月2005日
[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 Adaptationは仕様を層にします」。 「タイプ2AAL」、I.363.2、1997年9月。
Thompson, et al. Best Current Practice [Page 21] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[21ページ]RFC4170トンネリング
[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.、シャルニー、A.、アメリカダイコンソウ、J.C.、ベンソン、K.、Le Boudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、および2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。
[PPP] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[ppp]シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
7.2. Informative References
7.2. 有益な参照
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[SRTP] 2004年のBaugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[REORDER] G. Pelletier, L. Jonsson, K. Sandlund, "RObust Header
Compression (ROHC): ROHC over Channels that can Reorder
Packets", Work in Progress, June 2004.
G.ペレティア、L.イェンソン、[追加注文]K.Sandlund、「体力を要しているヘッダー圧縮(ROHC):」 「Channelsの上のそうすることができるROHC、Reorder Packets、」、Progress、6月2004日のWork
[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.、バーマイスター、C.、デーゲルマルク、M.、福島、H.、ハンヌ、H.、イェンソン、L-E.、Hakenberg、R.、コーレン、T.、Le、K.、リュウ、Z.、Martensson、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、Yoshimura、T.、およびH.ツェン、「体力を要しているヘッダー圧縮(ROHC):」 枠組みと4個のプロフィール: 「RTP、超能力であって、解凍されたUDP」、RFC3095、7月2001日
Thompson, et al. Best Current Practice [Page 22] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[22ページ]RFC4170トンネリング
Authors' Addresses
作者のアドレス
Bruce Thompson 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
西タスマン・Driveブルーストンプソン170カリフォルニア95134-1706サンノゼ(アメリカ合衆国)
Phone: +1 408 527 0446 EMail: brucet@cisco.com
以下に電話をしてください。 +1 0446年の408 527メール: brucet@cisco.com
Tmima Koren 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
西タスマン・Drive Tmimaコーレン170カリフォルニア95134-1706サンノゼ(アメリカ合衆国)
Phone: +1 408 527 6169 EMail: tmima@cisco.com
以下に電話をしてください。 +1 6169年の408 527メール: tmima@cisco.com
Dan Wing 170 West Tasman Drive San Jose, CA 95134-1706 United States of America
ダンWing170西タスマン・Driveサンノゼ、カリフォルニア95134-1706アメリカ合衆国
EMail: dwing@cisco.com
メール: dwing@cisco.com
Thompson, et al. Best Current Practice [Page 23] RFC 4170 Tunneling Multiplexed Compressed RTP November 2005
トンプソン、他 圧縮されたRTP2005年11月に多重送信された最も良い現在の習慣[23ページ]RFC4170トンネリング
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Thompson, et al. Best Current Practice [Page 24]
トンプソン、他 最も良い現在の習慣[24ページ]
一覧
スポンサーリンク
