Network Working Group J. Welch
Request for Comments: 4445 IneoQuest Technologies
Category: Informational J. Clark
Cisco Systems
April 2006
A Proposed Media Delivery Index (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).
著作権（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標準のRFCは3393と3611は、具体的には、存在し、そしてこれらの分野で現在進行中のIETF仕事はそこにもあります。また、IETFは、このRFCを公開する決定は、セキュリティ、輻輳制御、MIBフィットネス、または展開されたプロトコルとの不適切な相互作用のようなもののためにIETFレビューに基づいていないことを指摘しています。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
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、または他の情報などのアプリケーションを提供することを意図するものでネットワークを監視するための品質インジケータとして使用することができるメディア配信インデックス（MDI）測定を定義しますおよびパケット損失。これは、トラフィック・ジッタの指示、公称流量からの偏差の尺度、および特定のフローのために一目でわかる測定データ損失を提供します。例えば、MDIは、UDPストリーミングメディアを搬送するネットワークを特徴づけると比較における基準として使用することができます。
The MDI measurement defined in this memo is intended for Information only.
このメモで定義されたMDI測定は情報のみを意図しています。
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.
ストリーミングメディアとのような他の時間に敏感とパケットロスの影響を受けやすいアプリケーションの配信を改善するために、サービスのパケット交換ネットワーク上での品質（QoS）を提供するための方法の開発の最後の数年間でかなりの進展がありました[I1]、[I5]、[I6]、[I7]。 QoSは、ビデオトランスポートなどのアプリケーションのネットワークに許可されたフローの数に上限を設けることによって、ネットワーク帯域幅の利用可能性を保証するだけでなく、ネットワークによって導入されたパケットジッタを結合することを含む、多くの実用的なネットワークのために必要とされます。これらの境界は、バッファオーバーフローやアンダーフローなしにリアルタイムで適切に映像を表示するためにreceiver`sバッファ寸法を記入する必要があります。
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メソッドなしでレガシーネットワークの有意なインストールベースに、送達system`s移行溶液は、このように、これらのネットワークの動的挙動を特徴づけるの困難を増加させる、これらの方法とすることなく、ネットワークから構成されてもよいです。
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ビデオのようなストリーミングメディアを搬送するネットワークの瞬間と長期的な挙動を示しているメディア配信インデックス（MDI）を導出するために使用することができる測定値のセットを記述することです。
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トランスポートストリーム（TS）パケット[6-18]が、一般的なアプローチは、他のストリーミングメディア及びプロトコルに適用可能であることが期待されています。可変ビットレートの場合は、計算する幾分より困難であり得るけれどもアプローチは、定常および可変ビットレートストリームの両方に適用可能です。この文書は、測定を説明するために例として、固定ビットレートの場合に焦点を当てたが、あれば（第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 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.
ネットワークパケット配信時間変動および様々な統計は、[I10]で一般的なアプローチで説明されている同じを特徴付けます。アプローチは、アプリケーション及びさらなる実験の広い範囲に適用することができる柔軟な、カスタマイズ定義を定義する目的で様々な目的のためにパラメータ化されることが可能です。ジッタ挙動を特徴付けるの他のアプローチはまた、[I12]のように捕捉されます。幅広いレポート形式[I11]はRTP制御プロトコル（RTCP）[I12]と共に使用するためのジッタを含む情報を伝達するために記載されています。 MDIは、代わりに、具体的に、制御プレーンまたは測定トランスポートプロトコルまたはストリームカプセル化プロトコルとは無関係に、ストリーミングメディアに課されることができるネットワーク障害を特徴づけるスケーラブルな、経済的なツー計算メトリックの必要性に対処することを意図しています。これは、流れのネットワーク品質を監視する目的で、またはIPネットワーク装置の障害を受けやすいストリームの多数を分析することを意図し、他の用途のためのストリームの多数を保有する生産ネットワークで使用するための標的化メトリックです。サンプルアプリケーションは、ケーブルおよび電気通信サービスプロバイダによるインターネット・プロトコル・テレビジョン（IPTV）の急成長の展開です。以下に説明するように、MDIは、損失およびジッタの累積的な影響に焦点を当てて容易に拡張ストリーム毎の尺度を提供します。
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.
MDIは、（例えば、MPEG-2の場合におけるトランスポートストリームパケットなど）のストリーミングメディアを含む複数のパケットにまたがる選択された時間間隔の終了時に更新されます。 MDI成分値の最大値と最小値は、測定時間にわたって捕捉されます。測定時間は、長期的なモニタリングやロギングアプリケーションのための無期限の長いのトラブルシューティングの運動中に予想されるネットワークの異常をキャプチャするだけの十分な長さの範囲とすることができます。最大値と最小値は、十分な頻度で測定をサンプリングすることによって得ることができます。
The MDI consists of two components: the Delay Factor (DF) and the Media Loss Rate (MLR).
遅延ファクター（DF）とメディア損失レート（MLR）：MDIは、2つのコンポーネントで構成されています。
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.
遅延要因は、メディアデータの到着とメディアデータのドレインとの間の各メディアストリームのパケットの終わりに観察された最大差です。これは、ドレインレートが一定のビットレートストリームの公称一定のトラフィックレートまたは可変レートのメディアストリームのパケットデータの区分計算トラフィックレートであると仮定します。 「ドレイン率は、」ここにペイロードメディア速度を指します。ペイロードが復号化ノードで消費（表示）される速度 - 例えば、典型的な3.75 MB / sのMPEGビデオトランスポートストリーム（TS）は、ドレイン率は3.75 Mb /秒です。 、サンプル時間で、受信したバイト数が送信数に等しい場合、瞬時流量バランスはゼロとなります。それはバッファリングしなければならないデータの最小量であるようしかし、最低限の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を取得するために、公称トラフィックレートで、このデータ。ミリ秒の十の解像度を持つDFの表示は1〜40 MB /秒の典型的な流れ速度の監視および診断アプリケーションのためのストリーム変動の十分な指標を提供することが推奨されます。 DF値が更新され、選択された時間間隔の最後に表示されなければなりません。選択された時間間隔は、TSパケットとの意志の数をサンプリングするのに十分に長くなるように選択され、従って、公称トラフィックレートに基づいて変化します。最大1メガビット/秒との典型的な流れ速度は、1秒の間隔が十分に長いサンプル時間を提供し、すべての実装のために含まれるべきです。遅延ファクタは、データ・ストリームは、パケットロスを防止するために、公称ビットレートで（すなわち、遅延）バッファリングされなければならない時間の長さを示しています。この時間は、ストリームのジッターを収容し、損失を防ぐために必要とされるバッファリング、から誘導されなければならないネットワーク遅延の尺度として見ることができます。測定期間（複数の間隔）にわたってDF`s maxおよびminは、測定期間中に公称トラフィックレートに対する最悪の場合の到達時間のずれ、またはジッタを示すために表示されてもよいです。それは、そのmaxとのバランスから、最悪のエクスカーションを示す分と動的流量バランスの指標を提供します。
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 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は、ストリームの受信パケットをバッファリングするために使用する仮想バッファを考えます。パケットP（i）が計算区間中に到着した場合、2つのVB値を計算し、VBは、（i、PRE）及びVB（I、ポスト）として定義されます。
VB(i,pre) = sum (Sj) - MR * Ti; where j=1..i-1 VB(i,post) = VB(i,pre) + Si
VB（I、PRE）= SUM（Sjに） - MR *のTi; J = 1..i-1 VB（I、ポスト）= VB（I、PRE）+の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には、j番目のパケットのメディアペイロードサイズであり、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（私、前は）単にP（i）の到着前に仮想バッファのサイズです。 VB（I、ポストは）単にP（i）の到着後、仮想バッファサイズです。
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（MAX）及びVB（分）を導出する際に使用される2つの* K + 1つのVBの値が存在します。 2K + 1つのVBサンプルから（MAX）及びVB（分）VBを決定した後、DFは、測定間隔のように計算されて表示されます。
DF = [VB(max) - VB(min)]/ MR
DF = [VB（MAX） - VB（分）] / MR
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の計算に使用するために記録されています。
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.
メディア損失率がフローパケットがストリーミングアプリケーション情報を運ぶパケットで選択された時間間隔にわたって紛失またはアウトオブオーダーフローパケットの数です。単一のIPパケット内のゼロ個以上のストリーミングパケットがあるかもしれません。例えば、IPパケットで7つの188バイトのMPEGトランスポートストリームパケットを運ぶのが一般的です。 （これらの7つの失われたパケットはヌルパケットが含まれていなかった場合）、そのような場合には、単一のIPパケット損失を計数7つの失われたパケットをもたらすであろう。アウトオブオーダーのパケットを含むことが重要である、などの多くのストリームの消費者型デバイスは、順不同で受信されたパケットの順序を変更しようとしないでください。
Combining the Delay Factor and Media Loss Rate quantities for presentation results in the following MDI:
以下のMDIでのプレゼンテーションの結果のための遅延要因とメディア損失率の数量を組み合わせます：
DF:MLR Where: DF is the Delay Factor MLR is the Media Loss Rate
DF：MLR：DFが遅延要因MLRでは、メディアの損失率であります
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`s maxは、パケットジッタを収容するために必要なバッファのサイズを示します。又は、リーキーバケット[I9]パラメータに関して、DFは、バケットサイズBを表し、R、所与の公称トラフィックレートでバケットトラフィックBを送信する時間で発現。
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.
既知の場合、ノードは、中間スイッチノードとして未知以下よく特徴付けノードによるデータソースから分離された受信十分に特徴付けられ、中間データリンクで測定されたMDIは、アップストリームトラフィックフローの挙動の相対的な指標を提供します。一つのノードから別のDF差分指標は、計算の所定の一定間隔のデータストリームのトラフィックの輻輳や測定点ローカルデバイスバッファのより高い充填をもたらす可能性が誤って設定QoSフロー仕様（単数または複数）の局所領域、得られた流量偏差を示すことができます、およびデータの損失。
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は、動的劣化又は過渡オーバーサブスクリプションなどの開発、ネットワークオペレーションの問題を予想するために使用することができる流量の増加バースト性を示すことができます。このような統計は、フローの少数のために必要な最小限の計算要件のために利用できるスイッチのCPUリソースを使用して、ネットワークスイッチ内のフローのために取得することができます。すべてのフローの統計情報は、たとえば、ギガビット・イーサネット・ネットワーク上に存在これらは控えめかも知れませんバッファの要件とフローごとの必要な計算が最小限であるとして、おそらく、専用のハードウェアの設備が必要になります。 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の図は、フローデコーダの許容可能なパフォーマンスを特徴付けるために使用することができます。例えば、MPEGデコーダは、許容可能な表示性能（許容される画面上のアーチファクト）のための所定の最大DF及びMLRと流れを許容するように特徴付けることができました。このような内部ゲートウェイプロトコル（IGP）再コンバージェンス時間などのネットワーク条件は、次に、より高い品質のユーザエクスペリエンスをもたらす流量公差DFに含まれるかもしれません。
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は、失われたデータの指標として、データの損失を差し迫った、そしてメディアのロス率の可能性があることを示し遅延要因を、兼ね備えています。測定期間にわたって、ネットワーク内の複数の戦略的な位置にDF及びMLRおよびそれらの最小値と最大偏位を監視することにより、交通渋滞またはデバイスの障害を検出することができ、ストリーミングメディアコンテンツを搬送するネットワークのための単離されました。
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ヘッダのような）ペイロードヘッダ情報の検査を必要とします。コンテンツは、これらの測定値に影響を与えることなく、暗号化されてもよいです。そのため、コンテンツのプライバシーを心配することはないと予想されます。
[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の機能的な仕様"、RFC 2205、1997年9月。
[i2] Partridge, C., "A Proposed Flow Specification", RFC 1363, September 1992.
[I2]ウズラ、C.、 "提案フロー仕様"、RFC 1363、1992年9月。
[i3] R. Fellman, `Hurdles to Overcome for Broadcast Quality Video Delivery over IP` VidTranS 2002.
[I3] R. Fellman、 `IP` VidTranS 2002上で放送品質のビデオ配信のために克服するためにハードル。
[i4] CableLabs `PacketCable Dynamic Quality-of-Service Specification`, PKT-SP-DQOS-I06-030415, 2003.
[I4] CableLabsの `のPacketCableダイナミックサービス品質のSpecification`、PKT-SP-DQOS-I06-030415、2003。
[i5] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
[i5の] Shenker、S.、ヤマウズラ、C.、およびR.ゲラン、 "保証されたサービスの質の仕様"、RFC 2212、1997年9月。
[i6] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[I6] Wroclawski、J.、 "制御負荷ネットワーク要素サービスの仕様"、RFC 2211、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、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[i8] ISO/IEC 13818-1 (MPEG-2 Systems)
【I8] ISO / IEC 13818-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パフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、RFC 3393、2002年11月。
[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）"、RFC 3611、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：リアルタイムアプリケーションのためのトランスポートプロトコル"、STD 64、RFC 3550、2003年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社のジェシービーソン、ビルTrubeyとタイムワーナーケーブルのジョン・カールッチ、コックス・コミュニケーションズのNishithシンハ、のSeaChange国際のケン・Chiquoine、ベル・カナダのフィルProulx、博士ポール・スタラードの貢献を認めますTANDBERGテレビ、Broadbus Technologies社のゲイリー・ヒューズ、SBC研究所のブラッド・メドフォード、アデルフィア・コミュニケーションズのジョン・ロイ、クリフマーサー、このドキュメントの初期バージョンをレビューし、評価するためのKasenna、ロジャースケーブルのマシュー・ホー、およびOptinelシステムのIRL Dulingの博士号のそして、MDIの実装。
Authors' Addresses
著者のアドレス
James Welch IneoQuest Technologies, Inc 170 Forbes Blvd Mansfield, Massachusetts 02048
ジェームズ・ウェルチIneoQuest Technologies、Inc.は170フォーブスブルバードマンスフィールド、マサチューセッツ州02048
Phone: 508 618 0312 EMail: Jim.Welch@ineoquest.com
電話：508 618 0312 Eメール：Jim.Welch@ineoquest.com
James Clark Cisco Systems, Inc 500 Northridge Road Suite 800 Atlanta, Georgia 30350
James Clark氏シスコシステムズ社500ノースリッジロードスイート800アトランタ、ジョージア30350
Phone: 678 352 2726 EMail: jiclark@cisco.com
電話：678 352 2726 Eメール：jiclark@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に及び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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。