Network Working Group S. Poretsky
Request for Comments: 4689 Reef Point Systems
Category: Informational J. Perser
Veriwave
S. Erramilli
Telcordia
S. Khurana
Motorola
October 2006
Terminology for Benchmarking Network-layer Traffic Control Mechanisms
ベンチマーキングネットワーク層のトラフィック制御メカニズムのための用語
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）。
Abstract
抽象
This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number.
この文書では、定義された基準に基づいてパケット分類を使用して、トラフィック制御を実装するデバイスのベンチマークのための用語を説明しています。用語は、IPトラフィック制御メカニズムを評価するために、データプレーンになされた測定に適用されます。パケット分類のための規則は、そのような差別化サービスコードポイント（DSCP）、又はそのようなポート番号などパケットペイロード内の任意のフィールドとしてIPヘッダ内の任意のフィールドに基づくことができます。
Table of Contents
目次
1. Introduction ....................................................2
2. Existing Definitions ............................................3
3. Term Definitions ................................................4
3.1. Configuration Terms ........................................4
3.1.1. Classification ......................................4
3.1.2. Codepoint Set .......................................4
3.1.3. Forwarding Congestion ...............................5
3.1.4. Congestion Management ...............................6
3.1.5. Flow ................................................7
3.2. Measurement Terms ..........................................7
3.2.1. Forwarding Capacity .................................7
3.2.2. Conforming Packet ...................................8
3.2.3. Nonconforming Packet ................................9
3.2.4. Forwarding Delay ....................................9
3.2.5. Jitter .............................................11
3.2.6. Undifferentiated Response ..........................11
3.3. Sequence Tracking .........................................12
3.3.1. Test Sequence Number ...............................12
3.3.2. Stream .............................................12
3.3.3. In-Sequence Packet .................................13
3.3.4. Out-of-Order Packet ................................14
3.3.5. Duplicate Packet ...................................14
3.4. Vectors ...................................................15
3.4.1. Intended Vector ....................................15
3.4.2. Offered Vector .....................................16
3.4.3. Expected Vectors ...................................16
3.4.4. Output Vectors .....................................23
4. Security Considerations ........................................30
5. Acknowledgements ...............................................30
6. References .....................................................31
6.1. Normative References ......................................31
6.2. Informative References ....................................31
New terminology is needed because most existing measurements assume the absence of congestion and only a single per-hop behavior. This document introduces several new terms that will allow measurements to be taken during periods of congestion.
ほとんどの既存の測定が混雑して、単一のホップ単位動作がないことを前提としているため、新しい用語が必要とされています。この文書では、測定が輻輳期間中に撮影できるようになりますいくつかの新しい用語を紹介します。
Another key difference from existing terminology is the definition of measurements as observed on egress and ingress of a device/system under test. Again, the existence of congestion requires the addition of egress measurements, as well as of those taken on ingress; without observing traffic leaving a device/system, it is not possible to say whether traffic-control mechanisms effectively dealt with congestion.
既存の用語から別の重要な違いは、被試験デバイス/システムの出入りに観察されるように測定値の定義です。再び、輻輳の存在は、同様に、入口に沿うもののような、出力の測定値の加算を必要とします。デバイス/システムから送信されるトラフィックを観測することなく、トラフィック制御メカニズムが効果的に渋滞に対処するかどうかを言うことはできません。
The principal measurements introduced in this document are vectors for rate, delay, and jitter, all of which can be observed with or without congestion of the Device Under Test (DUT)/System Under Test (SUT). This document describes only those terms relevant to measuring behavior of a DUT or SUT at the egress during periods of congestion. End-to-end and service-level measurements are beyond the scope of this document.
この文書に導入主測定は、被試験テスト（DUT）/システム（SUT）の下でのデバイスの輻輳の有無にかかわらず観察することができるすべてがレート、遅延、およびジッタのためのベクターです。この文書では、輻輳期間中に出口でDUTやSUTの振る舞いを測定することに関連する用語のみを説明しています。エンドツーエンドのサービス・レベルの測定は、このドキュメントの範囲を超えています。
RFC 1224, "Techniques for Managing Asynchronously Generated Alerts" [St91], is used for 'Time with fine enough units to distinguish between two events'.
RFC 1224は、[ST91]「非同期に発生アラートを管理するための技術は、」「二つの事象を区別するのに十分な細かな単位での時間」のために使用されます。
RFC 1242, "Benchmarking Terminology for Network Interconnect Devices", and RFC 2285, "Benchmarking Terminology for LAN Switching Devices", should be consulted before attempting to make use of this document.
RFC 1242は、RFC 2285および「ネットワーク相互接続デバイスのためのベンチマーキング用語」、「LANスイッチングデバイスのためのベンチマーキング用語」、この文書を使用するように試みる前に相談する必要があります。
RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", section 2, contains discussions of a number of terms relevant to network-layer traffic control mechanisms and should also be consulted.
RFC 2474は、セクション2「IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義は、」ネットワーク・レイヤトラフィック制御機構に関連する用語の数の議論を含み、また相談する必要があります。
For the sake of clarity and continuity, this RFC adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of reference.
明瞭さと継続のために、このRFCは、1242の定義は、参照を容易にするためのセクションでインデックスと一緒にグループ化されているRFCの第2章に記載された定義のテンプレートを採用しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [Br97]に記載されているように解釈されます。 RFC 2119は、可能な限り明確な基準トラック文書の意図を支援するために、これらのキーワードの使用を定義します。この文書は、これらのキーワードを使用していますが、この文書では、標準トラック文書ではありません。
DA Destination Address DS DiffServ DSCP DiffServ Code Point DUT Device Under Test IP Internet Protocol PHB Per Hop Behavior SA Source Address SUT System Under Test
テストテスト対象IPインターネットプロトコルPHBパーホップ行動SA元アドレスSUTシステムの下でDA宛先アドレスDSのDiffServ DSCP DiffServのコードポイントDUTデバイス
Definition: Selection of packets according to defined rules.
定義：定義されたルールに従ってパケットを選択します。
Discussion: Classification determines the per-hop behaviors and traffic conditioning functions, such as shaping and dropping, that are to be applied to the packet.
議論：分類は、パケットに適用されるそのような成形、滴下等のホップごとの振舞いとトラフィック調整機能を、決定します。
Classification of packets can be based on the DS field or IP Precedence in the packet header. Classification can be based on other IP header fields, such as IP Source Address (SA), Destination Address (DA), and protocol, or on fields in the packet payload, such as port number. Classification can also be based on ingress interface. It is possible to base classification on Multi-Field (MF) criteria such as IP source and destination addresses, protocol, and port number. For further discussion of packet classification and its network applications, see [Bl98].
パケットの分類は、パケットヘッダ内のDSフィールドまたはIP優先順位に基づくことができます。分類は、IPソースアドレス（SA）、宛先アドレス（DA）、およびプロトコルとして、またはそのようなポート番号などパケットのペイロードにフィールド上の他のIPヘッダフィールドに基づくことができます。分類はまた、入力インターフェイスに基づくことができます。このようなIP送信元および宛先アドレス、プロトコル、およびポート番号のようなマルチフィールド（MF）基準にベース分類することが可能です。パケット分類とそのネットワーク・アプリケーションの更なる議論については、[Bl98]を参照してください。
Measurement units: n/a
測定単位：N / A
See Also: None
参照：なし
Definition: The set of all DS Code-points or IP precedence values used during the test duration.
定義：テスト期間中に使用されるすべてのDSコードポイントまたはIP precedence値のセット。
Discussion: Describes all the code-point markings associated with packets that are input to the DUT/SUT. For each entry in the codepoint set, there are associated vectors describing the rate of traffic, delay, loss, or jitter containing that particular DSCP or IP precedence value.
議論：DUT / SUTに入力されたパケットに関連付けられているすべてのコードポイントのマーキングを記述します。コードポイントのセット内の各エントリについて、その特定のDSCPまたはIP precedence値を含むトラフィック、遅延、損失、またはジッターの速度を記述するベクトルが関連付けられています。
The treatment that a packet belonging to a particular code-point gets is subject to the DUT classifying packets to map to the correct PHB. Moreover, the forwarding treatment in general is also dependent on the complete set of offered vectors.
特定のコードポイントに属するパケット取得処理が正しいPHBにマップするためにパケットを分類DUTの対象となります。また、一般的には転送処理も提供ベクトルの完全なセットに依存しています。
Measurement Units: n/a
測定単位：N / A
See Also: None
参照：なし
Definition: A condition in which one or more egress interfaces are offered more packets than are forwarded.
定義：一つ以上の出力インターフェースが転送されるよりも多くのパケットを提供されている状態。
Discussion: This condition is a superset of the overload definition [Ma98]. Overload [Ma98] deals with overloading input and output interfaces beyond the maximum transmission allowed by the medium. Forwarding congestion does not assume ingress interface overload as the only source of overload on output interfaces.
ディスカッション：この条件は、過負荷の定義[MA98]のスーパーセットです。媒体によって許容される最大送信超えて入出力インターフェースの過負荷と過負荷[MA98]ディール。輻輳を転送する出力インターフェイスの過負荷の唯一の供給源として、入力インターフェイスの過負荷を想定していません。
Another difference between Forwarding Congestion and overload occurs when the SUT comprises multiple elements, in that Forwarding Congestion may occur at multiple points. Consider an SUT comprising multiple edge devices exchanging traffic with a single core device. Depending on traffic patterns, the edge devices may induce Forwarding Congestion on multiple egress interfaces on the core device.
転送輻輳と過負荷との間の別の違いは、SUTが複数の要素を含む場合、その転送輻輳内の複数の点で行うことができる起こります。シングルコアデバイスとトラフィックを交換する複数のエッジデバイスを含むSUTを考えます。トラフィックパターンに応じて、エッジデバイスは、コアデバイス上の複数の出力インターフェイスに転送輻輳を誘発することができます。
Throughput [Br91] defines the lower boundary of Forwarding Congestion. Throughput is the maximum offered rate with no Forwarding Congestion. At offered rates above throughput, the DUT/SUT is considered to be in a state of Forwarding Congestion.
スループット[Br91]は転送輻輳の下側の境界を画定します。スループットはありませんフォワーディング混雑で最大提供率です。スループット上記提供レートでは、DUT / SUTを転送輻輳状態であると考えられます。
Packet Loss, not increased Forwarding Delay, is the external observable metric used to indicate the condition of Forwarding Congestion. Packet Loss is a deterministic indicator of Forwarding Congestion. The condition of increased Forwarding Delay without Packet Loss is an indicator of Forwarding Congestion known as Incipient Congestion. Incipient Congestion is a non-deterministic indicator of Forwarding Congestion [Fl93]. As stated in [Ec98], RED [Br98] detects incipient congestion before the buffer overflows, but the current Internet environment is limited to packet loss as the mechanism for indicating congestion to the end-nodes. [Ra99] implies that it is impractical to build a black-box test to observe Incipient Congestion. [Ra99] instead introduces Explicit Congestion Notification (ECN) as a deterministic Black-Box method for observing Incipient Congestion. [Ra99] is an Experimental RFC with limited deployment, so ECN is not used for this particular methodology. For the purpose of
パケットロス、増加していない転送遅延は、転送輻輳の状態を示すために使用される外部観察できるメトリックです。パケット損失は、転送輻輳の決定論的指標です。パケットロスのない増加フォワーディングディレイの条件は、初期の輻輳として知られている転送輻輳の指標です。初期の輻輳が転送輻輳[Fl93]の非決定論的指標です。 【Ec98]で述べたように、RED [Br98]はバッファオーバーフローの前に初期輻輳を検出するが、現在のインターネット環境では、エンドノードに輻輳を示すための機構としての損失をパケットに制限されています。 【Ra99]は、初期的輻輳を観察するためにブラックボックステストを構築することは非現実的であることを意味します。 【Ra99】代わり初生輻輳を観察するための決定論的なブラックボックス法として明示的輻輳通知（ECN）を導入します。 ECNは、この特定の方法のために使用されないように[Ra99]は、限られた展開と実験RFCです。ために
"black-box" testing a DUT/SUT, this methodology uses Packet Loss as the indicator of Forwarding Congestion.
DUT / SUTを試験する「ブラックボックス」は、この方法は、転送輻輳の指標としてパケット損失を使用します。
Ingress observations alone are not sufficient to cover all cases in which Forwarding Congestion may occur. A device with an infinite amount of memory could buffer an infinite number of packets and eventually forward all of them. However, these packets may or may not be forwarded during the test duration. Congestion Collapse [Na84] is defined as the state in which buffers are full and all arriving packets MUST be dropped across the network. Even though ingress interfaces accept all packets without loss, Forwarding Congestion is present in this hypothetical device.
イングレスの観察だけでは転送の輻輳が発生する可能性のあるすべてのケースをカバーするのに十分ではありません。メモリの無限量を有するデバイスは、パケットの無限の数をバッファリングし、最終的に前方にそれらのすべてができました。しかし、これらのパケットは、または試験期間中に転送されなくてもよいです。輻輳崩壊[Na84]はバッファが満杯である状態として定義され、すべての到着するパケットは、ネットワークを介して削除する必要があります。入力インタフェースが損失することなく、すべてのパケットを受け入れても、転送輻輳がこの仮想デバイスに存在しています。
The definition presented here explicitly defines Forwarding Congestion as an event observable on egress interfaces. Regardless of internal architecture, any device exhibiting Packet Loss on one or more egress interfaces is experiencing Forwarding Congestion.
ここで紹介する定義が明示的に出力インターフェイス上で観察イベントとして転送輻輳を定義します。かかわらず、内部アーキテクチャの1つまたは複数の出力インターフェイスにパケット損失を示す任意のデバイスは、転送輻輳が発生しています。
Measurement units: None
測定単位：なし
See Also: Gateway Congestion Control Survey [Ma91]
参照：ゲートウェイ輻輳制御調査[Ma91]
Definition: An implementation of one or more per-hop behaviors to avoid or minimize the condition of congestion.
定義：輻輳状態を回避または最小化するための1つ以上のホップごとの挙動の実装。
Discussion: Congestion management may seek either to control congestion or avoid it altogether through Classification.
ディスカッション：輻輳管理は、輻輳を制御したり、分類を通じて完全にそれを避けるために、どちらか求めることができます。
Congestion avoidance mechanisms seek to prevent congestion before it actually occurs.
輻輳回避メカニズムは、それが実際に発生する前に輻輳を防ぐために努めています。
Congestion control mechanisms give one or more flows (with a discrete IP Precedence or DSCP value) preferential treatment over other classes during periods of congestion.
輻輳制御メカニズムは、輻輳の期間中に、他のクラスの上に優先的に処理（離散IP PrecedenceまたはDSCP値を有する）1つ以上のフローを与えます。
Measurement units: n/a
測定単位：N / A
See Also: Classification
関連項目：分類
Definition: A flow is one or more packets sharing a common intended pair of ingress and egress interfaces.
定義：フローは入力および出力インターフェイスの共通の意図対を共有する1つ以上のパケットです。
Discussion: Packets are grouped by the ingress and egress interfaces they use on a given DUT/SUT.
議論：パケットは、所与のDUT / SUTに使用する入力および出力インターフェースによってグループ化されます。
A flow can contain multiple source IP addresses and/or destination IP addresses. All packets in a flow MUST enter on the same ingress interface and exit on the same egress interface and have some common network layer content.
フローは、複数のソースIPアドレスおよび/または宛先IPアドレスを含めることができます。フローのすべてのパケットは同じ出力インターフェイス上で同じ入力インターフェイスおよび終了時に入力して、いくつかの一般的なネットワーク層のコンテンツを持たなければなりません。
Microflows [Ni98] are a subset of flows. As defined in [Ni98], microflows require application-to-application measurement. In contrast, flows use lower-layer classification criteria. Since this document focuses on network-layer classification criteria, it concentrates here on the use of network-layer identifiers in describing a flow. Flow identifiers also may reside at the data-link, transport, or application layers of the OSI model. However, identifiers other than those at the network layer are out of scope for this document.
マイクロフロー【Ni98]はフローのサブセットです。 【Ni98]で定義されるように、マイクロフローは、アプリケーションからアプリケーションへの測定を必要とします。対照的に、下位層の分類基準を使用して流れます。このドキュメントは、ネットワーク層の分類基準に焦点を当てているので、それが流れを説明する際にネットワーク層識別子の使用にここに集中します。フロー識別子はまた、OSIモデルのデータリンク、トランスポート、またはアプリケーション層に常駐してもよいです。しかし、ネットワーク層での以外の識別子は、この文書の範囲外です。
A flow may contain a single code point/IP precedence value or may contain multiple values destined for a single egress interface. This is determined by the test methodology.
フローは、単一のコードポイント/ IP優先順位値を含んでも、単一の出力インターフェイス宛ての複数の値を含んでいてもよいです。これは、試験方法によって決定されます。
Measurement units: n/a
測定単位：N / A
See Also: Microflow [Ni98] Streams
参照：マイクロフロー[Ni98]ストリーム
Definition: The number of packets per second that a device can be observed to transmit successfully to the correct egress interface in response to a specified offered load while the device drops none of the offered packets.
定義：デバイスは、デバイスが提供されるパケットのどれを廃棄しないときに指定提供された負荷に応じて正しいイグレスインタフェースに正常に送信するように観察することができることを1秒あたりのパケット数。
Discussion: Forwarding Capacity measures the packet rate at the egress interface(s) of the DUT/SUT. In contrast, throughput (as defined in RFC 1242) measures the packet rate at the ingress interface(s) of the DUT/SUT.
ディスカッション：転送容量測定DUT / SUTの出力インターフェイス（複数可）でのパケットレート。対照的に、スループットは、（RFC 1242で定義されるように）DUT / SUTの入力インターフェイス（複数可）におけるパケットレートを測定します。
Ingress-based measurements do not account for queuing of the DUT/SUT. Throughput rates can be higher than the Forwarding Capacity because of queueing. The difference is dependent upon test duration, packet rate, and queue size. Forwarding Capacity, as an egress measurement, does take queuing into account.
イングレスベースの測定は、DUT / SUTのキューイングを考慮していません。スループット・レートがあるため、キューイングの転送容量よりも高くすることができます。違いは、テスト期間、パケットレート、およびキューのサイズに依存しています。容量の転送、出力測定として、考慮にキューイングを取るん。
Understanding Forwarding Capacity is a necessary precursor to any measurement involving Traffic Control Mechanisms. The accompanying methodology document MUST take into consideration Forwarding Capacity when determining the expected forwarding vectors. When the sum of the expected forwarding vectors on an interface exceeds the Forwarding Capacity, the Forwarding Capacity will govern the forwarding rate.
転送容量を理解することは、トラフィック制御メカニズムを含む任意の測定に必要な前駆体です。添付の方法論の文書が予想されるフォワーディングベクトルを決定する際に容量を転送考慮に入れなければなりません。インターフェイス上の予想転送ベクトルの和が転送容量を超えた場合に、転送容量は、転送速度を支配します。
This measurement differs from forwarding rate at maximum offered load (FRMOL) [Ma98] in that the Forwarding Capacity requires zero loss.
この測定は、転送容量がゼロ損失を必要とする負荷（FRMOL）[MA98]を提供する最大速度を転送は異なります。
Measurement units: N-octet packets per second
測定単位：秒当たりNオクテットのパケット
See Also: Throughput [Br91] Forwarding Rate at Maximum Offered Load [Ma98]
参照：スループット[Br91]転送レート最大与えられた負荷で[MA98]
Definition: Packets that lie within specific rate, delay, or jitter bounds.
定義：特定のレート、遅延、またはジッタ範囲内にあるパケット。
Discussion: A DUT/SUT may be configured to allow a given traffic class to consume a given amount of bandwidth, or to fall within predefined delay or jitter boundaries. All packets that lie within specified bounds are then said to be conforming, whereas those outside the bounds are nonconforming.
議論：DUT / SUTが所与のトラフィッククラスが帯域幅の所定量を消費し、または事前定義された遅延やジッタの境界内に入ることができるように構成されてもよいです。指定された範囲内にあるすべてのパケットは、その後、範囲外のものは不適合されているのに対し、適合されると言われます。
Measurement units: n/a
測定単位：N / A
See Also: Expected Vector Forwarding Vector Offered Vector Nonconforming
関連項目：期待のベクトル転送ベクターは、ベクター不適合を提供しました
Definition: Packets that do not lie within specific rate, delay, or jitter bounds.
定義：特定のレート、遅延、またはジッタの境界内に存在しないパケット。
Discussion: A DUT/SUT may be configured to allow a given traffic class to consume a given amount of bandwidth, or to fall within predefined delay or jitter boundaries. All packets that do not lie within these bounds are then said to be nonconforming.
議論：DUT / SUTが所与のトラフィッククラスが帯域幅の所定量を消費し、または事前定義された遅延やジッタの境界内に入ることができるように構成されてもよいです。これらの境界内に位置していないすべてのパケットが不適合すると言われています。
Measurement units: n/a
測定単位：N / A
See Also: Expected Vector Forwarding Vector Offered Vector Conforming
関連項目：期待のベクトル転送ベクターは、ベクター準拠を提供しました
Definition: The time interval starting when the last bit of the input IP packet is offered to the input port of the DUT/SUT and ending when the last bit of the output IP packet is received from the output port of the DUT/SUT.
定義：入力IPパケットの最後のビットがDUT / SUTの入力ポートに提供し、出力IPパケットの最後のビットがDUT / SUTの出力ポートから受信したときに終了するときに起動時間間隔。
Discussion: The delay time interval MUST be externally observed. The delay measurement MUST NOT include delays added by test bed components other than the DUT/SUT, such as propagation time introduced by cabling or non-zero delay added by the test instrument. Forwarding Delay differs from latency [Br91] and one-way delay [Al99] in several key regards:
ディスカッション：遅延時間間隔を外部から観察しなければなりません。遅延測定は、ケーブル又は試験機器によって追加非ゼロ遅延によって導入される伝播時間などのDUT / SUT以外のテストベッド構成要素によって追加された遅延を含めることはできません。転送遅延は、待ち時間[Br91]とは異なり、いくつかの重要な点で一方向遅延[Al99]：
1. Latency [Br91] assumes knowledge of whether the DUT/SUT uses "store and forward" or "bit forwarding" technology. Forwarding Delay is the same metric, measured the same way, regardless of the architecture of the DUT/SUT.
1.レイテンシ[Br91]は、DUT / SUTが「ストアアンドフォワード」または「ビット転送」技術を使用するかどうかについての知識を前提としています。遅延が同じメトリックである転送に関係なく、DUT / SUTのアーキテクチャの、同じように測定しました。
2. Forwarding Delay is a last-in, last-out (LILO) measurement, unlike the last-in, first-out method [Br91] or the first-in, last-out method [Al99].
2.転送遅延後入れ先出し法[Br91]または最初に、最後のアウト法[Al99]とは異なり、最後に、最後のアウト（LILO）測定です。
The LILO method most closely simulates the way a network-layer device actually processes an IP datagram. IP datagrams are not passed up and down the stack unless they are complete, and processing begins only once the last bit of the IP datagram has been received.
LILO法が最も密接ネットワークレイヤデバイスが実際にIPデータグラムを処理する方法をシミュレートします。 IPデータグラムが渡され、スタックダウン彼らが完了しない限り、及びIPデータグラムの最後のビットが受信された後の処理が開始されますのみされていません。
Further, the LILO method has an additive property, where the sum of the parts MUST equal the whole. This is a key difference from [Br91] and [Al99]. For example, the delay added by two DUTs MUST equal the sum of the delay of the DUTs. This may or may not be the case with [Br91] and [Al99].
さらに、LILOの方法は、部品の合計が全体に等しくなければならない添加剤性を有しています。これは、[Br91]と[Al99]から重要な違いです。例えば、二つのDUTによって追加遅延は、DUTの遅延の和に等しくなければなりません。これは、または[Br91]及び[Al99]の場合であってもなくてもよいです。
3. Forwarding Delay measures the IP datagram only, unlike [Br91], which also includes link-layer overhead.
3.転送遅延もリンク層オーバーヘッドを含む、[Br91]とは異なり、唯一のIPデータグラムを測定します。
A metric focused exclusively on the Internet protocol relieves the tester from specifying the start/end for every link-layer protocol that IP runs on. This avoids the need to determine whether the start/stop delimiters are included. It also allows the use of heterogeneous link-layer protocols in a test.
インターネットプロトコルに特化したメトリックは、IP上で実行するすべてのリンク層プロトコルの開始/終了を指定してからテスターを軽減します。これは、スタート/ストップ区切り文字が含まれているかどうかを判断する必要がありません。また、テスト中に異種リンク層プロトコルを使用することができます。
4. Forwarding Delay can be measured at any offered load, whereas the latency methodology [Br99] recommends measurement at, and only at, the throughput level. Comparing the Forwarding Delay below the throughput to Forwarding Delay above the Forwarding Capacity will give insight to the traffic control mechanisms.
4.レイテンシ方法[Br99]がで、そしてのみスループットレベルでの測定を推奨し、一方。転送遅延は、任意の提供された負荷で測定することができます転送容量上記転送遅延のスループットを下回る転送遅延を比較すると、トラフィック制御メカニズムへの洞察を与えます。
For example, non-congested delay may be measured with an offered load that does not exceed the Forwarding Capacity, while congested delay may involve an offered load that exceeds the Forwarding Capacity.
輻輳遅延は転送容量を超過する提供された負荷を含み得るが、例えば、非輻輳遅延は、転送容量を超えていない提供された負荷を用いて測定することができます。
Note: Forwarding Delay SHOULD NOT be used as an absolute indicator of DUT/SUT Forwarding Congestion. While Forwarding Delay may rise when offered load nears or exceeds the Forwarding Capacity, there is no universal point at which Forwarding Delay can be said to indicate the presence or absence of Forwarding Congestion.
注意：転送遅延は、DUT / SUT転送混雑の絶対的な指標として使用しないでください。提供された負荷が近づく又は転送容量を超えたときに転送遅延が上昇することができるが、転送遅延、転送輻輳の有無を示すために、前記可能な普遍的な点は存在しません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Latency [Br91] Latency [Al99] One-way Delay [Br99]
参照：レイテンシー[Br91]レイテンシ[Al99]片道遅延[Br99]
Definition: The absolute value of the difference between the Forwarding Delay of two consecutive received packets belonging to the same stream.
定義：同じストリームに属する2つの連続する受信パケットの転送遅延との差の絶対値。
Discussion: The Forwarding Delay fluctuation between two consecutive received packets in a stream is reported as the jitter. Jitter can be expressed as |D(i) - D(i-1)|, where D equals the Forwarding Delay and i is the order the packets were received.
議論：ストリーム内の2つの連続する受信パケット間の転送遅延変動をジッタとして報告されます。ジッタは、のように表すことができる| D（I） - D（I-1）|、Dは、転送遅延に等しく、iは、パケットが受信された順序です。
Under loss, jitter can be measured between non-consecutive test sequence numbers. When IP Traffic Control Mechanisms are dropping packets, fluctuating Forwarding Delay may be observed. Jitter MUST be able to benchmark the delay variation independently of packet loss.
損失の下では、ジッタは非連続的なテスト・シーケンス番号の間で測定することができます。 IPトラフィック制御メカニズムは、転送遅延の変動、パケットを廃棄しているときに観察することができます。ジッタは、独立して、パケットロスのベンチマーク遅延変動することができなければなりません。
Jitter is related to the IPDV [De02] (IP Delay Variation) by taking the absolute value of the ipdv. The two metrics will produce different mean values. Mean Jitter will produce a positive value, where the mean ipdv is typically zero. Also, IPDV is undefined when one packet from a pair is lost.
ジッタはIPDVの絶対値をとることによりIPDV [De02（IP遅延変動）に関連しています。 2つのメトリックは、異なる平均値を生成します。ジッタが平均IPDVは、典型的にはゼロであり、正の値を生成する平均。ペアから一つのパケットが失われた場合にも、IPDVは未定義です。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Forwarding Delay Jitter variation [Ja99] ipdv [De02] interarrival jitter [Sc96]
参照：転送遅延ジッタ変動[Ja99] IPDV [De02]のinterarrivalジッタ[SC96]
Definition: The vector(s) obtained when mechanisms used to support diff-serv or IP precedence are disabled.
定義：ベクター（単数または複数）のdiff-SERVまたはIP優先順位をサポートするために使用されるメカニズムが無効になっているときに得られます。
Discussion: Enabling diff-serv or IP precedence mechanisms may impose additional processing overhead for packets. This overhead may degrade performance even when traffic belonging to only one class, the best-effort class, is offered to the device. Measurements with "undifferentiated response" SHOULD be made to establish a baseline.
議論：有効差分-SERVまたはIP優先順位メカニズムは、パケットのための追加の処理オーバーヘッドを課すことができます。このオーバーヘッドは、トラフィックに属している唯一のクラス、ベストエフォートクラスは、デバイスに提供されていても、パフォーマンスが低下することがあります。 「未分化応答」との測定は、ベースラインを確立するためになされるべきです。
The vector(s) obtained with DSCP or IP precedence enabled can be compared to the undifferentiated response to determine the effect of differentiating traffic.
DSCPまたはIP優先順位有効で得られたベクター（単数または複数）のトラフィックを差別の効果を決定するために、未分化応答と比較することができます。
Measurement units: n/a
測定単位：N / A
Definition: A field in the IP payload portion of the packet that is used to verify the order of the packets on the egress of the DUT/SUT.
定義：DUT / SUTの出力にパケットの順序を確認するために使用されるパケットのIPペイロード部分内のフィールド。
Discussion: The traffic generator sets the test sequence number value. Upon receipt of the packet, the traffic receiver checks the value. The traffic generator changes the value on each packet transmitted based on an algorithm agreed to by the traffic receiver.
ディスカッション：トラフィックジェネレータは、テスト・シーケンス番号の値を設定します。パケットを受信すると、トラフィックレシーバーは、値をチェックします。トラフィックジェネレータは、トラフィック受信機によって合意されたアルゴリズムに基づいて送信される各パケットに値を変更します。
The traffic receiver keeps track of the sequence numbers on a per-stream basis. In addition to the number of received packets, the traffic receiver may also report the number of in-sequence packets, the number of out-of-sequence packets, the number of duplicate packets, and the number of reordered packets. The RECOMMENDED algorithm to change the sequence number on sequential packets is an incrementing value.
トラフィックの受信機は、ストリームごとにシーケンス番号を追跡します。受信されたパケットの数に加えて、トラフィックレシーバーはまた、シーケンスパケットの数、シーケンス外のパケット数、重複パケットの数、および並べ替えのパケットの数を報告することができます。シーケンシャルパケットにシーケンス番号を変更することを推奨アルゴリズムは、インクリメント値です。
Measurement units: n/a
測定単位：N / A
See Also: Stream
参照：ストリームを
Definition: A group of packets tracked as a single entity by the traffic receiver. A stream MUST share common content, such as type (IP, UDP), IP SA/DA, packet size, or payload.
定義：トラフィックの受信機によって単一のエンティティとして追跡パケットのグループ。ストリームは、タイプ（IP、UDP）、IP SA / DA、パケットサイズ、またはペイロードとして、共通のコンテンツを共有しなければなりません。
Discussion: Streams are tracked by test sequence number or "unique signature field" [Ma00]. Streams define how individual packet statistics are grouped together to form an intelligible summary.
議論：ストリームは、試験シーケンス番号または「一意の署名フィールド」[MA00]によって追跡されます。ストリームは、パケットの統計が分かりやすい要約を形成するために一緒にグループ化する方法を個別に定義します。
Common stream groupings would be by egress interface, destination address, source address, DSCP, or IP precedence. A stream using test sequence numbers can track the ordering of packets as they traverse the DUT/SUT.
一般的な流れのグループは、出力インターフェイス、宛先アドレス、送信元アドレス、DSCP、またはIP precedenceすることによります。彼らはDUT / SUTを横断するテスト・シーケンス番号を使用したストリームは、パケットの順序を追跡することができます。
Streams are not restricted to a pair of source and destination interfaces as long as all packets are tracked as a single entity. A multicast stream can be forwarded to multiple destination interfaces.
ストリームがあれば、すべてのパケットを単一のエンティティとして追跡される送信元および宛先インターフェイスのペアに限定されるものではありません。マルチキャストストリームは、複数の宛先インターフェイスに転送することができます。
Measurement units: n/a
測定単位：N / A
See Also: Flow Microflow [Ni98] Test sequence number
参照：フローマイクロフロー[Ni98]試験シーケンス番号
Definition: A received packet with the expected Test Sequence number.
定義：期待されるテストシーケンス番号と、受信したパケット。
Discussion: In-sequence is done on a stream level. As packets are received on a stream, each packet's Test Sequence number is compared with the previous packet. Only packets that match the expected Test Sequence number are considered in-sequence.
ディスカッション：インシーケンスは、ストリームレベルで行われます。パケットがストリーム上で受信されると、各パケットの試験シーケンス番号が前のパケットと比較されます。期待されるテストシーケンス番号と一致するパケットだけをして、シーケンスと考えられています。
Packets that do not match the expected Test Sequence number are counted as "not in-sequence" or out-of-sequence. Every packet that is received is either in-sequence or out-of-sequence. Subtracting the in-sequence from the received packets (for that stream), the tester can derive the out-of-sequence count.
期待されるテストシーケンス番号と一致しないパケットは、「いない配列で」またはアウトオブシーケンスとしてカウントされます。受信されたすべてのパケットは、配列内または外の配列のいずれかです。 （そのストリームのために）受信したパケットからシーケンス減算、テスタは、アウトオブシーケンス数を導出することができます。
Two types of events will prevent the in-sequence from incrementing: packet loss and reordered packets.
パケット損失や並べ替えのパケット：2つのタイプのイベントは、インクリメントからでシーケンスを防ぐことができます。
Measurement units: Packet count
測定単位：パケット数
See Also: Stream Test Sequence number
参照：ストリームテストシーケンス番号
Definition: A received packet with a sequence number less than the sequence number of any previously arriving packet.
定義：以前に到着したパケットのシーケンス番号よりも小さいシーケンス番号を持つ受信したパケット。
Discussion: As a stream of packets enters a DUT/SUT, they include a Stream Test Sequence number indicating the order the packets were sent to the DUT/SUT. On exiting the DUT/SUT, these packets may arrive in a different order. Each packet that was reordered is counted as an Out-of-Order Packet.
議論：パケットのストリームは、DUT / SUTに入ると、それらはパケットがDUT / SUTに送信された順序を示すストリームテストシーケンス番号を含みます。 DUT / SUTを出るには、これらのパケットは異なる順序で到着することができます。並び替えられた各パケットは、アウトオブオーダーパケットとしてカウントされます。
Certain streaming protocols (such as TCP) require the packets to be in a certain order. Packets outside this are dropped by the streaming protocols even though they were properly received by the IP layer. The type of reordering tolerated by a streaming protocol varies from protocol to protocol, and also by implementation.
（TCPなど）、特定のストリーミング・プロトコルは、特定の順序になるようにパケットを必要とします。この外のパケットは、彼らが適切にIP層で受信したにもかかわらず、ストリーミングプロトコルによって廃棄されます。ストリーミングプロトコルによって許容並べ替えのタイプがプロトコルのプロトコルに、また、実装によって変化します。
Packet loss does not affect the Out-of-Order Packet count. The Out-of-Order Packet count is impacted only by packets that were not received in the order that they were transmitted.
パケット損失はアウトオブオーダーパケット数には影響を与えません。アウトオブオーダーパケットカウントは、彼らだけが送信された順に受信されなかったパケットの影響を受けています。
Measurement units: packets
測定単位：パケット
See Also: Stream Test Sequence number Packet Reordering Metric for IPPM [Mo03]
参照：IPPM用ストリーム試験シーケンス番号パケット並べ替えメトリック[Mo03]
Definition: A received packet with a Test Sequence number matching a previously received packet.
定義：試験シーケンス番号が、以前に受信したパケットに一致すると、受信したパケット。
Discussion: A Duplicate Packet is a packet that the DUT/SUT has successfully transmitted out an egress interface more than once. The egress interface has previously forwarded this packet.
議論：重複パケットはDUT / SUTが正常に複数回出力インターフェイスを送信したパケットです。出力インターフェイスは、以前にこのパケットを転送しています。
A Duplicate Packet SHOULD be a bit-for-bit copy of an already transmitted packet (including Test Sequence number). If the Duplicate Packet traversed different paths through the DUT/SUT, some fields (such as TTL or checksum) may have changed.
重複パケットは、（試験シーケンス番号を含む）が既に送信されたパケットのビットごとのコピーであるべきです。重複パケットは、DUT / SUTを介して異なるパスを横断した場合、（例えば、TTLまたはチェックサムのような）いくつかのフィールドが変更されていてもよいです。
A multicast packet is not a Duplicate Packet by definition. For a given IP multicast group, a DUT/SUT SHOULD forward a packet once on a given egress interface provided the path to one or more multicast receivers is through that interface. Several egress interfaces will transmit the same packet, but only once per interface.
マルチキャストパケットは、定義により、重複パケットではありません。与えられたIPマルチキャストグループに対して、DUT / SUTは、1つまたは複数のマルチキャスト受信機への経路を提供し、所与の出力インターフェイスに一度パケットを転送する必要があることインターフェイスを介してです。いくつかの出力インターフェイスは、だけインターフェイスごとに一度、同じパケットを送信します。
To detect a Duplicate Packet, each packet offered to the DUT/SUT MUST contain a unique packet-by-packet identifier.
重複パケットを検出するために、DUT / SUTに提供される各パケットは、一意のパケット・バイ・パケット識別子を含まなければなりません。
Measurement units: Packet count
測定単位：パケット数
See Also: Stream Test Sequence number
参照：ストリームテストシーケンス番号
A vector is a group of packets all matching a specific classification criteria, such as DSCP. Vectors are identified by the classification criteria and benchmarking metrics, such as a Forwarding Capacity, Forwarding Delay, or Jitter.
ベクターは、DSCPなどの特定の分類基準を、一致するパケットのすべてのグループです。ベクターは、分類基準と、このような転送容量、転送遅延、またはジッタなどのベンチマーク測定基準によって識別されます。
Definition: A description of the configuration on an external source for the attempted rate of a stream transmitted to a DUT/SUT matching specific classification rules.
定義：特定の分類ルールに一致DUT / SUTに送信されるストリームの試み速度のための外部ソース上の構成の説明。
Discussion: The Intended Vector of a stream influences the benchmark measurements. The Intended Vector is described by the classification criteria and attempted rate.
ディスカッション：ストリームの意図ベクトルは、ベンチマーク測定結果に影響を与えます。対象ベクターは、分類基準と未遂率によって説明されます。
Measurement Units: N-bytes packets per second
測定単位：秒当たりNバイトのパケット
See Also: Stream Offered Vector Forwarding Vector
参照：ストリームは、Vector転送ベクトルを提供しました
Definition: A description for the attempted rate of a stream offered to a DUT/SUT matching specific classification rules.
定義：特定の分類規則に合致するDUT / SUTに提供ストリームの未遂率の説明。
Discussion: The Offered Vector of a stream influences the benchmark measurements. The Offered Vector is described by the classification criteria and offered rate.
ディスカッション：提供ベクターストリームのベンチマーク測定結果に影響を与えます。提供されるベクターは、分類基準および提供率によって説明されます。
Measurement Units: N-bytes packets per second
測定単位：秒当たりNバイトのパケット
See Also: Stream Intended Vector Forwarding Vector
参照：ストリームは、Vector転送ベクトルを対象
Definition: A description of the expected output rate of packets matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、一致するパケットの予想される出力レートの記述。
Discussion: The value of the Expected Forwarding Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：予想転送ベクトルの値がDUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Forwarding Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、期待転送ベクトルを記述する際に重要ではありません。
Measurement units: N-octet packets per second
測定単位：秒当たりNオクテットのパケット
See Also: Classification Stream Intended Vector Offered Vector
関連項目：分類ストリーム意図ベクトル提供されるベクトル
Definition: A description of the percentage of packets having a specific classification that should not be forwarded.
定義：転送されるべきではない特定の分類を持つパケットの割合についての説明。
Discussion: The value of the Expected Loss Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：予想損失のベクトルの値がDUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Loss Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想損失のベクトルを記述する際に重要ではありません。
Measurement Units: Percentage of intended packets expected to be dropped.
測定単位：ドロップされることが予想意図したパケットの割合。
See Also: Classification Stream Intended Vector Offered Vector One-way Packet Loss Metric [Ka99]
関連項目：分類ストリーム意図ベクトル提供されるベクトル一方向パケット損失メトリック[Ka99]
Definition: A description of the expected in-sequence packets matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、マッチング期待インシーケンスパケットの説明。
Discussion: The value of the Expected Sequence Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：期待されるシーケンスのベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Sequence Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想されるシーケンスのベクトルを記述する際に重要ではありません。
Measurement Units: N-octet packets per second
測定単位：秒あたりのNオクテットのパケット
See Also: Classification Stream In-Sequence Packet Intended Vector Offered Vector
関連項目：パケット意図ベクトルは、ベクトルのご提供では、シーケンスの分類ストリーム
Definition: A description of the expected instantaneous Forwarding Delay for packets matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、一致するパケットの予想される瞬間的な転送遅延の説明。
Discussion: The value of the Expected Delay Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：予想遅延ベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Delay Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想遅延ベクトルを記述する際に重要ではありません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Delay Intended Vector Offered Vector
関連項目：分類ストリーム転送遅延対象ベクトル提供されるベクトル
Definition: A description of the expected average Forwarding Delay for packets matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、一致するパケットの予想される平均転送遅延の説明。
Discussion: The value of the Expected Average Delay Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：予想平均遅延ベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Average Delay Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想される平均遅延ベクトルを記述する際に重要ではありません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Delay Intended Vector Offered Vector Expected Delay Vector
関連項目：分類ストリーム転送遅延は、ベクターが遅延ベクトルを期待ベクタ提供される対象
Definition: A description of the expected maximum Forwarding Delay for packets matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、一致するパケットのための予想される最大転送遅延の説明。
Discussion: The value of the Expected Maximum Delay Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：予想される最大遅延ベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Maximum Delay Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想される最大遅延ベクトルを記述する際に重要ではありません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Delay Intended Vector Offered Vector Expected Delay Vector
関連項目：分類ストリーム転送遅延は、ベクターが遅延ベクトルを期待ベクタ提供される対象
Definition: A description of the expected minimum Forwarding Delay for packets matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、一致するパケットの予想される最小転送遅延の説明。
Discussion: The value of the Expected Minimum Delay Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
ディスカッション：最小予想遅延ベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Minimum Delay Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想される最小遅延ベクトルを記述する際に重要ではありません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Delay Intended Vector Offered Vector Expected Delay Vector
関連項目：分類ストリーム転送遅延は、ベクターが遅延ベクトルを期待ベクタ提供される対象
Definition: A description of the expected Instantaneous Jitter between two consecutive packets arrival times matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、一致する二つの連続するパケットの到着時間との間の予想される瞬間ジッタの説明。
Discussion: Instantaneous Jitter is the absolute value of the difference between the Forwarding Delay measurement of two packets belonging to the same stream.
議論：瞬時ジッタは、同じストリームに属する2つのパケットの転送遅延測定の差の絶対値です。
The Forwarding Delay fluctuation between two consecutive packets in a stream is reported as the "Instantaneous Jitter". Instantaneous Jitter can be expressed as |D(i) - D(i-1)|, where D equals the Forwarding Delay and i is the test sequence number. Packets lost are not counted in the measurement.
ストリーム内の2つの連続したパケット間の転送遅延揺らぎは「瞬時ジッタ」として報告されます。瞬時ジッタは次のように表すことができる| D（I） - D（I-1）|、Dは、転送遅延に等しく、iは、試験シーケンス番号です。失われたパケットは、測定にはカウントされません。
The Forwarding Vector may contain several Jitter Vectors. For n packets received in a Forwarding Vector, there is a total of (n-1) Instantaneous Jitter Vectors.
転送ベクターは、いくつかのジッタベクターを含有していてもよいです。転送ベクトルで受信されたN個のパケットのために、（N-1）の合計瞬時ジッタベクターがあります。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Jitter Intended Vector Offered Vector
参照：分類ストリームジッタは、Vectorはベクトルを提供した意図
Definition: A description of the expected average jitter for packets arriving in a stream matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、マッチングストリームに到着するパケットに対する予想平均ジッタの説明。
Discussion: Average Jitter Vector is the average of all the Instantaneous Jitter Vectors measured during the test duration for the same stream.
議論：平均ジッタベクトルが同じストリームに対する試験時間の間測定された全ての瞬時ジッタベクトルの平均です。
The value of the Expected Average Jitter Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
予想平均ジッタのベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Average Jitter Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予想平均ジッタのベクトルを記述する際に重要ではありません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Jitter Intended Vector Offered Vector Expected Instantaneous Jitter Vector
参照：分類ストリームジッタは、ベクトルがベクトルの瞬時ジッタのベクトルを期待提供される対象
Definition: A description of the expected maximum variation in the Forwarding Delay of packet arrival times for packets arriving in a stream matching a specific classification, such as DSCP.
定義：例えばDSCPなどの特定の分類、マッチングストリームに到着するパケットのパケット到着時間の転送遅延の予想される最大変化の説明。
Discussion: Peak-to-peak Jitter Vector is the maximum Forwarding Delay minus the minimum Forwarding Delay of the packets (in a vector) forwarded by the DUT/SUT.
議論：ピーク・ツー・ピークジッタベクターは、DUT / SUTによって転送最大転送遅延マイナス（ベクターにおける）パケットの最小転送遅延です。
Peak-to-peak Jitter is not derived from the Instantaneous Jitter Vector. Peak-to-peak Jitter is based upon all the packets during the test duration, not just two consecutive packets.
ピーク・ツー・ピーク・ジッタは、瞬時ジッタベクターに由来するものではありません。ピーク・ツー・ピーク・ジッタは、試験期間中にすべてのパケットだけではなく、二つの連続したパケットに基づいています。
The value of the Expected Peak-to-peak Jitter Vector is dependent on the set of offered vectors and Classification configuration on the DUT/SUT. The DUT is configured in a certain way so that classification occurs when a traffic mix consisting of multiple streams is applied.
予測されるピーク・ツー・ピーク・ジッタのベクトルの値は、DUT / SUTに提供ベクトルの集合と分類の設定に依存しています。複数のストリームからなるトラフィックミックスを適用した場合の分類が発生するようにDUTが特定の方法で構成されています。
This term captures the expected forwarding behavior from the DUT receiving multiple Offered Vectors. The actual algorithm or mechanism the DUT uses to achieve service differentiation is implementation specific and is not important when describing the Expected Peak-to-peak Jitter Vector.
この用語は、複数提供されるベクトルを受けるDUTから期待される転送動作をキャプチャします。 DUTは、サービスの差別化を達成するために使用する実際のアルゴリズムまたはメカニズムは、実装固有のものであり、予測されるピーク・ツー・ピーク・ジッタのベクトルを記述する際に重要ではありません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Jitter Intended Vector Offered Vector Expected Instantaneous Jitter Vector Expected Average Jitter Vector
参照：ベクトル提供される分類ストリームジッタ対象ベクトルは瞬時ジッタのベクトルは、平均ジッタのベクトルを予想予想しました
Definition: The number of packets per second for a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to forward to the correct destination interface successfully in response to an offered vector.
定義：例えばDSCPなどの特定の分類、一致ストリームに対する1秒あたりのパケット数、DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに転送するように測定されること。
Discussion: Forwarding Vector is expressed as a combination of values: the classification rules AND the measured packets per second for the stream matching the classification rules. Forwarding Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP (or IP precedence) value for a multi-hop measurement. The stream remains the same.
ディスカッション：分類ルールおよび分類ルールに一致ストリーム毎秒測定パケット：転送ベクタ値の組み合わせとして表現されます。転送ベクターは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のために、特定のDSCP（またはIP優先順位）値を発言するかもしれません。ストリームは同じまま。
Measurement units: N-octet packets per second
測定単位：秒当たりNオクテットのパケット
See Also: Classification Stream Forwarding Capacity Intended Vector Offered Vector Expected Vector
参照：分類ストリーム転送容量意図ベクトル提供されるベクトル予想ベクトル
Definition: The percentage of packets per second for a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured not to transmit to the correct destination interface in response to an offered vector.
定義：DUT / SUTを提供するベクターに応じて、正しい宛先インターフェイスに送信しないように測定されるようにDSCPなどの特定の分類、マッチングストリームに対する秒あたりのパケットのパーセンテージ。
Discussion: Loss Vector is expressed as a combination of values: the classification rules AND the measured percentage value of packet loss. Loss Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
ディスカッション：分類ルールおよびパケット損失の測定パーセント値：損失ベクトルが値の組み合わせとして表現されます。損失ベクターは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Measurement Units: Percentage of packets
測定単位：パケットの割合
See Also: Classification Stream Intended Vector Offered Vector Expected Vector One-way Packet Loss Metric [Ka99]
参照：ベクトル予想ベクトル一方向パケット損失メトリック[Ka99]提供される分類ストリーム対象のベクトル
Definition: The number of packets per second for all packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit in sequence to the correct destination interface in response to an offered vector.
定義：例えばDSCPなどの特定の分類、一致ストリーム内のすべてのパケットの1秒あたりのパケット数、DUT / SUTを提供するベクターに応じて、正しい宛先インターフェイスに順次送信するように測定されます。
Discussion: Sequence Vector is expressed as a combination of values: the classification rules AND the number of packets per second that are in-sequence.
ディスカッション：分類ルールとに配列されている1秒あたりのパケット数：配列ベクトルが値の組み合わせとして表現されます。
Sequence Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
シーケンスベクトルはホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Measurement Units: N-octet packets per second
測定単位：秒あたりのNオクテットのパケット
See Also: Classification Stream In-sequence Packet Intended Vector Offered Vector Expected Vector
参照：分類ストリームでは、シーケンスパケット対象ベクトル提供されるベクトル予想ベクトル
Definition: The instantaneous Forwarding Delay for a packet in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されるようにDSCPなどの特定の分類、マッチングストリーム内のパケットの瞬時転送遅延。
Discussion: Instantaneous Delay Vector is expressed as a combination of values: the classification rules AND Forwarding Delay. For every packet received in a Forwarding Vector, there is a corresponding Instantaneous Delay Vector.
ディスカッション：分類ルールおよび転送遅延：瞬時遅延ベクトルは、値の組み合わせとして表現されます。転送ベクトルで受信されたすべてのパケットについて、対応する瞬時遅延ベクトルがあります。
Instantaneous Delay Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
瞬時遅延ベクトルは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Instantaneous Delay Vector can be obtained at any offered load. It is RECOMMENDED that this vector be obtained at or below the Forwarding Capacity in the absence of Forwarding Congestion. For congested Forwarding Delay, run the offered load above the Forwarding Capacity.
瞬時遅延ベクトルは、任意の与えられた負荷で得ることができます。なお、このベクターを転送輻輳の不在下で転送容量に又は下に得られることが推奨されます。混雑して転送遅延を、転送容量の上に提供され、ロードを実行します。
Measurement Units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Capacity Forwarding Delay Intended Vector Offered Vector Expected Delay Vector
参照：分類ストリーム転送容量転送遅延は、ベクターが遅延ベクトルを期待ベクタ提供される対象
Definition: The average Forwarding Delay for packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されるようにDSCPなどの特定の分類、マッチングストリーム内のパケットの平均転送遅延。
Discussion: Average Delay Vector is expressed as combination of values: the classification rules AND average Forwarding Delay.
ディスカッション：分類ルールと平均転送遅延：平均遅延ベクトルは、値の組み合わせとして表現されます。
The average Forwarding Delay is computed by averaging all the Instantaneous Delay Vectors for a given stream.
平均転送遅延が与えられたストリームのすべての瞬時遅延ベクトルを平均することによって計算されます。
Average Delay Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
平均遅延ベクトルは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Average Delay Vector can be obtained at any offered load. It is recommended that the offered load be at or below the Forwarding Capacity in the absence of congestion. For congested Forwarding Delay, run the offered load above the Forwarding Capacity.
平均遅延ベクトルは、任意の与えられた負荷で得ることができます。与えられた負荷が輻輳のない状態で転送容量またはそれ以下にすることをお勧めします。混雑して転送遅延を、転送容量の上に提供され、ロードを実行します。
Measurement Units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Capacity Forwarding Delay Intended Vector Offered Vector Expected Delay Vector Instantaneous Delay Vector
参照：分類ストリーム転送容量転送遅延ベクトルがベクトルの遅延ベクトル瞬時遅延ベクトルを期待提供される対象
Definition: The maximum Forwarding Delay for packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されるようにDSCPなどの特定の分類、マッチングストリーム内のパケットの最大転送遅延。
Discussion: Maximum Delay Vector is expressed as combination of values: the classification rules AND maximum Forwarding Delay.
ディスカッション：分類ルールと最大転送遅延：最大遅延ベクトルは、値の組み合わせとして表現されます。
The maximum Forwarding Delay is computed by selecting the highest value from the Instantaneous Delay Vectors for a given stream.
最大転送遅延は、指定されたストリームの瞬時遅延ベクトルから、最も高い値を選択することによって計算されます。
Maximum Delay Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
最大遅延ベクトルは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Maximum Delay Vector can be obtained at any offered load. It is recommended that the offered load be at or below the Forwarding Capacity in the absence of congestion. For congested Forwarding Delay, run the offered load above the Forwarding Capacity.
最大遅延ベクトルは、任意の与えられた負荷で得ることができます。与えられた負荷が輻輳のない状態で転送容量またはそれ以下にすることをお勧めします。混雑して転送遅延を、転送容量の上に提供され、ロードを実行します。
Measurement Units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Capacity Forwarding Delay Intended Vector Offered Vector Expected Delay Vector Instantaneous Delay Vector
参照：分類ストリーム転送容量転送遅延ベクトルがベクトルの遅延ベクトル瞬時遅延ベクトルを期待提供される対象
Definition: The minimum Forwarding Delay for packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されるようにDSCPなどの特定の分類、マッチングストリーム内のパケットの最小転送遅延。
Discussion: Minimum Delay Vector is expressed as a combination of values: the classification rules AND minimum Forwarding Delay. The minimum Forwarding Delay is computed by selecting the lowest value from the Instantaneous Delay Vectors for a given stream.
ディスカッション：分類ルールおよび最小転送遅延：最小遅延ベクトルは、値の組み合わせとして表現されます。最小転送遅延は、指定されたストリームの瞬時遅延ベクトルから最小値を選択することによって計算されます。
Minimum Delay Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
最小遅延ベクトルは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Minimum Delay Vector can be obtained at any offered load. It is recommended that the offered load be at or below the Forwarding Capacity in the absence of congestion. For congested Forwarding Delay, run the offered load above the Forwarding Capacity.
最小遅延ベクトルは、任意の与えられた負荷で得ることができます。与えられた負荷が輻輳のない状態で転送容量またはそれ以下にすることをお勧めします。混雑して転送遅延を、転送容量の上に提供され、ロードを実行します。
Measurement Units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Capacity Forwarding Delay Intended Vector Offered Vector Expected Delay Vector
参照：分類ストリーム転送容量転送遅延は、ベクターが遅延ベクトルを期待ベクタ提供される対象
Definition: The jitter for two consecutive packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：例えばDSCPなどの特定の分類、一致ストリーム内の2つの連続したパケットジッタ、DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されます。
Discussion: Instantaneous Jitter is the absolute value of the difference between the Forwarding Delay measurement of two packets belonging to the same stream.
議論：瞬時ジッタは、同じストリームに属する2つのパケットの転送遅延測定の差の絶対値です。
The Instantaneous Jitter vector is expressed as a pair of numbers. Both the specific DSCP (or IP precedence) value AND jitter value combine to make a vector.
瞬時ジッタベクトルは番号の組として表現されます。特定のDSCP（またはIP優先順位）値とジッタ値の両方がベクトルを作るために組み合わせます。
The Forwarding Delay fluctuation between two consecutive packets in a stream is reported as the "Instantaneous Jitter". Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)|, where D equals the Forwarding Delay and i is the test sequence number. Packets lost are not counted in the measurement.
ストリーム内の2つの連続したパケット間の転送遅延揺らぎは「瞬時ジッタ」として報告されます。 、Dは、転送遅延に等しく、iは、試験シーケンス番号である| - D（I-1）D（I）|瞬時ジッタベクトルはとして表すことができます。失われたパケットは、測定にはカウントされません。
The Instantaneous Jitter Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
瞬時ジッタベクターは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
There may be several Instantaneous Jitter Vectors for a single stream. For n packets measured, there may be (n-1) Instantaneous Jitter Vectors.
単一ストリームのためのいくつかの瞬時ジッタのベクトルがあるかもしれません。 n個のパケットが測定のために、（N-1）瞬時ジッタベクトルが存在し得ます。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Forwarding Delay Jitter Forwarding Vector Expected Vectors
関連項目：分類ストリーム転送遅延ジッタ転送ベクトルはベクトルを期待
Definition: The average jitter for packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されるようにDSCPなどの特定の分類、マッチングストリーム内のパケットの平均ジッタ。
Discussion: Average jitter is calculated by the average of all the Instantaneous Jitter Vectors of the same stream measured during the test duration. Average Jitter Vector is expressed as a combination of values: the classification rules AND average Jitter.
議論：平均ジッタは試験期間中に測定同じストリームのすべての瞬間ジッタベクトルの平均により算出されます。分類規則と平均ジッタ：平均ジッタベクトルは、値の組み合わせとして表現されます。
Average Jitter Vector is a per-hop measurement. The DUT/SUT MAY remark the specific DSCP or IP precedence value for a multi-hop measurement. The stream remains the same.
平均ジッタベクターは、ホップごとの測定値です。 DUT / SUTは、マルチホップ測定のための特定のDSCPまたはIP precedence値を発言するかもしれません。ストリームは同じまま。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Classification Stream Jitter Forwarding Vector Expected Vector Instantaneous Jitter Vector
関連項目：分類ストリームジッタ転送ベクターは、ベクター瞬時ジッタのベクトルを期待
Definition: The maximum possible variation in the Forwarding Delay for packets in a stream matching a specific classification, such as DSCP, that a DUT/SUT is measured to transmit to the correct destination interface successfully in response to an offered vector.
定義：例えばDSCPなどの特定の分類、一致ストリーム内のパケットの転送遅延の最大の可能な変化、DUT / SUTを提供ベクトルに応答して正常に正しい宛先インターフェイスに送信するように測定されます。
Discussion: Peak-to-peak Jitter Vector is calculated by subtracting the maximum Forwarding Delay from the minimum Forwarding Delay of the packets forwarded by the DUT/SUT. Jitter vector is expressed as a combination of values: the classification rules AND peak-to-peak Jitter.
議論：ピーク・ツー・ピークジッタベクトルがDUT / SUTによって転送されるパケットの最小転送遅延から最大転送遅延を減算することによって計算されます。分類規則およびピーク・ツー・ピークのジッタ：ジッタベクトルが値の組み合わせとして表現されます。
Peak-to-peak Jitter is not derived from the Instantaneous Jitter Vector. Peak-to-peak Jitter is based upon all the packets during the test duration, not just two consecutive packets.
ピーク・ツー・ピーク・ジッタは、瞬時ジッタベクターに由来するものではありません。ピーク・ツー・ピーク・ジッタは、試験期間中にすべてのパケットだけではなく、二つの連続したパケットに基づいています。
Measurement units: milliseconds
測定単位：ミリ秒
See Also: Jitter Forwarding Vector Stream Expected Vectors Instantaneous Jitter Vector Average Jitter Vector
参照：ジッタ転送ベクトルストリームは、ベクトル瞬時ジッタのベクトル平均ジッタのベクトルを期待
Documents of this type do not directly affect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to production networks.
このタイプのドキュメントは、直接限りベンチマークは、生産ネットワークに接続されたデバイスやシステム上で実行されていないとして、インターネットまたは企業ネットワークのセキュリティに影響を与えません。
Packets with unintended and/or unauthorized DSCP or IP precedence values may present security issues. Determining the security consequences of such packets is out of scope for this document.
意図しないおよび/または不正DSCPまたはIP precedence値を持つパケットは、セキュリティ上の問題を提示することができます。このようなパケットのセキュリティへの影響を決定することは、この文書の範囲外です。
The authors gratefully acknowledge the contributions of the IETF's Benchmarking Methodology Working Group members in reviewing this document. The authors would like to express our thanks to David Newman for his consistent and valuable assistance throughout the development of this document. The authors would also like to thank Al Morton and Kevin Dubray for their ideas and support.
作者は感謝して、この文書のレビューにIETFのベンチマーク手法ワーキンググループのメンバーの貢献を認めます。作者はこのドキュメントの開発を通して、彼の一貫性のある貴重な援助のためにデビッド・ニューマンへの感謝を表したいと思います。著者はまた、彼らのアイデアやサポートのためにアル・モートンとケビンDubrayに感謝したいと思います。
[Br91] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991.
[Br91]ブラドナーの、S.、RFC 1242、1991年7月 "ネットワーク相互接続デバイスのための用語をベンチマーキング"。
[Br97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Br97]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J., and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[Br98]ブレーデン、B.、クラーク、D.、クロウクロフト、J.、デイビー、B.、デアリング、S.、Estrin、D.、フロイド、S.、ヤコブソン、V.、Minshall、G.、ヤマウズラ、 C.、ピーターソン、L.、ラマクリシュナン、K.、Shenker、S.、Wroclawski、J.、およびL.チャン、 "インターネットの待ち行列管理と輻輳回避の推薦"、RFC 2309、1998年4月。
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[MA98]マンデビル、R.、RFC 2285、1998年2月 "LANのためのベンチマーキング用語は、デバイスの切り替え"。
[Ni98] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[Ni98]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.ブラック、RFC 2474、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、1998年12月。
[St91] Steinberg, L., "Techniques for managing asynchronously generated alerts", RFC 1224, May 1991.
[ST91]スタインバーグ、L.、RFC 1224、1991年5月 "非同期に生成されたアラートを管理するための技術"。
[Al99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[Al99] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "IPPMための一方向遅延メトリック"、RFC 2679、1999年9月。
[Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[Bl98]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[Br99]ブラドナー、S.とJ. McQuaid、RFC 2544、1999年3月 "ベンチマーキング方法論は、ネットワークの相互接続デバイスのため"。
[De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[De02]デミチェリス、C.およびP. Chimento、 "IPパフォーマンス・メトリックのためのIPパケット遅延変動メトリック（IPPM）"、RFC 3393、2002年11月。
[Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm
【Ec98] http://www3.ietf.org/proceedings/98mar/98mar-edited-135.htm
[Fl93] Floyd, S., and Jacobson, V., "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, V.1 N.4, August 1993, p. 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf".
[Fl93]フロイド、S.、およびヤコブソン、V.、 "輻輳回避のためのランダム早期検出・ゲートウェイ"、ネットワーキング、V.1のN.4、1993年8月、P上のIEEE / ACM取引。 397から413まで。 URL "ftp://ftp.ee.lbl.gov/papers/early.pdf"。
[Ja99] 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.
【Ja99】デイビー、B.、Charny、A.、ベネット、JC、ベンソン、K.、ルBoudec、J.、コートニー、W.、Davari、S.、Firoiu、V.、およびD. Stiliadis、「アン緊急転送PHB（ホップ単位動作）」、RFC 3246、2002年3月。
[Ka99] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[Ka99] Almes、G.、Kalidindi、S.、およびM. Zekauskas、 "一方向パケット損失IPPMためのメトリック"、RFC 2680、1999年9月。
[Ma91] Mankin, A. and K. Ramakrishnan, "Gateway Congestion Control Survey", RFC 1254, August 1991.
[Ma91]マンキン、A.およびK.ラマクリシュナン、 "ゲートウェイの輻輳制御調査"、RFC 1254、1991年8月。
[Ma00] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
、RFC 2889、2000年8月、 "LANスイッチングデバイスのためのベンチマーキング方法論" [MA00]マンデヴィル、R.とJ. Perser、。
[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., Perser, J., "Packet Reordering Metric for IPPM", Work in Progress.
【Mo03】モートン、A.、Ciavattone、L.、ラマチャンドラン、G.、Shalunov、S.、Perser、J.、 "IPPMのパケット並べ替えメトリック"、ProgressのWork。
[Na84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[Na84]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
[Ra99] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
【Ra99 "IPに明示的輻輳通知の添加（ECN）" ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[Sc96] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
"：リアルタイムアプリケーションのためのトランスポートプロトコルRTP"、STD 64、RFC 3550、2003年7月[SC96] Schulzrinneと、H.、Casner、S.、フレデリック、R.、およびV.ヤコブソン、。
Authors' Addresses
著者のアドレス
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton, OR 97008 USA USA
ジェリーPerser Veriwave 8770 SWニンバスアベニュー。スイートBビーバートン、OR 97008 USA USA
Phone: + 1 818 338 4112 EMail: jerry@perser.org
電話：+ 1 818 338 4112 Eメール：jerry@perser.org
Scott Poretsky Reef Point Systems 8 New England Executive Park Burlington, MA 01803 USA
スコットPoretskyリーフPoint Systems社8ニューイングランド・エグゼクティブ・パークバーリントン、MA 01803 USA
Phone: + 1 508 439 9008 EMail: sporetsky@reefpoint.com
電話：+ 1 508 439 9008 Eメール：sporetsky@reefpoint.com
Shobha Erramilli Telcordia Technologies 331 Newman Springs Road Red Bank, New Jersey 07701 USA
ショブハErramilliのTelcordia Technologies社331ニューマンスプリングスの道レッドバンク、ニュージャージー州07701米国
EMail: shobha@research.telcordia.com
メールアドレス：shobha@research.telcordia.com
Sumit Khurana Motorola 7700 West Parmer Ln. Austin, TX 78729 USA
スミットクラナモトローラ7700ウェスト・パーマーのLn。オースティン、TX 78729 USA
Phone: +1 512 996 6604 Email: skhurana@motorola.com
電話：+1 512 996 6604 Eメール：skhurana@motorola.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 except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。