RFC4445 日本語訳
4445 A Proposed Media Delivery Index (MDI). J. Welch, J. Clark. April 2006. (Format: TXT=24171 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Welch Request for Comments: 4445 IneoQuest Technologies Category: Informational J. Clark Cisco Systems April 2006
ウェールズ人がコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4445年のIneoQuest技術カテゴリ: 情報のJ.クラークシスコシステムズ2006年4月
A Proposed Media Delivery Index (MDI)
提案されたメディア配送インデックス(MDI)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. There are IETF standards which are highly applicable to the space defined by this document as its applicability, in particular, RFCs 3393 and 3611, and there is ongoing IETF work in these areas as well. The IETF also notes that the decision to publish this RFC is not based on IETF review for such things as security, congestion control, MIB fitness, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 このドキュメントによって適用性と定義されたスペースに非常に適切なIETF規格があります、特に、RFCs3393と3611、進行中のIETF仕事がまた、これらの領域にあります。 また、IETFは、このRFCを発行するという決定が配備されたプロトコルとのセキュリティのようなもの、輻輳制御、MIBフィットネス、または不適当な相互作用のためのIETFレビューに基づいていないことに注意します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media, MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.
このメモはネットワークをモニターするための診断用道具か質のインディケータが到着時間とパケット損失に機密のストリーミング・メディア、MPEGビデオ、ボイス・オーバー IP、または他の情報などのアプリケーションを提供するつもりであったように使用できるメディアDelivery Index(MDI)測定を定義します。 それは交通ジターのしるし、名目上の流速からの逸脱の基準、および特定の流れのための一目におけるデータ損失測定を供給します。 例えば、MDIは参照としてUDPストリーミング・メディアを運びながらネットワークを特徴付けて、比較する際に使用されるかもしれません。
The MDI measurement defined in this memo is intended for Information only.
このメモで定義されたMDI測定は情報だけのために意図します。
Welch & Clark Informational [Page 1] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[1ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
1. Introduction
1. 序論
There has been considerable progress over the last several years in the development of methods to provide for Quality of Service (QoS) over packet-switched networks to improve the delivery of streaming media and other time-sensitive and packet-loss-sensitive applications such as [i1], [i5], [i6], [i7]. QoS is required for many practical networks involving applications such as video transport to assure the availability of network bandwidth by providing upper limits on the number of flows admitted to a network, as well as to bound the packet jitter introduced by the network. These bounds are required to dimension a receiver`s buffer to display the video properly in real time without buffer overflow or underflow.
そして、かなりの進展が時間敏感な状態でストリーミング・メディアで他の配送を改良するためにパケット交換網の上にService(QoS)のQualityに備える方法の開発におけるここ数年間ある、パケットの損失敏感である、[i1]、[i5]、[i6][i7]などのアプリケーション QoSは多くのビデオ輸送などの応用にかかわる実用的なネットワークのためによくバウンドのようにネットワークに認められた流れの数における最大の限界を提供するのによるネットワーク回線容量の有用性にネットワークによって導入されたパケットジターを保証しなければなりません。 これらの領域が、リアルタイムでバッファオーバーフローもアンダーフローなしでビデオを適切に表示するのに受信機のものがバッファリングする寸法に必要です。
Now that large-scale implementations of such networks based on RSVP and Diffserv are undergoing trials [i3] and being specified by major service providers for the transport of streaming media such as MPEG video [i4], there is a need to diagnose issues easily and to monitor the real-time effectiveness of networks employing these QoS methods or to assess whether they are required. Furthermore, due to the significant installed base of legacy networks without QoS methods, a delivery system`s transitional solution may be composed of networks with and without these methods, thus increasing the difficulty in characterizing the dynamic behavior of these networks.
または、RSVPとDiffservに基づくそのようなネットワークの大規模な実現が公判[i3]を受けて、主要サービスプロバイダーによってMPEGビデオ[i4]などのストリーミング・メディアの輸送に指定されているので容易に問題を診断して、これらのQoS方法を使うネットワークのリアルタイムの有効性をモニターする必要がある、それらが必要であるか否かに関係なく、評価するために。 その上、QoS方法のない遺産ネットワークの重要なインストールされたベースのため、配送システムの過渡的な解決策はこれらの方法のあるなしにかかわらずネットワークで構成されるかもしれません、その結果、これらのネットワークの動的挙動を特徴付けながら、困難を増やします。
The purpose of this memo is to describe a set of measurements that can be used to derive a Media Delivery Index (MDI) that indicates the instantaneous and longer-term behavior of networks carrying streaming media such as MPEG video.
このメモの目的はMPEGビデオなどのストリーミング・メディアを運ぶネットワークの瞬時に起こっていて、より長い期間の振舞いを示すメディアDelivery Index(MDI)を引き出すのに使用できる1セットの測定について説明することです。
While this memo addresses monitoring MPEG Transport Stream (TS) packets [i8] over UDP, the general approach is expected to be applicable to other streaming media and protocols. The approach is applicable to both constant and variable bit rate streams though the variable bit rate case may be somewhat more difficult to calculate. This document focuses on the constant bit rate case as the example to describe the measurement, but as long as the dynamic bit rate of the encoded stream can be determined (the "drain rate" as described below in Section 3), then the MDI provides the measurement of network- induced cumulative jitter. Suggestions and direction for calculation of MDI for a variable bit rate encoded stream may be the subject of a future document.
このメモがUDPの上にモニターしているMPEG Transport Stream(TS)パケット[i8]を記述している間、一般的方法が他のストリーミング・メディアとプロトコルに適切であると予想されます。 変化するビット伝送速度ケースは計算するのがいくらか難しいかもしれませんが、アプローチは一定のものと同様に可変なビット伝送速度の流れに適切です。 このドキュメントは測定について説明するために例として固定ビットレートケースに焦点を合わせますが、コード化された流れのダイナミックなビット伝送速度を測定できる(セクション3で以下で説明される「排水率」)限り、そして、MDIはネットワークの誘発された累積しているジターの測定を提供します。 可変ビット伝送速度コード化された流れのためのMDIの計算のための提案と指示は将来のドキュメントの対象であるかもしれません。
Network packet delivery time variation and various statistics to characterize the same are described in a generic approach in [i10]. The approach is capable of being parameterized for various purposes with the intent of defining a flexible, customizable definition that can be applied to a wide range of applications and further
ネットワークパケット配信時間変化と同じように特徴付ける様々な統計は[i10]の一般的方法で説明されます。 さまざまなアプリケーションに適用されて、より遠い場合があるフレキシブルで、カスタマイズ可能な定義を定義する意図によって様々な目的のためにアプローチがparameterizedされることができます。
Welch & Clark Informational [Page 2] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[2ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
experimentation. Other approaches to characterizing jitter behavior are also captured such as in [i12]. A wide-ranging report format [i11] has been described to convey information including jitter for use with the RTP Control Protocol (RTCP) [i12]. The MDI is instead intended to specifically address the need for a scalable, economical-to-compute metric that characterizes network impairments that may be imposed on streaming media, independent of control plane or measurement transport protocol or stream encapsulation protocol. It is a targeted metric for use in production networks carrying large numbers of streams for the purpose of monitoring the network quality of the flows or for other applications intended to analyze large numbers of streams susceptible to IP network device impairments. An example application is the burgeoning deployments of Internet Protocol Television (IPTV) by cable and telecommunication service providers. As described below, MDI provides for a readily scalable per-stream measure focused on loss and the cumulative effects of jitter.
実験。 また、[i12]などのようにジターの振舞いを特徴付けることへの他のアプローチを得ます。 広範囲のレポート形式[i11]は、RTP Controlプロトコル(RTCP)[i12]との使用のためのジターを含んでいて、情報を伝達するために説明されます。 MDIによる明確にメートル法でスケーラブルで、計算するために経済的なaの必要性を記述することを代わりに意図して、それはストリーミング・メディアに課されるかもしれないネットワーク損傷を特徴付けます、制御飛行機、測定トランスポート・プロトコルまたは流れのカプセル化プロトコルの如何にかかわらずことです。 それは流れのネットワーク品質をモニターする目的のための多くの流れを運ぶ生産ネットワークにおける使用かIPネットワーク装置損傷に影響されやすい多くの流れを分析することを意図する他のアプリケーションにおいてメートル法で狙うaです。 例のアプリケーションはケーブルと電気通信サービスプロバイダーによるインターネットプロトコルTelevision(IPTV)の芽の展開です。 以下で説明されるように、MDIは損失に集中している1流れあたり1つの容易にスケーラブルな程度とジターの累積している効果に備えます。
2. Media Delivery Index Overview
2. メディア配送インデックス概観
The MDI provides a relative indicator of needed buffer depths at the consumer node due to packet jitter as well as an indication of lost packets. By probing a streaming media service network at various nodes and under varying load conditions, it is possible to quickly identify devices or locales that introduce significant jitter or packet loss to the packet stream. By monitoring a network continuously, deviations from nominal jitter or loss behavior can be used to indicate an impending or ongoing fault condition such as excessive load. It is believed that the MDI provides the necessary information to detect all network-induced impairments for streaming video or voice-over-IP applications. Other parameters may be required to troubleshoot and correct the impairments.
MDIは無くなっているパケットのしるしと同様にパケットジターのため必要なバッファの相対的なインディケータに消費者ノードにおける深層を提供します。 ストリーミングを調べることによって、メディアは様々なノードでネットワークにサービスを提供します、そして、異なった負荷状態の下で、すぐに重要なジターかパケット損失をパケットの流れに紹介する装置か現場を特定するのは可能です。 絶え間なくネットワークをモニターすることによって、負担過重などの迫るか進行中の欠点状態を示すのに名目上のジターか損失の振舞いからの逸脱を使用できます。 MDIがストリーミング・ビデオかナレーターの声IPアプリケーションのためのすべてのネットワークによって誘発された損傷を検出するために必要事項を提供すると信じられています。 他のパラメタが、損傷を障害調査して、修正するのに必要であるかもしれません。
The MDI is updated at the termination of selected time intervals spanning multiple packets that contain the streaming media (such as transport stream packets in the MPEG-2 case). The Maximums and Minimums of the MDI component values are captured over a measurement time. The measurement time may range from just long enough to capture an anticipated network anomaly during a troubleshooting exercise to indefinitely long for a long-term monitoring or logging application. The Maximums and Minimums may be obtained by sampling the measurement with adequate frequency.
ストリーミング・メディア(MPEG-2場合における輸送流れのパケットなどの)を含む複数のパケットにかかる選択された時間間隔の終了のときにMDIをアップデートします。 測定時間MDI成分値のMaximumsとMinimumsを捕らえます。 測定時間はちょうどトラブルシューティング運動の間、長期のモニターか伐採アプリケーションには無期限に長く予期されたネットワーク異常を得ることができるくらい長さから変化するかもしれません。 適切な頻度で測定を抽出することによって、MaximumsとMinimumsを入手するかもしれません。
Welch & Clark Informational [Page 3] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[3ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
3. Media Delivery Index Components
3. メディア配送インデックスコンポーネント
The MDI consists of two components: the Delay Factor (DF) and the Media Loss Rate (MLR).
MDIは2つのコンポーネントから成ります: 遅れ要素(DF)とメディアの損失は(MLR)を評定します。
3.1. Delay Factor
3.1. 遅れ要素
The Delay Factor is the maximum difference, observed at the end of each media stream packet, between the arrival of media data and the drain of media data. This assumes the drain rate is the nominal constant traffic rate for constant bit rate streams or the piece-wise computed traffic rate of variable rate media stream packet data. The "drain rate" here refers to the payload media rate; e.g., for a typical 3.75 Mb/s MPEG video Transport Stream (TS), the drain rate is 3.75 Mb/s -- the rate at which the payload is consumed (displayed) at a decoding node. If, at the sample time, the number of bytes received equals the number transmitted, the instantaneous flow rate balance will be zero; however, the minimum DF will be a line packet's worth of media data, as that is the minimum amount of data that must be buffered.
Delay Factorが最大の違いである、それぞれの終わりで観測されて、メディアはパケットを流します、メディアデータの到着とメディアデータの排水の間で。 これは、排水率が固定ビットレートの流れの名目上の一定の交通率であるか変動金利メディアの断片の計算された交通率が流れのパケットデータであると仮定します。 ここの「排水率」はペイロードメディアレートを示します。 例えば、典型的な3.75Mb/s MPEGビデオTransport Stream(TS)に関しては、排水率は3.75Mb/sです--ペイロードが解読ノードで消費される(表示します)レート。 バイト数がサンプル時に数が伝えた同輩を受けたなら、瞬間流量レートバランスはゼロになるでしょう。 しかしながら、最小のDFは線パケットのメディアデータの価値、同じくらいすなわち、バッファリングしなければならない最小のデータ量になるでしょう。
The DF is the maximum observed value of the flow rate imbalance over a calculation interval. This buffered media data in bytes is expressed in terms of how long, in milliseconds, it would take to drain (or fill) this data at the nominal traffic rate to obtain the DF. Display of DF with a resolution of tenths of milliseconds is recommended to provide adequate indication of stream variations for monitoring and diagnostic applications for typical stream rates from 1 to 40 Mb/s. The DF value must be updated and displayed at the end of a selected time interval. The selected time interval is chosen to be long enough to sample a number of TS packets and will, therefore, vary based on the nominal traffic rate. For typical stream rates of 1 Mb/s and up, an interval of 1 second provides a long enough sample time and should be included for all implementations. The Delay Factor indicates how long a data stream must be buffered (i.e., delayed) at its nominal bit rate to prevent packet loss. This time may also be seen as a measure of the network latency that must be induced from buffering, which is required to accommodate stream jitter and prevent loss. The DF`s max and min over the measurement period (multiple intervals) may also be displayed to show the worst case arrival time deviation, or jitter, relative to the nominal traffic rate in a measurement period. It provides a dynamic flow rate balance indication with its max and min showing the worst excursions from balance.
DFは計算間隔の間の流速不均衡の最大の観測値です。 バイトで表現されるこのバッファリングされたメディアデータはどれくらい長さに関して言い表されるか、ミリセカンドでそれは、DFを入手するために名目上の交通率でこのデータを消耗させる(いっぱいになる)にはかかるでしょう。 ミリセカンドの10分の1の解決によるDFの表示が1〜40Mb/sの典型的な流れの率のモニターしていて診断しているアプリケーションに流れの変化の適切なしるしを供給することが勧められます。 選択された時間間隔の終わりにDF値をアップデートして、表示しなければなりません。 選択された時間間隔は、多くのTSパケットを抽出できるくらい長くなるように選ばれていて、したがって、名目上の交通率に基づいて異なるでしょう。 1Mb/s以上の典型的な流れの率において、1秒の間隔は、十分長いサンプル時間を提供して、すべての実現のために含まれるべきです。 Delay Factorは、パケット損失を防ぐために名目上のビット伝送速度でどれくらい長いデータ・ストリームをバッファリングしなければならないかを(すなわち、延着します)示します。 また、バッファリングから引き起こさなければならなくて、そうするネットワーク潜在の測定が流れのジターを収容して、損失を防ぐのが必要であるので、今回に遭遇するかもしれません。 また、最悪の場合到着時間の逸脱、またはジターを示しているために測定の期間(複数の間隔)のDFの最大と分を表示するかもしれません、測定の期間の名目上の交通率に比例して。 それはその最大とバランスから示している中で遠足最も悪い分をダイナミックな流速バランス指示に提供します。
The Delay Factor gives a hint of the minimum size of the buffer required at the next downstream node. As a stream progresses, the variation of the Delay Factor indicates packet bunching or packet
Delay Factorは次の川下のノードで必要であるバッファの最小規模のヒントを与えます。 流れが進歩をするとき、Delay Factorの変化はパケットの束になるかパケットを示します。
Welch & Clark Informational [Page 4] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[4ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
gaps (jitter). Greater DF values also indicate that more network latency is necessary to deliver a stream due to the need to pre-fill a receive buffer before beginning the drain to guarantee no underflow. The DF comprises a fixed part based on packet size and a variable part based on the buffer utilization of the various network component switch elements that comprise the switched network infrastructure [i2].
ギャップ(ジター)。 また、大DF値は、より多くのネットワーク潜在がアンダーフローを全く保証しないように排水を始める前に受信バッファをあらかじめいっぱいにする必要性による流れを届けるのに必要であることを示します。 DFはパケットサイズに基づく固定部分と交換網インフラストラクチャ[i2]を含む様々なネットワーク要素スイッチ素子のバッファ利用に基づく可変部分を包括します。
To further detail the calculation of DF, consider a virtual buffer VB used to buffer received packets of a stream. When a packet P(i) arrives during a calculation interval, compute two VB values, VB(i,pre) and VB(i,post), defined as:
詳細への計算、DFでは、VBが以前はよくバッファリングしていた仮想のバッファが流れのパケットを受けたと考えてください。 VB、aパケットP(i)が計算間隔の間、到着したら2つのVB値を計算してください、(i、前、)、以下と定義されたVB(i、ポスト)
VB(i,pre) = sum (Sj) - MR * Ti; where j=1..i-1 VB(i,post) = VB(i,pre) + Si
VB、(i、前、)、= (Sj)をまとめてください--MR*Ti どこj=1。i-1 VB(i、ポスト)がVBと等しい、(i、前、)、+ Si
where Sj is the media payload size of the jth packet, Ti is the relative time at which packet i arrives in the interval, and MR is the nominal media rate.
Sjがjthパケットのメディアペイロードサイズであるところでは、Tiはパケットiが間隔で達する相対的な時間です、そして、MRは名目上のメディアレートです。
VB(i,pre) is the Virtual Buffer size just before the arrival of P(i). VB(i,post) is the Virtual Buffer size just after the arrival of P(i).
VB、(i、前、)、P(i)の到着のすぐ前のVirtual Bufferサイズはそうです。 VB(i、ポスト)はP(i)の到着のすぐ後のVirtual Bufferサイズです。
The initial condition of VB(0) = 0 is used at the beginning of each measurement interval. A measurement interval is defined from just after the time of arrival of the last packet during a nominal period (typically 1 second) as mentioned above to the time just after the arrival of the last packet of the next nominal period.
VB(0)=0に関する初期条件はそれぞれの測定間隔の始めに使用されます。 測定間隔は次の名目上の期間の最後のパケットの到着のすぐ後に以上のようの名目上の期間(通常1秒)の最後のパケットの到着時刻の後、正当であるのから時間まで定義されます。
During a measurement interval, if k packets are received, then there are 2*k+1 VB values used in deriving VB(max) and VB(min). After determining VB(max) and VB(min) from the 2k+1 VB samples, DF for the measurement interval is computed and displayed as:
測定間隔の間、kパケットが受け取られているなら、VB(最大)とVB(分)を引き出す際に使用される2つの*k+1VB値があります。 2k+1VBのサンプルからVB(最大)とVB(分)を決定した後に、以下として測定間隔の間のDFを計算して、表示します。
DF = [VB(max) - VB(min)]/ MR
DFは/MRと等しいです[VB(最大)--VB(分)]。
As noted above, a measurement interval of 1 second is typically used. If no packets are received during an interval, the last DF calculated during an interval in which packets did arrive is displayed. The time of arrival of the last previous packet is always retained for use in calculating VB when the next packet arrives (even if the time of the last received packet spans measurement intervals). For the first received measurement interval of a measurement period, no DF is calculated; however, packet arrival times are recorded for use in calculating VB during the following interval.
上で述べたように、1秒の測定間隔は通常費やされます。 間隔の間、パケットを全く受け取らないなら、パケットが到着した間隔の間に計算された最後のDFを表示します。 次のパケットが到着するとき(最終時間がパケット長さ測定間隔を受けたとしても)、最後の前のパケットの到着時刻は計算のVBにおける使用のためにいつも保有されます。 測定の期間の最初の容認された測定間隔の間、DFは全く計算されません。 しかしながら、パケット到着時間は計算のVBにおける使用のために次の間隔の間、記録されます。
Welch & Clark Informational [Page 5] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[5ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
3.2. Media Loss Rate
3.2. メディア損失率
The Media Loss Rate is the count of lost or out-of-order flow packets over a selected time interval, where the flow packets are packets carrying streaming application information. There may be zero or more streaming packets in a single IP packet. For example, it is common to carry seven 188 Byte MPEG Transport Stream packets in an IP packet. In such a case, a single IP packet loss would result in 7 lost packets counted (if those 7 lost packets did not include null packets). Including out-of-order packets is important, as many stream consumer-type devices do not attempt to reorder packets that are received out of order.
メディアLoss Rateは選択された時間間隔の上間の無くなっているか故障している流れパケットのカウントです。そこでは、流れパケットがストリーミング・アプリケーション情報を運ぶパケットです。 ゼロか、よりストリーミングのパケットが単一のIPパケットにあるかもしれません。 例えば、IPパケットで7つの188Byte MPEG Transport Streamパケットを運ぶのは一般的です。 このような場合には、単一のIPパケット損失は無くなっているパケットが数えた7をもたらすでしょう(それらの7つの無くなっているパケットがヌルパケットを含んでいなかったなら)。 故障しているパケットを含んでいるのは重要です、多くの流れの消費者タイプ装置が受け取られていているパケットを故障していた状態で追加注文に試みないとき。
3.3. Media Delivery Index
3.3. メディア配送インデックス
Combining the Delay Factor and Media Loss Rate quantities for presentation results in the following MDI:
プレゼンテーションのためにDelay FactorとメディアLoss Rate量を結合すると、以下のMDIはもたらされます:
DF:MLR Where: DF is the Delay Factor MLR is the Media Loss Rate
DF: MLR、どこ: DFによるDelay Factor MLRがメディアLoss Rateであるということです。
At a receiving node, knowing its nominal drain bit rate, the DF`s max indicates the size of buffer required to accommodate packet jitter. Or, in terms of Leaky Bucket [i9] parameters, DF indicates bucket size b, expressed in time to transmit bucket traffic b, at the given nominal traffic rate, r.
受信ノードでは、名目上の排水ビット伝送速度を知っていて、DFの最大は、バッファのサイズがパケットジターを収容するのが必要であることを示します。 または、Leaky Bucket[i9]パラメタに関して、DFは与えられた名目上の交通率(r)で時間内にバケツ交通bを伝えるために表されたバケツサイズbを示します。
3.4. MDI Application Examples
3.4. MDIアプリケーションの例
If a known, well-characterized receive node is separated from the data source by unknown or less well-characterized nodes such as intermediate switch nodes, the MDI measured at intermediate data links provides a relative indication of the behavior of upstream traffic flows. DF difference indications between one node and another in a data stream for a given constant interval of calculation can indicate local areas of traffic congestion or possibly misconfigured QoS flow specification(s) leading to greater filling of measurement point local device buffers, resultant flow rate deviations, and possible data loss.
aである、知られていて、よく特徴付けられる、中間的スイッチノードなどの未知の、または、それほどよく特徴付けられなかったノードでデータ送信端末から切り離されたノードを受け取ってください、そして、中間的データ・リンクで測定されたMDIは上流の交通の流れの振舞いのa相対的なしるしを供給します。 計算の或る値間隔の間のデータ・ストリームの1つのノードと別のものの間のDF違いの指摘は、測定ポイントローカル装置バッファ、結果の流速逸脱、および可能なデータの損失の、よりすばらしい充填に通じながら、交通渋滞かことによるとmisconfigured QoS流れ仕様の局部を示すことができます。
Welch & Clark Informational [Page 6] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[6ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
For a given MDI, if DF is high and/or the DF Max-Min captured over a significant measurement period of multiple intervals is high, jitter has been detected but the longer-term, average flow rate may be nominal. This could be the result of a transient flow upset due to a coincident traffic stream unrelated to the flow of interest causing packet bunching. A high DF may cause downstream buffer overflow or underflow or unacceptable latency even in the absence of lost data.
DFが高いか、そして、そして/または、複数の間隔の重要な測定の期間にわたって得られたDFマックス-分が高い、与えられたMDIに関しては、ジターは検出されましたが、より長い期間の、そして、平均した流速は名目上であるかもしれません。 これはパケットの束になることを引き起こす興味がある流れに関係ないコインシデンス交通の流れのため台無しになる一時的な流れの結果であるかもしれません。 高いDFはロストデータがないときでさえ川下のバッファオーバーフロー、アンダーフローまたは容認できない潜在を引き起こすかもしれません。
Due to transient network failures or DF excursions, packets may be lost within the network. The MLR component of the MDI shows this condition.
一時的なネットワーク失敗かDF遠足のため、パケットはネットワークの中で失われるかもしれません。 MDIのMLRの部品はこの状態を示しています。
Through automated or manual flow detection and identification and subsequent MDI calculations for real-time statistics on a flow, the DF can indicate the dynamic deterioration or increasing burstiness of a flow, which can be used to anticipate a developing network operation problem such as transient oversubscription. Such statistics can be obtained for flows within network switches using available switch cpu resources due to the minimal computational requirements needed for small numbers of flows. Statistics for all flows present on, say, a gigabit Ethernet network, will likely require dedicated hardware facilities, though these can be modest, as buffer requirements and the required calculations per flow are minimal. By equipping network switches with MDI measurements, flow impairment issues can quickly be identified, localized, and corrected. Until switches are so equipped with appropriate hardware resources, dedicated hardware tools can provide supplemental switch statistics by gaining access to switch flows via mirror ports, link taps, or the like as a transition strategy.
流れにおけるリアルタイムの統計のための自動化されたか手動の流れ検出、識別、およびその後のMDI計算で、DFは流れのダイナミックな劣化か増加するburstinessを示すことができます。(流れは展開しているネットワーク操作上の問題を予期するのにおいて中古の一時的な応募超過であるかもしれません)。 少ない数の流れに必要である最小量のコンピュータの要件のため利用可能なスイッチcpuリソースを使用することでネットワークスイッチの中の流れようにそのような統計を得ることができます。 たとえば、ギガビットイーサネットネットワーク、意志の現在の流れがおそらく必要とするすべてのための統計はハードウェア施設を捧げました、これらが穏やかである場合がありますが、1流れあたりのバッファ要件と必要な計算が最小限ときに。 ネットワークスイッチにMDI測定値を持たせることによって、すぐに流れ損傷問題を特定して、局所化されて、修正できます。 専用ハードウェアツールは、変遷戦略として鏡のポート、リンク消灯ラッパ、または同様のもので流れを切り換えるためにアクセスを得ることによって、スイッチはそのように適切なハードウェアリソースを備えるまで補足のスイッチ統計を提供できます。
The MDI figure can also be used to characterize a flow decoder's acceptable performance. For example, an MPEG decoder could be characterized as tolerating a flow with a given maximum DF and MLR for acceptable display performance (acceptable on-screen artifacts). Network conditions such as Interior Gateway Protocol (IGP) reconvergence time then might also be included in the flow tolerance DF resulting in a higher-quality user experience.
また、流れデコーダの許容性能を特徴付けるのにMDI数値を使用できます。 例えば、許容表示性能(許容できるスクリーンの上の人工物)のために流れを許容するとして与えられた最大のDFとMLRでMPEGデコーダを特徴付けることができました。 そして、また、Interiorゲートウェイプロトコル(IGP)再集合時間などのネットワーク状態は、より高い品質ユーザー・エクスペリエンスをもたらす流れ寛容DFに含まれるかもしれません。
4. Summary
4. 概要
The MDI combines the Delay Factor, which indicates potential for impending data loss, and Media Loss Rate as the indicator of lost data. By monitoring the DF and MLR and their min and max excursions over a measurement period and at multiple strategic locations in a network, traffic congestion or device impairments may be detected and isolated for a network carrying streaming media content.
MDIはロストデータのインディケータとしてDelay FactorとメディアLoss Rateを結合します。(Delay Factorはデータの損失を迫らせる可能性を示します)。 測定の期間の上と、そして、ネットワークにおける複数の要衝でDF、MLR、それらの分、および最大遠足をモニターすることによって、交通渋滞か装置損傷が、ストリーミング・メディア内容を運ぶネットワークのために、検出されて、隔離されるかもしれません。
Welch & Clark Informational [Page 7] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[7ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
5. Security Considerations
5. セキュリティ問題
The measurements identified in this document do not directly affect the security of a network or user. Actions taken in response to these measurements that may affect the available bandwidth of the network or the availability of a service is out of scope for this document.
本書では特定された測定値は直接ネットワークかユーザのセキュリティに影響しません。 このドキュメントのための範囲の外にネットワークの利用可能な帯域幅に影響するかもしれないこれらの測定値に対応して取られた行動かサービスの有用性があります。
Performing the measurements described in this document only requires examination of payload header information (such as MPEG transport stream headers or RTP headers) to determine nominal stream bit rate and sequence number information. Content may be encrypted without affecting these measurements. Therefore, content privacy is not expected to be a concern.
測定値が説明した実行は、名目上の流れのビット伝送速度と一連番号情報を測定するために本書ではペイロードヘッダー情報(MPEG輸送流れのヘッダーかRTPヘッダーなどの)の調査を必要とするだけです。 これらの測定値に影響しないで、内容はコード化されるかもしれません。 したがって、満足しているプライバシーは関心でないと予想されます。
6. Informative References
6. 有益な参照
[i1] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[i1] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[i2] Partridge, C., "A Proposed Flow Specification", RFC 1363, September 1992.
[i2] ヤマウズラ、C.、「提案された流れ仕様」、RFC1363、1992年9月。
[i3] R. Fellman, `Hurdles to Overcome for Broadcast Quality Video Delivery over IP` VidTranS 2002.
[i3]R.Fellman、'IPの上の放送の上質のビデオ配送のために打ち勝つハードル'VidTranS2002。
[i4] CableLabs `PacketCable Dynamic Quality-of-Service Specification`, PKT-SP-DQOS-I06-030415, 2003.
[i4]CableLabs'PacketCableのダイナミックなサービスの質仕様'、PKT-SP-DQOS-I06-030415、2003。
[i5] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
1997年9月の[i5]ShenkerとS.とヤマウズラ、C.とR.ゲラン、「保証されたサービスの質の仕様」RFC2212。
[i6] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[i6] Wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC2211、1997年9月。
[i7] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[i7] ブレーデン、R.、クラーク、D.、およびS.Shenker、「インターネット構造における統合サービス:」 「概観」、RFC1633、1994年6月。
[i8] ISO/IEC 13818-1 (MPEG-2 Systems)
[i8]ISO/IEC13818-1(MPEG-2台のシステム)
[i9] V. Raisanen, "Implementing Service Quality in IP Networks", John Wiley & Sons Ltd., 2003.
[i9]V.Raisanen、「IPネットワークでサービス品質を実行します」、ジョンワイリーと息子株式会社、2003。
[i10] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[i10]デミチェリスとC.とP.Chimento、「IPパフォーマンス測定基準(IPPM)における、メートル法のIPパケット遅れ変化」、RFC3393、2002年11月。
Welch & Clark Informational [Page 8] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[8ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
[i11] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[i11]フリードマン、T.、カセレス、R.、およびA.クラーク、「RTP制御プロトコルの拡張レポート(RTCP XR)」、RFC3611 2003年11月。
[i12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[i12] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
7. Acknowledgements
7. 承認
The authors gratefully acknowledge the contributions of Marc Todd and Jesse Beeson of IneoQuest Technologies, Inc., Bill Trubey and John Carlucci of Time Warner Cable, Nishith Sinha of Cox Communications, Ken Chiquoine of SeaChange International, Phil Proulx of Bell Canada, Dr Paul Stallard of TANDBERG Television, Gary Hughes of Broadbus Technologies, Brad Medford of SBC Laboratories, John Roy of Adelphia Communications, Cliff Mercer, PhD of Kasenna, Mathew Ho of Rogers Cable, and Irl Duling of Optinel Systems for reviewing and evaluating early versions of this document and implementations for MDI.
作者は感謝してIneoQuest Technologies Inc.のマーク・トッドとジェシー・ビーソンの貢献を承諾します; タイム・ワーナーCableのビルTrubeyとジョン・カールーチ、Cox CommunicationsのNishithシンハ、国際SeaChangeのケンChiquoine、ベル・カナダのフィルProulx、TANDBERG Televisionのポール・スタラード博士、Broadbus Technologies、SBC研究所のブラッド・メドフォードのゲイリー・ヒューズ、アデルフィアコミュニケーションズ、クリフMercer、Kasennaの博士号、ロジャーズケーブルのマシューHoのジョン・ロイ、およびMDIのためにこのドキュメントと実現の早めのバージョンを見直して、評価するためのOptinel SystemsのIrl Duling。
Authors' Addresses
作者のアドレス
James Welch IneoQuest Technologies, Inc 170 Forbes Blvd Mansfield, Massachusetts 02048
ジェームスウェルチIneoQuest Technologies、Inc170フォーブズ・Blvdマンスフィールド、マサチューセッツ 02048
Phone: 508 618 0312 EMail: Jim.Welch@ineoquest.com
以下に電話をしてください。 0312年の508 618メール: Jim.Welch@ineoquest.com
James Clark Cisco Systems, Inc 500 Northridge Road Suite 800 Atlanta, Georgia 30350
アトランタ、ジェームスクラークシスコシステムズ、Inc500ノースリッジ道路Suite800ジョージア 30350
Phone: 678 352 2726 EMail: jiclark@cisco.com
以下に電話をしてください。 2726年の678 352メール: jiclark@cisco.com
Welch & Clark Informational [Page 9] RFC 4445 A Proposed Media Delivery Index (MDI) April 2006
支払いを回避してください。そうすれば、提案されたメディア配送あたりクラークInformational[9ページ]のRFC4445は2006年4月に(MDI)に索引をつけます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Welch & Clark Informational [Page 10]
ウェールズであってクラークInformationalです。[10ページ]
一覧
スポンサーリンク