[要約] RFC 4689は、ネットワーク層のトラフィック制御メカニズムのベンチマーク用語を定義しています。このRFCの目的は、ネットワーク制御メカニズムの評価と比較を容易にするための共通の用語と定義を提供することです。
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).
Copyright（c）The Internet Society（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.
既存の用語とのもう1つの重要な違いは、テスト中のデバイス/システムの出力と侵入で観察される測定の定義です。繰り返しになりますが、輻輳の存在には、出口測定値と侵入で撮影された測定値を追加する必要があります。デバイス/システムを離れるトラフィックを観察しないと、トラフィックコントロールメカニズムが混雑を効果的に扱ったかどうかを言うことはできません。
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]は、「2つのイベントを区別するのに十分な繊細なユニットで時間」に使用されます。
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、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、セクション2には、ネットワーク層トラフィック制御メカニズムに関連する多くの用語の議論も含まれており、また相談する必要があります。
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は、RFC 1242のセクション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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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
DA宛先アドレスDS DIFFSERV DSCP DIFFSERVコードポイントDUTデバイステスト下のIPインターネットプロトコルPHB PERホップ動作SAソースアドレスSUTシステム
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の優先順位値のセット。
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に入力されるパケットに関連付けられたすべてのコードポイントマーキングについて説明します。CodePointセットの各エントリについて、特定のDSCPまたはIPの優先順位値を含むトラフィック、遅延、損失、またはジッターのレートを説明する関連ベクトルがあります。
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.
定義：1つ以上の出口インターフェイスが転送されるよりも多くのパケットが提供される条件。
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]に記載されているように、赤[BR98]はバッファーがオーバーフローする前に初期の混雑を検出しますが、現在のインターネット環境は、エンドノードへの輻輳を示すメカニズムとしてパケット損失に限定されています。[RA99]は、初期の混雑を観察するためにブラックボックステストを構築することは非現実的であることを意味します。[RA99]は、初期の混雑を観察するための決定論的なブラックボックス方法として、明示的な混雑通知（ECN）を導入します。[RA99]は、展開が限られている実験RFCであるため、ECNはこの特定の方法論には使用されません。ために
"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]は、バッファーがいっぱいで、すべての到着パケットをネットワーク全体にドロップする必要がある状態として定義されます。Ingress Interfacesはすべてのパケットを損失なく受け入れますが、この仮想デバイスには転送輻輳が存在します。
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.
輻輳制御メカニズムは、混雑期間中に他のクラスで1つ以上のフロー（離散IPの優先順位またはDSCP値）を優先的に処理します。
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アドレスを含めることができます。フロー内のすべてのパケットは、同じIngressインターフェイスに入力し、同じEgressインターフェイスで終了し、共通のネットワークレイヤーコンテンツを持つ必要があります。
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
参照：microflow [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.
定義：デバイスが指定された提供された負荷に応じて正しい出力インターフェイスに正常に送信するようにデバイスを観察できるパケット数は、提供されたパケットをドロップしません。
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インターフェイスでパケットレートを測定します。
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-OCTETパケットあたりのパケット
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. Latency [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]との重要な違いです。たとえば、2つのDUTによって追加された遅延は、DUTSの遅延の合計に等しくなければなりません。これは、[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が実行されるすべてのリンク層プロトコルの開始/端を指定することをテスターに解放します。これにより、Start/Stopデリミターが含まれているかどうかを判断する必要性が回避されます。また、テストで不均一なリンク層プロトコルを使用することもできます。
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]
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は、ペアから1つのパケットが紛失した場合に定義されていません。
Measurement units: milliseconds
測定単位：ミリ秒
See Also:
Forwarding Delay
Jitter variation [Ja99]
ipdv [De02]
interarrival jitter [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.
ディスカッション：DIF-ServまたはIPの優先順位メカニズムを有効にすると、パケットの追加処理オーバーヘッドが課される場合があります。このオーバーヘッドは、トラフィックが1つのクラスである最高のクラスに属している場合でも、デバイスに提供されている場合でも、パフォーマンスを低下させる可能性があります。ベースラインを確立するために、「未分化応答」の測定を行う必要があります。
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の優先順位によるものです。テストシーケンス番号を使用したストリームは、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つまたは複数のマルチキャストレシーバーへのパスがそのインターフェイスを使用している場合、特定の出力インターフェイスにパケットを1回転送する必要があります。いくつかの出力インターフェイスは、同じパケットを送信しますが、インターフェイスごとに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-bytesパケットあたりのパケット
See Also: Stream Offered Vector Forwarding 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-bytesパケットあたりのパケット
See Also: Stream Intended Vector Forwarding 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-OCTETパケットあたりのパケット
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]
参照。
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-OCTETパケットあたりのパケット
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などの特定の分類に一致する2つの連続したパケットの到着時間の間の予想される瞬間ジッターの説明。
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
参照：分類ストリームジッター意図ベクトル提供ベクトル
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.
ピーク間ジッターは、瞬時のジッターベクトルから派生したものではありません。ピーク間ジッターは、2つの連続したパケットだけでなく、テスト期間中のすべてのパケットに基づいています。
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などの特定の分類に一致するストリームのパケット数は、提供されたベクトルに応じて正しい宛先インターフェイスに正常に転送するように測定されるように測定されます。
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-OCTETパケットあたりのパケット
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.
定義：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の優先順位値に照会する場合があります。ストリームは同じままです。
Measurement Units: Percentage of packets
測定単位：パケットの割合
See Also: Classification Stream Intended Vector Offered Vector Expected Vector One-way Packet Loss Metric [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などの特定の分類に一致するストリーム内のすべてのパケットのパケット数は、提供されたベクトルに応じて正しい宛先インターフェイスに順番に送信するように測定されることを測定します。
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の優先順位値に照会する場合があります。ストリームは同じままです。
Measurement Units: N-octet packets per second
測定単位：N-OCTETパケットあたりのパケット
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.
定義：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の優先順位値に照会する場合があります。ストリームは同じままです。
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.
定義：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の優先順位値に照会する場合があります。ストリームは同じままです。
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.
定義：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の優先順位値に照会する場合があります。ストリームは同じままです。
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.
定義：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の優先順位値に照会する場合があります。ストリームは同じままです。
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つの連続したパケットのジッターは、提供されたベクトルに応じて正しい宛先インターフェイスに正常に送信するように測定されます。
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の優先順位値に照会する場合があります。ストリームは同じままです。
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.
定義：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の優先順位値に照会する場合があります。ストリームは同じままです。
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などの特定の分類と一致するストリーム内のパケットの転送遅延の最大変動は、提供されたベクトルに応じて正しい宛先インターフェイスに正常に送信するように測定されます。
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.
ピーク間ジッターは、瞬時のジッターベクトルから派生したものではありません。ピーク間ジッターは、2つの連続したパケットだけでなく、テスト期間中のすべてのパケットに基づいています。
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の優先順位値を持つパケットは、セキュリティの問題を提示する場合があります。このようなパケットのセキュリティ結果を決定することは、このドキュメントの範囲外です。
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のベンチマーク方法論ワーキンググループメンバーの貢献に感謝します。著者は、この文書の開発を通して彼の一貫した貴重な支援について、デビッド・ニューマンに感謝します。著者はまた、アル・モートンとケビン・ダブレイのアイデアとサポートに感謝したいと思います。
[Br91] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991.
[BR91] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] 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。、およびL. Zhang、「インターネットでのキュー管理と混雑回避に関する推奨事項」、RFC 2309、1998年4月。
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[MA98] Mandeville、R。、「LANスイッチングデバイスのベンチマーク用語」、RFC 2285、1998年2月。
[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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[St91] Steinberg, L., "Techniques for managing asynchronously generated alerts", RFC 1224, May 1991.
[St91] Steinberg、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[BR99] Bradner、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] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」、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] Floyd、S。、およびJacobson、V。、「混雑回避のためのランダムな早期検出ゲートウェイ」、Networkingに関するIEEE/ACMトランザクション、v.1 N.4、1993年8月、p。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] Davie、B.、Charny、A.、Bennet、J.C.、Benson、K.、Le Boudec、J.、Courtney、W.、Davari、S.、Firoiu、V。、およびD. Stiliadis」迅速な転送PHB（ホップごとの動作）」、RFC 3246、2002年3月。
[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] Mankin、A。およびK. Ramakrishnan、「Gateway commestion Control Survey」、RFC 1254、1991年8月。
[Ma00] Mandeville, R. and J. Perser, "Benchmarking Methodology for LAN Switching Devices", RFC 2889, August 2000.
[MA00] Mandeville、R。およびJ. Perser、「LANスイッチングデバイスのベンチマーク方法論」、RFC 2889、2000年8月。
[Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., Perser, J., "Packet Reordering Metric for IPPM", Work in Progress.
[Mo03] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S.、Perser、J。、「IPPMのパケット並べ替えメトリック」、進行中の作業。
[Na84] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[Na84] Nagle、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] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、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.
[SC96] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
Authors' Addresses
著者のアドレス
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton, OR 97008 USA USA
Jerry Perser Veriwave 8770 SW Nimbus Ave. Suite B Beaverton、または97008 USA USA
Phone: + 1 818 338 4112
EMail: jerry@perser.org
Scott Poretsky Reef Point Systems 8 New England Executive Park Burlington, MA 01803 USA
スコットポレツキーリーフポイントシステム8ニューイングランドエグゼクティブパークバーリントン、マサチューセッツ州01803 USA
Phone: + 1 508 439 9008
EMail: sporetsky@reefpoint.com
Shobha Erramilli Telcordia Technologies 331 Newman Springs Road Red Bank, New Jersey 07701 USA
Shobha Erramilli Telcordia Technologies 331 Newman Springs Road Red Bank、ニュージャージー07701 USA
EMail: shobha@research.telcordia.com
Sumit Khurana Motorola 7700 West Parmer Ln. Austin, TX 78729 USA
Sumit Khurana Motorola 7700 West Parmer Ln。テキサス州オースティン78729 USA
Phone: +1 512 996 6604
Email: skhurana@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。