Network Working Group D. Stopp
Request for Comments: 3918 Ixia
Category: Informational B. Hickman
Spirent Communications
October 2004
Methodology for IP Multicast Benchmarking
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
このドキュメントの目的は、マルチキャストIP転送デバイスのベンチマーキングに特定の方法論を記述することです。これは、RFC 2432 RFC 2544と他のIETFベンチマーク手法ワーキンググループ（BMWG）の努力に記載された教義上に構築されています。この文書では、マルチキャストパラダイムにこれらの努力を拡張しようとしています。
The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.
ベンチマーク用語の文書やベンチマーキング方法論の文書：BMWGは、文書の2つの主要なクラスを生成します。用語の文書は、ベンチマークやその他の関連する用語を提示します。方法論の文書は、対応する用語の文書に引用ベンチマークを収集するために必要な手順を定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words to Reflect Requirements. . . . . . . . . . . . . . . 3
3. Test Set Up. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Test Considerations. . . . . . . . . . . . . . . . . . . 4
3.1.1. IGMP Support. . . . . . . . . . . . . . . . . . . 5
3.1.2. Group Addresses . . . . . . . . . . . . . . . . . 5
3.1.3. Frame Sizes . . . . . . . . . . . . . . . . . . . 5
3.1.4. TTL . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. Trial Duration. . . . . . . . . . . . . . . . . . 6
4. Forwarding and Throughput. . . . . . . . . . . . . . . . . . . 6
4.1. Mixed Class Throughput . . . . . . . . . . . . . . . . . 6
4.2. Scaled Group Forwarding Matrix . . . . . . . . . . . . . 8
4.3. Aggregated Multicast Throughput. . . . . . . . . . . . . 9
4.4. Encapsulation/Decapsulation (Tunneling) Throughput . . . 10
4.4.1. Encapsulation Throughput. . . . . . . . . . . . . 10
4.4.2. Decapsulation Throughput. . . . . . . . . . . . . 12
4.4.3. Re-encapsulation Throughput . . . . . . . . . . . 14
5. Forwarding Latency . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Multicast Latency. . . . . . . . . . . . . . . . . . . . 16
5.2. Min/Max Multicast Latency. . . . . . . . . . . . . . . . 18
6. Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Group Join Delay . . . . . . . . . . . . . . . . . . . . 20
6.2. Group Leave Delay. . . . . . . . . . . . . . . . . . . . 22
7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Multicast Group Capacity . . . . . . . . . . . . . . . . 24
8. Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Forwarding Burdened Multicast Latency. . . . . . . . . . 25
8.2. Forwarding Burdened Group Join Delay . . . . . . . . . . 27
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. Contributions. . . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
This document defines tests for measuring and reporting the throughput, forwarding, latency and Internet Group Management Protocol (IGMP) group membership characteristics of devices that support IP multicast protocols. The results of these tests will provide the user with meaningful data on multicast performance.
この文書では、IPマルチキャストプロトコルをサポートするデバイスの特性を測定し、スループット、転送、遅延を報告し、インターネットグループ管理プロトコル（IGMP）グループメンバーシップのためにテストを定義します。これらのテストの結果は、マルチキャストパフォーマンス上の意味のあるデータをユーザに提供します。
A previous document, "Terminology for IP Multicast Benchmarking" [Du98], defined many of the terms that are used in this document. The terminology document should be consulted before attempting to make use of this document.
以前の文書、「IPマルチキャストベンチマーキングのための用語」[Du98]は、このドキュメントで使用されている用語の多くを定義しました。用語の文書は、この文書を使用することを試みる前に相談する必要があります。
This methodology will focus on one source to many destinations, although many of the tests described may be extended to use multiple source to multiple destination topologies.
記載した試験の多くは、複数の宛先トポロジに複数のソースを使用するように拡張することができるが、この方法は、多くの宛先に一つのソースに焦点を当てます。
Subsequent documents may address IPv6 multicast and related multicast routing protocol performance. Additional insight on IP and multicast networking can be found in [Hu95], [Ka98] and [Mt98].
後続のドキュメントは、IPv6マルチキャストと関連するマルチキャストルーティングプロトコルの性能に対処することができます。 IPマルチキャストネットワーク上の追加の洞察力は、[Ka98]と[Mt98]、[Hu95]で見つけることができます。
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は、可能な限り明確な基準トラック文書の意図を支援するために、これらのキーワードの使用を定義します。この文書は、これらのキーワードを使用していますが、この文書では、標準トラック文書ではありません。
The set of methodologies presented in this document are for single ingress, multiple egress multicast scenarios as exemplified by Figures 1 and 2. Methodologies for multiple ingress and multiple egress multicast scenarios are beyond the scope of this document.
図1およびマルチキャストのシナリオは、この文書の範囲を超えて複数の入力および複数の出力2.方法論によって例示されるように、この文書で提示方法論のセットは、単一入口、複数出口マルチキャストシナリオのためのものです。
Figure 1 shows a typical setup for an IP multicast test, with one source to multiple destinations.
図1は、複数の宛先への1つのソースと、IPマルチキャスト試験のための典型的なセットアップを示します。
+------------+ +--------------+
| | | destination |
+--------+ | Egress(-)------->| test |
| source | | | | port(E1) |
| test |------>(|)Ingress | +--------------+
| port | | | +--------------+
+--------+ | Egress(-)------->| destination |
| | | test |
| | | port(E2) |
| DUT | +--------------+
| | . . .
| | +--------------+
| | | destination |
| Egress(-)------->| test |
| | | port(En) |
+------------+ +--------------+
Figure 1
図1
If the multicast metrics are to be taken across multiple devices forming a System Under Test (SUT), then test frames are offered to a single ingress interface on a device of the SUT, subsequently forwarded across the SUT topology, and finally forwarded to the test apparatus' frame-receiving components by the test egress interface(s) of devices in the SUT. Figure 2 offers an example SUT test topology. If a SUT is tested, the test topology and all relevant configuration details MUST be disclosed with the corresponding test results.
マルチキャストメトリックはテスト対象システム（SUT）を形成する複数のデバイス間で解釈されるべきである場合、テストフレームは、SUTのデバイス上の単一の入力インターフェイスに提供され、その後SUTトポロジを横切って転送され、最終的にテストに転送しますSUT内のデバイスの試験出力インターフェイス（複数可）によって装置フレーム受容部品。図2は、例えば、SUTのテストトポロジを提供しています。 SUTをテストする場合、テストトポロジと関連するすべての構成の詳細は、対応する試験結果で開示されなければなりません。
*-----------------------------------------*
| |
+--------+ | +----------------+ | +--------+
| | | +------------+ |DUT B Egress E0(-)-|->| |
| | | |DUT A |--->| | | | |
| source | | | | | Egress E1(-)-|->| dest. |
| test |--|->(-)Ingress, I | +----------------+ | | test |
| port | | | | +----------------+ | | port |
| | | | |--->|DUT C Egress E2(-)-|->| |
| | | +------------+ | | | | |
| | | | Egress En(-)-|->| |
+--------+ | +----------------+ | +--------+
| |
*------------------SUT--------------------*
Figure 2
図2
Generally, the destination test ports first join the desired number of multicast groups by sending IGMP Group Report messages to the DUT/SUT. To verify that all destination test ports successfully joined the appropriate groups, the source test port MUST transmit IP multicast frames destined for these groups. After test completion, the destination test ports MAY send IGMP Leave Group messages to clear the IGMP table of the DUT/SUT.
一般的に、先のテストポートは、第DUT / SUTにIGMPグループ報告メッセージを送信することによってマルチキャストグループの所望の数に参加します。すべての宛先テストポートが正常に適切なグループに参加していることを確認するために、ソース・テスト・ポートは、これらのグループ宛のIPマルチキャストフレームを送信しなければなりません。テスト終了後、先のテスト・ポートは、DUT / SUTのIGMPテーブルをクリアするIGMPのLeave Groupメッセージを送信することができます。
In addition, test equipment MUST validate the correct and proper forwarding actions of the devices they test in order to ensure the receipt of the frames that are involved in the test.
また、試験装置は、試験に関与しているフレームの受信を確実にするために、彼らはテスト装置の正確かつ適切なフォワーディングアクションを検証する必要があります。
The methodology assumes a uniform medium topology. Issues regarding mixed transmission media, such as speed mismatch, headers differences, etc., are not specifically addressed. Flow control, QoS and other non-essential traffic or traffic-affecting mechanisms affecting the variable under test MUST be disabled. Modifications to the collection procedures might need to be made to accommodate the transmission media actually tested. These accommodations MUST be presented with the test results.
方法論は、均一な媒質トポロジを前提としています。そのような速度の不一致、ヘッダの違い、などのような混合伝送メディアに関する問題は、具体的に対処されていません。フロー制御、QoSとは、他の非本質的なトラフィックやテスト中の変数に影響を与えるトラフィックに影響のメカニズムを無効にする必要があります。収集手順への変更は、実際にテストした伝送媒体に対応するために行われる必要があります。これらの客室には、テスト結果を提示しなければなりません。
An actual flow of test traffic MAY be required to prime related mechanisms, (e.g., process RPF events, build device caches, etc.) to optimally forward subsequent traffic. Therefore, prior to running any tests that require forwarding of multicast or unicast packets, the test apparatus MUST generate test traffic utilizing the same addressing characteristics to the DUT/SUT that will subsequently be used to measure the DUT/SUT response. The test monitor should ensure the correct forwarding of traffic by the DUT/SUT. The priming action need only be repeated to keep the associated information current.
テストトラフィックの実際の流量を最適フォワード後続のトラフィックに（例えば、プロセスRPFイベント、デバイスキャッシュ、等を構築する）、プライム関連機構に必要とされ得ます。したがって、マルチキャスト、またはユニキャストパケットの転送を必要とするテストを実行する前に、試験装置は、その後、DUT / SUTの応答を測定するために使用されるDUT / SUTに同じアドレッシング特性を利用テストトラフィックを生成しなければなりません。テストモニターは、DUT / SUTによってトラフィックの正しい転送を保証すべきです。プライミングアクションは、関連する情報を最新の状態に保つために繰り返される必要があります。
It is the intent of this memo to provide the methodology for basic characterizations regarding the forwarding of multicast packets by a device or simple system of devices. These characterizations may be useful in illustrating the impact of device architectural features (e.g., message passing versus shared memory; handling multicast traffic as an exception by the general purpose processor versus the by a primary data path, etc.) in the forwarding of multicast traffic.
デバイスまたはデバイスの簡単なシステムにより、マルチキャストパケットの転送に関する基本的な特徴付けのための方法論を提供するために、このメモの目的です。マルチキャストトラフィックの転送に、（プライマリ・データ・パス、等によって対汎用プロセッサにより例外としてマルチキャストトラフィックを処理、例えば、メッセージ、共有メモリに対して通過）は、これらの特徴付けは、デバイスアーキテクチャ機能の影響を説明するのに有用であり得ます。
It has been noted that the formation of the multicast distribution tree may be a significant component of multicast performance. While this component may be present in some of the measurements or scenarios presented in this memo, this memo does not seek to explicitly benchmark the formation of the multicast distribution tree. The benchmarking of the multicast distribution tree formation is left as future, more targeted work specific to a given tree formation vehicle.
マルチキャスト配信ツリーの形成がマルチキャスト性能の重要な構成要素であり得ることが注目されてきました。このコンポーネントは、このメモで提示測定またはシナリオの一部に存在してもよいが、このメモは、マルチキャスト配信ツリーの明示的ベンチマーク形成しようとしません。マルチキャスト配信ツリー形成のベンチマークは、与えられた木の形成車両に固有の将来、よりターゲットを絞っ作品として残されています。
All of the ingress and egress interfaces MUST support a version of IGMP. The IGMP version on the ingress interface MUST be the same version of IGMP that is being tested on the egress interfaces.
入力および出力インターフェイスのすべては、IGMPのバージョンをサポートしなければなりません。入力インターフェイス上でIGMPバージョンが出力インターフェイス上でテストされているIGMPの同じバージョンでなければなりません。
Each of the ingress and egress interfaces SHOULD be able to respond to IGMP queries during the test.
入力および出力インターフェイスの各々は、試験中にIGMPクエリに応答することができるべきです。
Each of the ingress and egress interfaces SHOULD also send LEAVE (running IGMP version 2 or later) [Ca02] [Fe97] after each test.
入力および出力インターフェイスの各々は、各テストの後に[CA02] [Fe97]（IGMPバージョン2以降を実行している）LEAVEを送信すべきです。
There is no restriction to the use of multicast addresses [De89] to compose the test traffic other than those assignments imposed by IANA. The IANA assignments for multicast addresses [IANA1] MUST be regarded for operational consistency. Address selection does not need to be restricted to Administratively Scoped IP Multicast addresses [Me98].
IANAによって課されるものの割り当て以外のテストトラフィックを構成するマルチキャストアドレス[De89]の使用に制限はありません。マルチキャストアドレスのIANAの割り当ては、[IANA1]操作の一貫性のために考えなければなりません。アドレス選択は、管理スコープのIPマルチキャストアドレス[Me98]に制限する必要はありません。
Each test SHOULD be run with different multicast frame sizes. For Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280, and 1518 byte frames.
各テストは、異なるマルチキャストフレームサイズで実行する必要があります。イーサネットの場合、推奨されるサイズは64、128、256、512、1024、1280、1518のバイトのフレームです。
Other link layer technologies MAY be used. The minimum and maximum frame lengths of the link layer technology in use SHOULD be tested.
その他のリンク層技術を使用することができます。使用中のリンク層技術の最小および最大フレーム長は、試験されるべきです。
When testing with different frame sizes, the DUT/SUT configuration MUST remain the same.
異なったフレームサイズでテストする場合、DUT / SUTの構成は同じままでなければなりません。
The data plane test traffic should have a TTL value large enough to traverse the DUT/SUT.
データプレーンのテストトラフィックは、DUT / SUTを横断するのに十分な大きTTL値を有するべきです。
The TTL in IGMP control plane messages MUST be in compliance with the version of IGMP in use.
IGMP制御プレーンメッセージ内のTTLは、使用中のIGMPのバージョンに準拠していなければなりません。
The duration of the test portion of each trial SHOULD be at least 30 seconds. This parameter MUST be included as part of the results reporting for each methodology.
各試験の試験部分の持続時間は少なくとも30秒であるべきです。このパラメータは、それぞれの方法論のレポート結果の一部として含まれなければなりません。
This section contains the description of the tests that are related to the characterization of the frame forwarding of a DUT/SUT in a multicast environment. Some metrics extend the concept of throughput presented in RFC 1242. Forwarding Rate is cited in RFC 2285 [Ma98].
このセクションでは、マルチキャスト環境においてDUT / SUTのフレーム転送の特性に関連するテストの記述を含みます。いくつかの指標は1242転送レートはRFC 2285 [MA98]で引用されたRFCに提示スループットの概念を拡張します。
Objective:
目的：
To determine the throughput of a DUT/SUT when both unicast class frames and multicast class frames are offered simultaneously to a fixed number of interfaces as defined in RFC 2432.
RFC 2432で定義されるようにユニキャストクラスフレームおよびマルチキャスト・クラス・フレームの両方がインターフェイスの固定数に同時に提供されるDUT / SUTのスループットを決定します。
Procedure:
手順：
Multicast and unicast traffic are mixed together in the same aggregated traffic stream in order to simulate a heterogeneous networking environment.
マルチキャストとユニキャストトラフィックは、異種ネットワーク環境をシミュレートするために、同一の集約トラフィックストリームに一緒に混合されます。
The following events MUST occur before offering test traffic:
次のイベントは、テストトラフィックを提供する前に発生する必要があります：
o All destination test ports configured to receive multicast traffic MUST join all configured multicast groups; o The DUT/SUT MUST learn the appropriate unicast and multicast addresses; and
Oマルチキャストトラフィックを受信するように構成されたすべての宛先テスト・ポートは、すべての設定されたマルチキャストグループに参加する必要があります。 O DUT / SUTは、適切なユニキャストとマルチキャストアドレスを学ばなければなりません。そして
o Group membership and unicast address learning MUST be verified through some externally observable method.
Oグループメンバーシップとユニキャストアドレス学習は、いくつかの外部から観察可能な方法によって検証されなければなりません。
The intended load [Ma98] SHOULD be configured as alternating multicast class frames and unicast class frames to a single ingress interface. The unicast class frames MUST be configured to transmit in an unweighted round-robin fashion to all of the destination ports.
意図した荷重は、[MA98]単一入力インターフェイスにマルチキャストクラスフレーム及びユニキャストクラスフレームを交互ように構成されるべきです。ユニキャストクラスのフレームは、宛先ポートのすべてに非加重ラウンドロビン方式で送信するように構成されなければなりません。
For example, with six multicast groups and 3 destination ports with one unicast addresses per port, the source test port will offer frames in the following order:
例えば6つのマルチキャストグループとポートごとにユニキャストアドレスを持つ3つの宛先ポートと、ソース・テスト・ポートは、次の順序でフレームを提供します。
m1 u1 m2 u2 m3 u3 m4 u1 m5 u2 m6 u3 m1 ...
Y1、M1、M2 M3 W2スキッドY1 M4 M5 M6 W2カラット... M1
Where:
どこ：
m<Number> = Multicast Frame<Group> u<Number> = Unicast Frame<Target Port>
M <番号> =マルチキャストフレーム<グループ> U <番号> =ユニキャストフレーム<ターゲットポート>
Mixed class throughput measurement is defined in RFC 2432 [Du98]. A search algorithm MUST be utilized to determine the Mixed Class Throughput. The ratio of unicast to multicast frames MUST remain the same when varying the intended load.
混合クラスのスループット測定は[Du98] RFC 2432で定義されています。検索アルゴリズムは、混合クラスのスループットを決定するために利用されなければなりません。意図した負荷を変化させたときにマルチキャストフレームをユニキャストの比率は同じままでなければなりません。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o Traffic distribution for unicast and multicast traffic classes o The ratio of multicast to unicast class traffic
ユニキャストクラストラフィックに対するマルチキャストの比Oユニキャストおよびマルチキャストトラフィッククラスのトラフィック分布Oマルチキャストグループの総数O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o Mixed Class Throughput as defined in RFC 2432 [Du98], including: Throughput per unicast and multicast traffic classes.
ユニキャスト当たりのスループットおよびマルチキャストトラフィッククラス：[Du98] RFC 2432で定義されるようにOを含む、クラススループットを混合しました。
The Mixed Class Throughput results for each test SHOULD be reported in the form of a table with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row SHOULD specify the intended load, number of multicast frames offered, number of unicast frames offered and measured throughput per class.
各試験のためのミックスクラススループット結果をセクション3.1.3に推奨に従って試験されたフレームサイズのそれぞれの行を有する表の形で報告されるべきです。各行は、提供されるマルチキャストフレーム、クラスごとのスループットを提供し、測定されたユニキャストフレームの数の数を意図する負荷を特定すべきです。
Objective:
目的：
To determine Forwarding Rate as a function of tested multicast groups for a fixed number of tested DUT/SUT ports.
試験されたDUT / SUTポートの固定数の試験マルチキャストグループの関数としての転送速度を決定します。
Procedure:
手順：
This is an iterative procedure. The destination test port(s) MUST join an initial number of multicast groups on the first iteration. All destination test ports configured to receive multicast traffic MUST join all configured multicast groups. The recommended number of groups to join on the first iteration is 10 groups. Multicast traffic is subsequently transmitted to all groups joined on this iteration and the forwarding rate is measured.
これは、反復手順です。先のテスト・ポート（複数可）は、最初の反復でのマルチキャストグループの初期数に参加しなければなりません。マルチキャストトラフィックを受信するように構成されたすべての宛先テスト・ポートは、すべての設定されたマルチキャストグループに加入しなければなりません。最初の反復に参加するグループの推奨数は10個のグループです。マルチキャストトラフィックは、その後、すべてのグループに送信され、この反復に参加し、転送速度が測定されます。
The number of multicast groups joined by each destination test port is then incremented, or scaled, by an additional number of multicast groups. The recommended granularity of additional groups to join per iteration is 10, although the tester MAY choose a finer granularity. Multicast traffic is subsequently transmitted to all groups joined during this iteration and the forwarding rate is measured.
各宛先テストポートによって接合されたマルチキャストグループの数がインクリメント、またはマルチキャストグループの追加の数によって、スケーリングされます。テスターは、より細かい粒度を選択するかもしれないが、反復ごとに参加するために追加のグループの推奨粒度は、10です。マルチキャストトラフィックは、その後、すべてのグループに送信され、この反復中に参加し、転送速度を測定します。
The total number of multicast groups joined MUST not exceed the multicast group capacity of the DUT/SUT. The Group Capacity (Section 7.1) results MUST be known prior to running this test.
マルチキャストグループの総数は、DUT / SUTのマルチキャストグループの容量を超えてはならない参加しました。グループの容量（7.1節）の結果は、このテストを実行する前に知らなければなりません。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version
IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The total number of multicast groups joined for that iteration
Oマルチキャストグループの総数は、その反復のために参加しました
o Forwarding rate determined for that iteration
O転送レートは、その反復のために決定します
The Scaled Group Forwarding results for each test SHOULD be reported in the form of a table with a row representing each iteration of the test. Each row or iteration SHOULD specify the total number of groups joined for that iteration, offered load, total number of frames transmitted, total number of frames received and the aggregate forwarding rate determined for that iteration.
各試験のためにスケール・グループの転送結果がテストの各反復を表す行と表の形で報告されるべきです。グループの総数を指定する必要があり、各行又は反復は、その反復のために提供された負荷に参加し、送信されたフレームの合計数、受信フレームの総数とその反復について決定総計転送レート。
Objective:
目的：
To determine the maximum rate at which none of the offered frames to be forwarded through N destination interfaces of the same multicast groups are dropped.
同じマルチキャストグループのN先のインタフェースを介して転送されるために提供フレームのどれが削除されていない最大速度を決定します。
Procedure:
手順：
Offer multicast traffic at an initial maximum offered load to a fixed set of interfaces with a fixed number of groups at a fixed frame length for a fixed duration of time. All destination test ports MUST join all specified multicast groups.
時間の固定期間のための固定されたフレーム長でグループの固定数とインターフェースの固定セットに初期最大提供された負荷でマルチキャストトラフィックを提供します。すべての宛先テスト・ポートは、指定されたすべてのマルチキャストグループに参加する必要があります。
If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be utilized to determine the maximum offered frame rate with a zero frame loss.
任意のフレーム損失が検出された場合、提供された負荷が減少され、送信者が再び送信します。反復探索アルゴリズムは、ゼロフレーム損失と最大提供フレームレートを決定するために利用されなければなりません。
Each iteration will involve varying the offered load of the multicast traffic, while keeping the set of interfaces, number of multicast groups, frame length and test duration fixed, until the maximum rate at which none of the offered frames are dropped is determined.
フレーム長とテスト期間が固定され、マルチキャストグループの数をインタフェースのセットを維持したまま提供フレームのどれが削除されていない最大レートが決定されるまで、各反復は、マルチキャストトラフィックのオファードロードを変える含むであろう。
Parameters to be measured MUST include the maximum offered load at which no frame loss occurred. Other offered loads MAY be measured for diagnostic purposes.
測定されるパラメータには、フレーム損失が発生しなかった最大オファードロードを含まなければなりません。その他の提供負荷は、診断目的のために測定することができます。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups
マルチキャストグループの総数O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o Aggregated Multicast Throughput as defined in RFC 2432 [Du98]
RFC 2432で定義されるように集約マルチキャストスループットO [Du98]
The Aggregated Multicast Throughput results SHOULD be reported in the format of a table with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration SHOULD specify offered load, total number of offered frames and the measured Aggregated Multicast Throughput.
集約マルチキャストスループット結果をセクション3.1.3に推奨に従って試験されたフレームサイズのそれぞれの行を有するテーブルの形式で報告されるべきです。各行又は反復は提供された負荷、提供フレームの総数と測定集約マルチキャストスループットを特定すべきです。
This sub-section provides the description of tests related to the determination of throughput measurements when a DUT/SUT or a set of DUTs are acting as tunnel endpoints.
このサブセクションでは、DUT / SUTまたはDUTのセットは、トンネルエンドポイントとして動作しているスループット測定の決意に関連するテストの説明を提供します。
For this specific testing scenario, encapsulation or tunneling refers to a packet that contains an unsupported protocol feature in a format that is supported by the DUT/SUT.
この特定のテストシナリオでは、カプセル化またはトンネリングは、DUT / SUTによって支持されている形式でサポートされていないプロトコル機能が含まれているパケットを指します。
Objective:
目的：
To determine the maximum rate at which frames offered to one ingress interface of a DUT/SUT are encapsulated and correctly forwarded on one or more egress interfaces of the DUT/SUT without loss.
DUT / SUTの入力インターフェイスに提供フレームれる最大レートを決定するために損失することなくカプセル化され、正しくDUT / SUTの一つ以上の出力インターフェイスに転送されます。
Procedure:
手順：
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
| |------->|Ingress | | |
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
+---------+ +-----------+ +---------+
Figure 3
図3
Figure 3 shows the setup for testing the encapsulation throughput of the DUT/SUT. One or more tunnels are created between each egress interface of the DUT/SUT and a destination test port. Non-Encapsulated multicast traffic will then be offered by the source test port, encapsulated by the DUT/SUT and forwarded to the destination test port(s).
図3は、DUT / SUTのカプセル化スループットをテストするためのセットアップを示します。一つ以上のトンネルがDUT / SUTの各出力インターフェイスと宛先テストポートとの間に作成されます。非封入マルチキャストトラフィックは、その後、DUT / SUTによってカプセル化され、宛先テストポート（複数可）に転送され、ソース・テスト・ポートによって提供されるであろう。
The DUT/SUT SHOULD be configured such that the traffic across each egress interface will consist of either:
DUT / SUTは、各出力インターフェイス上のトラフィックのいずれかで構成するように構成されるべきです。
a) A single tunnel encapsulating one or more multicast address groups OR b) Multiple tunnels, each encapsulating one or more multicast address groups.
a）1種または複数のマルチキャストアドレスグループまたはb）複数のトンネル、各封入1つまたは複数のマルチキャストアドレスグループをカプセル化する単一のトンネル。
The number of multicast groups per tunnel MUST be the same when the DUT/SUT is configured in a multiple tunnel configuration. In addition, it is RECOMMENDED to test with the same number of tunnels on each egress interface. All destination test ports MUST join all multicast group addresses offered by the source test port. Each egress interface MUST be configured with the same MTU.
DUT / SUTが複数のトンネル設定で設定されたときにトンネルあたりのマルチキャストグループの数は同じでなければなりません。加えて、各出力インターフェイス上のトンネルの数が同じでテストすることが推奨されます。すべての宛先テスト・ポートは、ソース・テスト・ポートが提供するすべてのマルチキャストグループアドレスに参加する必要があります。各出力インターフェイスは同じMTUを設定する必要があります。
Note: when offering large frames sizes, the encapsulation process may require the DUT/SUT to fragment the IP datagrams prior to being forwarded on the egress interface. It is RECOMMENDED to limit the offered frame size such that no fragmentation is required by the DUT/SUT.
注：大きなフレームサイズを提供する場合、カプセル化プロセスは、従来の出力インターフェイス上で転送されることにIPデータグラムを断片化するDUT / SUTを必要とするかもしれません。全くフラグメンテーションがDUT / SUTによって必要とされないように提供されるフレームサイズを制限することが推奨されます。
A search algorithm MUST be utilized to determine the encapsulation throughput as defined in [Du98].
探索アルゴリズムは、[Du98]で定義されるようにカプセル化スループットを決定するために利用されなければなりません。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o MTU size of DUT/SUT interfaces o Originating un-encapsulated frame size o Number of tunnels per egress interface o Number of multicast groups per tunnel o Encapsulation algorithm or format used to tunnel the packets
O DUT / SUTインターフェースのMTUサイズOマルチキャストグループの総数O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスのO数マルチキャストグループのイグレスインタフェースO数当たりのトンネルの非カプセル化されたフレームサイズO番号を発信しますパケットトンネルに使用されるトンネルOカプセル化アルゴリズムまたは形式ごと
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o Measured Encapsulated Throughput as defined in RFC 2432 [Du98] o Encapsulated frame size
RFC 2432で定義されるようにOカプセル化されたフレームのサイズO [Du98]カプセル化スループット測定
The Encapsulated Throughput results SHOULD be reported in the form of a table and specific to this test there SHOULD be rows for each originating un-encapsulated frame size. Each row or iteration SHOULD specify the offered load, encapsulation method, encapsulated frame size, total number of offered frames, and the encapsulation throughput.
カプセル化されたスループットの結果は、各発信非カプセル化されたフレームのサイズの行がなければならない表の形で報告され、このテストに特異的であるべきです。各行又は反復は提供された負荷、カプセル化法、カプセル化されたフレームサイズ、提供されるフレームの総数、およびカプセル化のスループットを指定する必要があります。
Objective:
目的：
To determine the maximum rate at which frames offered to one ingress interface of a DUT/SUT are decapsulated and correctly forwarded by the DUT/SUT on one or more egress interfaces without loss.
DUT / SUTの入力インターフェイスに提供フレームれる最大レートを決定するために、カプセル化が解除され、正しく損失せずに、1つのまたは複数の出力インターフェイス上のDUT / SUTによって転送されます。
Procedure:
手順：
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|------->| |
| | | | | |
| |--(Tunnel)-->|Ingress | | |
| | | | | |
| | | Egress|------->| |
| | | | | |
+---------+ +-----------+ +---------+
Figure 4
図4
Figure 4 shows the setup for testing the decapsulation throughput of the DUT/SUT. One or more tunnels are created between the source test port and the DUT/SUT. Encapsulated multicast traffic will then be offered by the source test port, decapsulated by the DUT/SUT and forwarded to the destination test port(s).
図4は、DUT / SUTのデカプセル化スループットをテストするためのセットアップを示します。一つ以上のトンネルは、ソース・テスト・ポートとDUT / SUTの間に作成されます。カプセル化されたマルチキャストトラフィックは、DUT / SUTによってデカプセル化し、宛先テストポート（複数可）に転送され、ソース・テスト・ポートによって提供されるであろう。
The DUT/SUT SHOULD be configured such that the traffic across the ingress interface will consist of either:
DUT / SUTは、入力インターフェースを介してトラフィックがいずれかから構成するように構成されるべきです。
a) A single tunnel encapsulating one or more multicast address groups OR b) Multiple tunnels, each encapsulating one or more multicast address groups.
a）1種または複数のマルチキャストアドレスグループまたはb）複数のトンネル、各封入1つまたは複数のマルチキャストアドレスグループをカプセル化する単一のトンネル。
The number of multicast groups per tunnel MUST be the same when the DUT/SUT is configured in a multiple tunnel configuration. All destination test ports MUST join all multicast group addresses offered by the source test port. Each egress interface MUST be configured with the same MTU.
DUT / SUTが複数のトンネル設定で設定されたときにトンネルあたりのマルチキャストグループの数は同じでなければなりません。すべての宛先テスト・ポートは、ソース・テスト・ポートが提供するすべてのマルチキャストグループアドレスに参加する必要があります。各出力インターフェイスは同じMTUを設定する必要があります。
A search algorithm MUST be utilized to determine the decapsulation throughput as defined in [Du98].
探索アルゴリズムは、[Du98]で定義されるようにデカプセル化スループットを決定するために利用されなければなりません。
When making performance comparisons between the encapsulation and decapsulation process of the DUT/SUT, the offered frame sizes SHOULD reflect the encapsulated frame sizes reported in the encapsulation test (See section 4.4.1) in place of those noted in section 3.1.3.
DUT / SUTのカプセル化およびカプセル化解除プロセスの間の性能比較を行う際に、提供されるフレームサイズは、セクション3.1.3で述べたものの代わりに（セクション4.4.1を参照）のカプセル化試験で報告されたカプセル化されたフレームサイズを反映すべきです。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o Originating encapsulation algorithm or format used to tunnel the packets o Originating encapsulated frame size o Number of tunnels o Number of multicast groups per tunnel
トンネルあたりのマルチキャストグループの数oをトンネルのカプセル化されたフレームサイズO番号発信Oトンネルに使用されるカプセル化アルゴリズムまたは形式発信Oマルチキャストグループの総数O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスパケットのO数
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o Measured Decapsulated Throughput as defined in RFC 2432 [Du98] o Decapsulated frame size
RFC 2432で定義されているOデカプセル化フレームサイズO [Du98]デカプセル化スループット測定
The Decapsulated Throughput results SHOULD be reported in the format of a table and specific to this test there SHOULD be rows for each originating encapsulated frame size. Each row or iteration SHOULD specify the offered load, decapsulated frame size, total number of offered frames and the decapsulation throughput.
デカプセル化スループット結果は、各発信カプセル化されたフレームのサイズの行がなければならないテーブルの形式で報告され、このテストに特異的であるべきです。各行又は反復は提供された負荷、デカプセル化フレームサイズ、提供されるフレームの総数とデカプセル化スループットを特定すべきです。
Objective:
目的：
To determine the maximum rate at which frames of one encapsulated format offered to one ingress interface of a DUT/SUT are converted to another encapsulated format and correctly forwarded by the DUT/SUT on one or more egress interfaces without loss.
別のカプセル化されたフォーマットに変換され、正しく損失せずに、1つのまたは複数の出力インターフェイス上でDUT / SUTによって転送されたDUT / SUTの入力インターフェイスに提供1つのカプセル化フォーマットのフレームを最大速度を決定します。
Procedure:
手順：
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +---------+ +---------+
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
| |-(Tunnel)->|Ingress | | |
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
+---------+ +---------+ +---------+
Figure 5
図5
Figure 5 shows the setup for testing the Re-encapsulation throughput of the DUT/SUT. The source test port will offer encapsulated traffic of one type to the DUT/SUT, which has been configured to re-encapsulate the offered frames using a different encapsulation format. The DUT/SUT will then forward the re-encapsulated frames to the destination test port(s).
図5は、DUT / SUTの再カプセル化スループットをテストするためのセットアップを示します。ソース・テスト・ポートは、異なるカプセル化フォーマットを使用して提供されるフレームを再カプセル化するように構成されたDUT / SUT、1つのタイプのトラフィックをカプセル化提供します。 DUT / SUTは、宛先テストポート（単数または複数）に再カプセル化されたフレームを転送します。
The DUT/SUT SHOULD be configured such that the traffic across the ingress and each egress interface will consist of either:
DUT / SUT入力および各出力インターフェイス上のトラフィックのいずれかで構成するように構成されるべきです。
a) A single tunnel encapsulating one or more multicast address groups OR b) Multiple tunnels, each encapsulating one or more multicast address groups.
a）1種または複数のマルチキャストアドレスグループまたはb）複数のトンネル、各封入1つまたは複数のマルチキャストアドレスグループをカプセル化する単一のトンネル。
The number of multicast groups per tunnel MUST be the same when the DUT/SUT is configured in a multiple tunnel configuration. In addition, the DUT/SUT SHOULD be configured such that the number of tunnels on the ingress and each egress interface are the same. All destination test ports MUST join all multicast group addresses offered by the source test port. Each egress interface MUST be configured with the same MTU.
DUT / SUTが複数のトンネル設定で設定されたときにトンネルあたりのマルチキャストグループの数は同じでなければなりません。加えて、DUT / SUTは、入力上のトンネルの数と、各出力インターフェイスが同じであるように構成されるべきです。すべての宛先テスト・ポートは、ソース・テスト・ポートが提供するすべてのマルチキャストグループアドレスに参加する必要があります。各出力インターフェイスは同じMTUを設定する必要があります。
Note that when offering large frames sizes, the encapsulation process may require the DUT/SUT to fragment the IP datagrams prior to being forwarded on the egress interface. It is RECOMMENDED to limit the offered frame sizes, such that no fragmentation is required by the DUT/SUT.
大きなフレームサイズを提供する場合、カプセル化プロセスの前出力インターフェイス上で転送されることにIPデータグラムを断片化するDUT / SUTを必要とし得ることに留意されたいです。全くフラグメンテーションがDUT / SUTによって必要とされないように、提供されるフレームサイズを制限することが推奨されます。
A search algorithm MUST be utilized to determine the re-encapsulation throughput as defined in [Du98].
【Du98]で定義されるように探索アルゴリズムは、再カプセル化スループットを決定するために利用されなければなりません。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o MTU size of DUT/SUT interfaces o Originating encapsulation algorithm or format used to tunnel the packets o Re-encapsulation algorithm or format used to tunnel the packets o Originating encapsulated frame size o Number of tunnels per interface o Number of multicast groups per tunnel
Oトンネルに使用されるカプセル化アルゴリズムまたは形式発信O DUT / SUTインターフェースのMTUサイズOマルチキャストグループの総数O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数Reカプセル化アルゴリズムまたは形式Oのパケットが使用されますトンネルあたりのマルチキャストグループの数Oインターフェイスあたりトンネルのカプセル化されたフレームサイズO番号発信Oトンネルにパケット
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o Measured Re-encapsulated Throughput as defined in RFC 2432 [Du98] o Re-encapsulated frame size
RFC 2432で定義されているOの再カプセル化されたフレームのサイズO [Du98]再カプセル化されたスループット測定
The Re-encapsulated Throughput results SHOULD be reported in the format of a table and specific to this test there SHOULD be rows for each originating encapsulated frame size. Each row or iteration SHOULD specify the offered load, Re-encapsulated frame size, total number of offered frames, and the Re-encapsulated Throughput.
再カプセル化されたスループットの結果は、各発信カプセル化されたフレームのサイズの行がなければならないテーブルの形式で報告され、このテストに特異的であるべきです。各行又は反復は提供された負荷、再カプセル化されたフレームのサイズ、提供されるフレームの総数、および再カプセル化されたスループットを特定すべきです。
This section presents methodologies relating to the characterization of the forwarding latency of a DUT/SUT in a multicast environment. It extends the concept of latency characterization presented in RFC 2544.
このセクションでは、マルチキャスト環境でDUT / SUTの転送遅延時間の特性評価に関する方法論を提示します。これは、RFC 2544で提示の待ち時間特性の概念を拡張します。
The offered load accompanying the latency-measured packet can affect the DUT/SUT packet buffering, which may subsequently impact measured packet latency. This SHOULD be a consideration when selecting the intended load for the described methodologies below.
レイテンシ測定パケットを伴う提供された負荷は、その後、測定パケット遅延に影響を与える可能性がDUT / SUTパケットバッファリングに影響を与えることができます。以下で説明する方法論のために意図した負荷を選択するとき、これは考慮する必要があります。
RFC 1242 and RFC 2544 draw a distinction between device types: "store and forward" and "bit-forwarding." Each type impacts how latency is collected and subsequently presented. See the related RFCs for more information.
「ビット転送」を「ストア・アンド・フォワード」と：RFC 1242及びRFC 2544は、デバイスタイプとの間の区別を描きます待ち時間が収集され、その後に提示される方法各タイプの影響。詳細については、関連するRFCを参照してください。
Objective:
目的：
To produce a set of multicast latency measurements from a single, multicast ingress interface of a DUT/SUT through multiple, egress multicast interfaces of that same DUT/SUT as provided for by the metric "Multicast Latency" in RFC 2432 [Du98].
RFC 2432 [Du98]にメトリック「マルチキャストLatency」でのために提供されるものと同じDUT / SUTの複数のイグレスマルチキャスト・インターフェースを介してDUT / SUTの単一、マルチキャスト入力インターフェイスからマルチキャストレイテンシ測定値のセットを生成します。
The procedures below draw from the collection methodology for latency in RFC 2544 [Br96]. The methodology addresses two topological scenarios: one for a single device (DUT) characterization; a second scenario is presented or multiple device (SUT) characterization.
RFC 2544での待ち時間の収集方法論から引き分け以下の手順[BR96]。方法は、二つのトポロジカルなシナリオに対処：単一のデバイス（DUT）の特徴付けのための1つを、第2のシナリオは、提示され、または複数のデバイス（SUT）の特徴付けされています。
Procedure:
手順：
If the test trial is to characterize latency across a single Device Under Test (DUT), an example test topology might take the form of Figure 1 in section 3. That is, a single DUT with one ingress interface receiving the multicast test traffic from frame-transmitting component of the test apparatus and n egress interfaces on the same DUT forwarding the multicast test traffic back to the frame-receiving component of the test apparatus. Note that n reflects the number of TESTED egress interfaces on the DUT actually expected to forward the test traffic (as opposed to configured but untested, non-forwarding interfaces, for example).
試験試験は、テスト（DUT）の下では、単一のデバイスにかかる待ち時間を特徴付けることである場合、例えば、テスト・トポロジーはセクション3において、図1の形態、フレームからマルチキャストテストトラフィックを受信する1つの入力インターフェイスを有する単一のDUTがかかる場合がありますバック試験装置のフレーム受信コンポーネントへマルチキャストテストトラフィックを転送同じDUTに試験装置の構成要素とn出力インターフェイスを-transmitting。なお、nは実際に（例えば、構成が、テストされていない、非転送インタフェースとは対照的に）テストトラフィックを転送することが期待DUTでテスト出力インターフェイスの数を反映します。
If the multicast latencies are to be taken across multiple devices forming a System Under Test (SUT), an example test topology might take the form of Figure 2 in section 3.
マルチキャスト待ち時間がテスト対象システム（SUT）を形成する複数のデバイス間で解釈されるべきである場合、例えば、テスト・トポロジは、セクション3に、図2の形を取るかもしれません。
The trial duration SHOULD be 120 seconds to be consistent with RFC 2544 [Br96]. The nature of the latency measurement, "store and forward" or "bit forwarding", MUST be associated with the related test trial(s) and disclosed in the results report.
試験期間は、RFC 2544 [BR96]と一致するように120秒であるべきです。レイテンシ測定、「ストアアンドフォワード」または「ビット転送」の性質は、関連試験試験（複数可）に関連し、結果報告書に開示されなければなりません。
A test traffic stream is presented to the DUT. It is RECOMMENDED to offer traffic at the measured aggregated multicast throughput rate (Section 4.3). At the mid-point of the trial's duration, the test apparatus MUST inject a uniquely identifiable ("tagged") frame into the test traffic frames being presented. This tagged frame will be the basis for the latency measurements. By "uniquely identifiable", it is meant that the test apparatus MUST be able to discern the "tagged" frame from the other frames comprising the test traffic set. A frame generation timestamp, Timestamp A, reflecting the completion of the transmission of the tagged frame by the test apparatus, MUST be determined.
テストトラフィックストリームがDUTに提示されます。測定された集約マルチキャストのスループット・レート（4.3節）でトラフィックを提供することをお勧めします。試験の期間の中間時点で、試験装置は、提示されたテストトラフィックフレームに一意に識別（「タグ付け」）フレームを注入しなければなりません。このタグ付けされたフレームは、待ち時間測定の基礎となります。 「一意に識別可能な」とは、試験装置は、テストトラフィックのセットを含む他のフレームから「タグ付け」フレームを識別できなければならないことを意味します。フレーム生成タイムスタンプ、タイムスタンプAは、試験装置によってタグ付けされたフレームの送信が完了したことを反映し、決定されなければなりません。
The test apparatus will monitor frames from the DUT's tested egress interface(s) for the expected tagged frame(s) and MUST record the time of the successful detection of a tagged frame from a tested egress interface with a timestamp, Timestamp B. A set of Timestamp B values MUST be collected for all tested egress interfaces of the DUT/SUT. See RFC 1242 [Br91] for additional discussion regarding store and forward devices and bit forwarding devices.
試験装置は、予想されるタグ付きフレーム（単数または複数）のためのDUTの試験された出力インターフェイス（複数可）からのフレームを監視し、タイムスタンプを用いて試験イグレスインタフェースからタグ付けされたフレームの成功した検出の時間を記録する必要があり、タイムスタンプB.セットタイムスタンプB値のDUT / SUTの全ての試験された出力インターフェイスのために収集されなければなりません。ストアアンドフォワードデバイスとビット転送装置に関するさらなる議論については、RFC 1242 [Br91]を参照。
A trial MUST be considered INVALID should any of the following conditions occur in the collection of the trial data:
次のいずれかの条件が試験データの収集に発生した裁判は無効であると見なさなければなりません：
o Unexpected differences between Intended Load and Offered Load or unexpected differences between Offered Load and the resulting Forwarding Rate(s) on the DUT/SUT egress ports. o Forwarded test frames improperly formed or frame header fields improperly manipulated. o Failure to forward required tagged frame(s) on all expected egress interfaces. o Reception of tagged frames by the test apparatus more than 5 seconds after the cessation of test traffic by the source test port.
対象ロードおよび提供された負荷またはDUT / SUTの出口ポートに提供された負荷と、得られた転送レート（S）との間の予想外の差のO予期違い。 O不適切に形成されたテストフレームまたは不適切な操作フレームヘッダフィールドを転送しました。 O障害は、すべての期待される出力インターフェイスにタグ付けされたフレーム（複数可）を必要と転送します。試験装置によってタグ付けされたフレームの受信Oソーステストポートによるテストトラフィックの停止後5秒以上。
The set of latency measurements, M, composed from each latency measurement taken from every ingress/tested egress interface pairing MUST be determined from a valid test trial:
すべての入口から採取した各レイテンシ測定からなるレイテンシ測定値の集合、Mは、/出力インターフェイスのペアが有効な試験試験から決定されなければならない試験しました。
M = { (Timestamp B(E0) - Timestamp A), (Timestamp B(E1) - Timestamp A), ... (Timestamp B(En) - Timestamp A) }
M = {（タイムスタンプB（E0） - タイムスタンプA）、（タイムスタンプB（E1） - タイムスタンプA）、...（タイムスタンプB（JA） - タイムスタンプA）}
where (E0 ... En) represents the range of all tested egress interfaces and Timestamp B represents a tagged frame detection event for a given DUT/SUT tested egress interface.
（E0 ... Enが）すべての試験された出力インターフェイスの範囲を表し、タイムスタンプBは、所与のDUTのためにタグ付けされたフレーム検出イベントを表し/ SUTは、出力インターフェイスを試験しました。
A more continuous profile MAY be built from a series of individual measurements.
より連続的なプロファイルは、個々の一連の測定値から構築することができます。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Offered load o Total number of multicast groups
マルチキャストグループの総数O提供された負荷O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The set of all latencies with respective time units related to the tested ingress and each tested egress DUT/SUT interface.
試験された入力および各試験出口DUT / SUTのインタフェースに関連するそれぞれの時間単位を有する全ての待ち時間の組O。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
提示待ち時間の時間単位は均一でなければならないし、媒体または媒体のために十分な精度で試験されます。
The results MAY be offered in a tabular format and should preserve the relationship of latency to ingress/egress interface for each multicast group to assist in trending across multiple trials.
結果は、表形式で提供されてもよく、複数の試験を横切ってトレンドを支援するために、各マルチキャストグループ用/出力インターフェイスを進入する待ち時間の関係を保つべきです。
Objective:
目的：
To determine the difference between the maximum latency measurement and the minimum latency measurement from a collected set of latencies produced by the Multicast Latency benchmark.
マルチキャストレイテンシベンチマークによって生成されるレイテンシの収集セットから最大待ち時間測定及び最小待ち時間測定値との差を決定します。
Procedure:
手順：
Collect a set of multicast latency measurements over a single test duration, as prescribed in section 5.1. This will produce a set of multicast latencies, M, where M is composed of individual forwarding latencies between DUT frame ingress and DUT frame egress port pairs. E.g.:
セクション5.1に規定され、単一の試験期間にわたってマルチキャストレイテンシ測定値のセットを収集します。これは、Mは、DUTのフレームの入力およびDUTフレーム出口ポートのペア間の個々の転送待ち時間で構成されているマルチキャスト待ち時間、M、の組を生成します。例えば。：
M = {L(I,E1),L(I,E2), ..., L(I,En)}
M = {L（I E1）、L（E、E2）、...、L（および）}
where L is the latency between a tested ingress interface, I, of the DUT, and Ex a specific, tested multicast egress interface of the DUT. E1 through En are unique egress interfaces on the DUT.
ここで、Lは、試験された入力インターフェイス、I、DUTの、および実施例DUTの特定、試験マルチキャストイグレスインタフェース間の待ち時間です。エン通じE1は、DUT上の固有の出力インターフェイスです。
From the collected multicast latency measurements in set M, identify MAX(M), where MAX is a function that yields the largest latency value from set M.
集合Mに収集マルチキャストレイテンシ測定値から、MAXセットM.から最大レイテンシ値を与える関数であるMAX（M）を、特定
Identify MIN(M), when MIN is a function that yields the smallest latency value from set M.
MINが設定M.から最小レイテンシ値を与える関数である場合、MIN（M）を識別
The Max/Min value is determined from the following formula:
最大/最小値は、次式から決定されます。
Result = MAX(M) - MIN(M)
結果= MAX（M） - MIN（M）
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Offered load o Total number of multicast groups
マルチキャストグループの総数O提供された負荷O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The Max/Min value
最大/最小値O
The following results SHOULD be reflected in the test report:
以下の結果は、試験報告書に反映されるべきです：
o The set of all latencies with respective time units related to the tested ingress and each tested egress DUT/SUT interface.
試験された入力および各試験出口DUT / SUTのインタフェースに関連するそれぞれの時間単位を有する全ての待ち時間の組O。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
提示待ち時間の時間単位は均一でなければならないし、媒体または媒体のために十分な精度で試験されます。
The results MAY be offered in a tabular format and should preserve the relationship of latency to ingress/egress interface for each multicast group.
結果は、表形式で提供されてもよく、各マルチキャストグループ用/出力インターフェイスを進入する待ち時間の関係を保つべきです。
This section presents methodology relating to the characterization of the overhead delays associated with explicit operations found in multicast environments.
このセクションでは、マルチキャスト環境で見つかった明示的な操作に伴うオーバーヘッド遅延の特性評価に関する方法論を提示します。
Objective:
目的：
To determine the time duration it takes a DUT/SUT to start forwarding multicast frames from the time a successful IGMP group membership report has been issued to the DUT/SUT.
継続時間を決定するためには、成功したIGMPグループメンバーシップレポートは、DUT / SUTに発行された時点からのマルチキャストフレームの転送を開始するためにDUT / SUTをとります。
Procedure:
手順：
The Multicast Group Join Delay measurement may be influenced by the state of the Multicast Forwarding Database <MFDB> of the DUT/SUT. The states of the MFDB may be described as follows:
マルチキャストグループに参加遅延測定は、DUT / SUTのマルチキャスト転送データベース<MFDB>の状態によって影響され得ます。次のようにMFDBの状態を記述することができます。
o State 0, where the MFDB does not contain the specified multicast group address. In this state, the delay measurement includes the time the DUT/SUT requires to add the address to the MFDB and begin forwarding. Delay measured from State 0 provides information about how the DUT/SUT is able to add new addresses into MFDB.
MFDBは、指定されたマルチキャストグループアドレスが含まれていないO状態0、。この状態では、遅延測定は、DUT / SUTがMFDBにアドレスを追加し、転送を開始するために必要な時間を含みます。状態0から測定された遅延は、DUT / SUTがMFDBに新しいアドレスを追加することができます方法に関する情報を提供します。
o State 1, where the MFDB does contain the specified multicast group address. In this state, the delay measurement includes the time the DUT/SUT requires to update the MFDB with the newly joined node<s> and begin forwarding to the new node<s> plus packet replication time. Delay measured from State 1 provides information about how well the DUT/SUT is able to update the MFDB for new nodes while transmitting packets to other nodes for the same IP multicast address. Examples include adding a new user to an event that is being promoted via multicast packets.
O MFDBがない状態1は、指定されたマルチキャストグループアドレスが含まれています。この状態では、遅延測定は、DUT / SUTが新たに参加したノード<S>とMFDBを更新し、新しいノード<S>プラスパケット複製時間に転送を開始するために必要な時間を含みます。状態1から測定された遅延は、DUT / SUTが同じIPマルチキャストアドレスを他のノードにパケットを送信しながら、新しいノードに対してMFDBを更新することができ、どれだけの情報を提供します。例としては、マルチキャストパケットを介して推進されているイベントに新しいユーザを追加することが挙げられます。
The methodology for the Multicast Group Join Delay measurement provides two alternate methods, based on the state of the MFDB, to measure the delay metric. The methods MAY be used independently or in conjunction to provide meaningful insight into the DUT/SUT ability to manage the MFDB.
マルチキャストグループの方法は、遅延測定に参加メトリック遅延を測定するために、MFDBの状態に基づいて、2つの代替方法を提供します。方法はMFDBを管理するためのDUT / SUT能力に意味のある洞察を提供するために、単独で、または組み合わせて使用することができます。
Users MAY elect to use either method to determine the Multicast Group Join Delay; however the collection method MUST be specified as part of the reporting format.
ユーザーは、マルチキャストグループが遅延に参加決定するためのいずれかの方法を使用することを選択するかもしれません。しかし、収集方法は、報告様式の一部として指定する必要があります。
In order to minimize the variation in delay calculations as well as minimize burden on the DUT/SUT, the test SHOULD be performed with one multicast group. In addition, all destination test ports MUST join the specified multicast group offered to the ingress interface of the DUT/SUT.
遅延計算の変動を最小限に抑えるだけでなく、DUT / SUTの負担を最小限にするために、テストは、1つのマルチキャストグループを用いて行われるべきです。加えて、すべての宛先テストポートは、DUT / SUTの入力インターフェイスに提供される指定されたマルチキャストグループに参加しなければなりません。
Method A:
方法A：
Method A assumes that the Multicast Forwarding Database <MFDB> of the DUT/SUT does not contain or has not learned the specified multicast group address; specifically, the MFDB MUST be in State 0. In this scenario, the metric represents the time the DUT/SUT takes to add the multicast address to the MFDB and begin forwarding the multicast packet. Only one ingress and one egress MUST be used to determine this metric.
方法Aは、<MFDB> DUT / SUTのマルチキャスト転送データベースが含まれていない場合、または指定されたマルチキャストグループアドレスを学習していないことを想定しています。具体的には、MFDBこのシナリオでは状態0でなければなりません、メトリックは、DUT / SUTがMFDBにマルチキャストアドレスを追加して、マルチキャストパケットの転送を開始するのにかかる時間を表します。唯一の入口と出口1は、このメトリックを決定するために使用しなければなりません。
Prior to sending any IGMP Group Membership Reports used to calculate the Multicast Group Join Delay, it MUST be verified through externally observable means that the destination test port is not currently a member of the specified multicast group. In addition, it MUST be verified through externally observable means that the MFDB of the DUT/SUT does not contain the specified multicast address.
任意のIGMPグループメンバーシップレポートをマルチキャストグループが遅延に参加計算するために使用される送信する前に、それは先のテスト・ポートが現在指定されたマルチキャストグループのメンバーではないことを外部から観察可能な手段を通じて検証されなければなりません。また、外部から観察可能なを通じて検証されなければならないDUT / SUTのMFDBは、指定されたマルチキャストアドレスが含まれていないことを意味します。
Method B:
方法B：
Method B assumes that the MFDB of the DUT/SUT does contain the specified multicast group address; specifically, the MFDB MUST be in State 1. In this scenario, the metric represents the time the DUT/SUT takes to update the MFDB with the additional nodes and their corresponding interfaces and to begin forwarding the multicast packet. One or more egress ports MAY be used to determine this metric.
方法Bは、DUT / SUTのMFDBは、指定されたマルチキャストグループアドレスを含んでいないことを前提とし、具体的には、MFDBこのシナリオでは状態1でなければなりません、メトリックは、DUT / SUTの追加のノードおよびそれらの対応するインターフェースとMFDBを更新し、マルチキャストパケットの転送を開始するのにかかる時間を表します。一つ以上の出力ポートは、このメトリックを決定するために使用されるかもしれません。
Prior to sending any IGMP Group Membership Reports used to calculate the Group Join Delay, it MUST be verified through externally observable means that the MFDB contains the specified multicast group address. A single un-instrumented test port MUST be used to join the specified multicast group address prior to sending any test traffic. This port will be used only for insuring that the MFDB has been populated with the specified multicast group address and can successfully forward traffic to the un-instrumented port.
任意のIGMPグループメンバーシップレポートを送信する前には、グループが遅延に参加計算するために使用し、それが外部から観察可能なを通じて検証されなければならないMFDBは、指定されたマルチキャストグループアドレスが含まれていることを意味します。単一の未計測のテストポートは、従来の任意のテストトラフィックの送信に指定されたマルチキャストグループアドレスに参加するために使用されなければなりません。このポートは、唯一MFDBは、指定されたマルチキャストグループアドレスが取り込まれ、正常にトラフィックを転送非インストルメントポートにすることができますされていることを保証するために使用されます。
Join Delay Calculation
遅延計算に参加
Once verification is complete, multicast traffic for the specified multicast group address MUST be offered to the ingress interface prior to the DUT/SUT receiving any IGMP Group Membership Report messages. It is RECOMMENDED to offer traffic at the measured aggregated multicast throughput rate (Section 4.3).
検証が完了すると、指定されたマルチキャストグループアドレスのマルチキャストトラフィックはすべてのIGMPグループメンバーシップレポートメッセージを受信したDUT / SUTに先立って入力インターフェイスに提供されなければなりません。測定された集約マルチキャストのスループット・レート（4.3節）でトラフィックを提供することをお勧めします。
After the multicast traffic has been started, the destination test port (See Figure 1) MUST send one IGMP Group Membership Report for the specified multicast group.
マルチキャストトラフィックが開始された後、先のテスト・ポートは、指定されたマルチキャストグループに対して1 IGMPグループメンバーシップレポートを送らなければなりません（図1参照します）。
The join delay is the difference in time from when the IGMP Group Membership message is sent (timestamp A) and the first frame of the multicast group is forwarded to a receiving egress interface (timestamp B).
参加遅延は、IGMPグループメンバーシップメッセージが（タイムスタンプA）送信され、マルチキャストグループの最初のフレームが受信出力インターフェイス（タイムスタンプB）に転送されたときからの時間の差です。
Group Join delay time = timestamp B - timestamp A
タイムスタンプA - グループでは、遅延時間=タイムスタンプBに参加します
Timestamp A MUST be the time the last bit of the IGMP group membership report is sent from the destination test port; timestamp B MUST be the time the first bit of the first valid multicast frame is forwarded on the egress interface of the DUT/SUT.
タイムスタンプAは、IGMPグループメンバシップレポートの最後のビットが宛先テストポートから送信された時刻でなければなりません。タイムスタンプBは、最初の有効なマルチキャストフレームの最初のビットは、DUT / SUTの出力インターフェイス上で転送される時間でなければなりません。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Total number of multicast groups o Offered load to ingress interface o Method used to measure the join delay metric
提供された負荷Oマルチキャストグループの総数O IGMPバージョンO DUT / SUTでテスト出力インターフェイスの数O Oフレームサイズ（S）入力インターフェイスのメソッドは、メトリック参加遅延を測定するために用いられますo-
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The group join delay time in microseconds per egress interface(s)
O群イグレスインタフェース当たりのマイクロ秒の遅延時間（秒）に参加
The Group Join Delay results for each test MAY be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration MAY specify the group join delay time per egress interface for that iteration.
各試験のグループ参加遅延結果をセクション3.1.3に推奨に従って試験されたフレームサイズのそれぞれの行と、表の形で報告することができます。各行または反復は、その反復のためイグレスインタフェース当たりの遅延時間を参加グループを指定するかもしれません。
Objective:
目的：
To determine the time duration it takes a DUT/SUT to cease forwarding multicast frames after a corresponding IGMP Leave Group message has been successfully offered to the DUT/SUT.
継続時間を決定するためには、対応するIGMP Leave Groupメッセージが正常にDUT / SUTに提供された後にマルチキャストフレームを転送中止するDUT / SUTをとります。
Procedure:
手順：
In order to minimize the variation in delay calculations as well as minimize burden on the DUT/SUT, the test SHOULD be performed with one multicast group. In addition, all destination test ports MUST join the specified multicast group offered to the ingress interface of the DUT/SUT.
遅延計算の変動を最小限に抑えるだけでなく、DUT / SUTの負担を最小限にするために、テストは、1つのマルチキャストグループを用いて行われるべきです。加えて、すべての宛先テストポートは、DUT / SUTの入力インターフェイスに提供される指定されたマルチキャストグループに参加しなければなりません。
Prior to sending any IGMP Leave Group messages used to calculate the group leave delay, it MUST be verified through externally observable means that the destination test ports are currently members of the specified multicast group. If any of the egress interfaces do not forward validation multicast frames then the test is invalid.
グループ離脱遅延を計算するために使用される任意のIGMPのLeave Groupメッセージを送信する前に、先のテスト・ポートは、現在指定されたマルチキャストグループのメンバーであることを外部から観察可能な手段を通じて検証されなければなりません。出力インターフェイスのいずれかが検証マルチキャストフレームを転送しない場合、テストは無効です。
Once verification is complete, multicast traffic for the specified multicast group address MUST be offered to the ingress interface prior to receipt or processing of any IGMP Leave Group messages. It is RECOMMENDED to offer traffic at the measured aggregated multicast throughput rate (Section 4.3).
検証が完了すると、指定されたマルチキャストグループアドレスのマルチキャストトラフィックは、すべてのIGMPリーブグループメッセージの受信または処理の前に入力インターフェイスに提供されなければなりません。測定された集約マルチキャストのスループット・レート（4.3節）でトラフィックを提供することをお勧めします。
After the multicast traffic has been started, each destination test port (See Figure 1) MUST send one IGMP Leave Group message for the specified multicast group.
マルチキャストトラフィックが開始された後、各宛先テスト・ポートは、（図1を参照）指定されたマルチキャストグループの1つのIGMP Leave Groupメッセージを送らなければなりません。
The leave delay is the difference in time from when the IGMP Leave Group message is sent (timestamp A) and the last frame of the multicast group is forwarded to a receiving egress interface (timestamp B).
脱退遅延は、IGMP Leave Groupメッセージを（タイムスタンプA）送信され、マルチキャストグループの最後のフレームを受信し、出力インターフェイス（タイムスタンプB）に転送されたときからの時間の差です。
Group Leave delay time = timestamp B - timestamp A
グループ離脱遅延時間=タイムスタンプB - タイムスタンプA
Timestamp A MUST be the time the last bit of the IGMP Leave Group message is sent from the destination test port; timestamp B MUST be the time the last bit of the last valid multicast frame is forwarded on the egress interface of the DUT/SUT.
タイムスタンプAはIGMP Leave Groupメッセージの最後のビットが宛先テストポートから送信された時刻でなければなりません。タイムスタンプBは、最後の有効なマルチキャストフレームの最後のビットがDUT / SUTの出力インターフェイス上で転送される時間でなければなりません。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Total number of multicast groups o Offered load to ingress interface
提供された負荷Oマルチキャストグループの総数O IGMPバージョンO DUT / SUTでテスト出力インターフェイスの数O Oフレームサイズ（S）入力インターフェイスに
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The group leave delay time in microseconds per egress interface(s)
出力インターフェイス当たりのマイクロ秒のグループ脱退遅延時間（秒）O
The Group Leave Delay results for each test MAY be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration MAY specify the group leave delay time per egress interface for that iteration.
各試験のグループ脱退遅延結果をセクション3.1.3に推奨に従って試験されたフレームサイズのそれぞれの行と、表の形で報告することができます。各行または反復は、その反復のための出力インターフェイスごとにグループ脱退遅延時間を指定してもよいです。
This section offers a procedure relating to the identification of multicast group limits of a DUT/SUT.
このセクションでは、DUT / SUTのマルチキャストグループの制限の同定に関する手順を提供します。
Objective:
目的：
To determine the maximum number of multicast groups a DUT/SUT can support while maintaining the ability to forward multicast frames to all multicast groups registered to that DUT/SUT.
そのDUT / SUTに登録されているすべてのマルチキャストグループにマルチキャストフレームを転送する能力を維持しながら、DUT / SUTがサポートできるマルチキャストグループの最大数を決定します。
Procedure:
手順：
One or more destination test ports of DUT/SUT will join an initial number of multicast groups.
DUT / SUTのテストポートがマルチキャストグループの初期数に参加する1つまたは複数の宛先。
After a minimum delay as measured by section 6.1, the source test ports MUST transmit to each group at a specified offered load.
セクション6.1により測定される最小の遅延の後、ソース・テスト・ポートは、指定された提供された負荷に各グループに送信しなければなりません。
If at least one frame for each multicast group is forwarded properly by the DUT/SUT on each participating egress interface, the iteration is said to pass at the current capacity.
各マルチキャストグループのための少なくとも一つのフレームが各参加出力インターフェイス上のDUT / SUTによって適切に転送される場合、反復は電流容量で通過すると言われています。
For each successful iteration, each destination test port will join an additional user-defined number of multicast groups and the test repeats. The test stops iterating when one or more of the egress interfaces fails to forward traffic on one or more of the configured multicast groups.
各成功した反復のために、各宛先テストポートがマルチキャストグループとテストリピートの付加的なユーザ定義の数に参加します。出力インターフェイスの1つまたは複数が設定されたマルチキャストグループの一つ以上のトラフィックの転送に失敗した場合、試験は、反復を停止します。
Once the iteration fails, the last successful iteration is the stated Maximum Group Capacity result.
反復が失敗したら、最後に成功した反復が規定の最大グループ容量の結果です。
Reporting Format:
報告フォーマット：
The following configuration parameters MUST be reflected in the test report:
次の設定パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Offered load
提供された負荷O IGMPバージョンO DUT / SUTでテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The total number of multicast group addresses that were successfully forwarded through the DUT/SUT
正常DUT / SUTを介して転送されたマルチキャストグループアドレスの総数O
The Multicast Group Capacity results for each test SHOULD be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration SHOULD specify the number of multicast groups joined per destination interface, number of frames transmitted and number of frames received for that iteration.
各試験のためにマルチキャストグループ容量の結果は、セクション3.1.3の推奨事項に従って試験フレームサイズのそれぞれの行と、表の形で報告されるべきです。各行または反復は、マルチキャストグループの数は、宛先インタフェース、送信されたフレームの数と、その繰り返しのために受信されたフレーム数ごとに接合特定すべきです。
Network forwarding devices are generally required to provide more functionality than just the forwarding of traffic. Moreover, network-forwarding devices may be asked to provide those functions in a variety of environments. This section offers procedures to assist in the characterization of DUT/SUT behavior in consideration of potentially interacting factors.
ネットワーク転送デバイスは、一般的にトラフィックの転送だけでより多くの機能を提供するために必要とされます。また、ネットワーク中継装置は、さまざまな環境でこれらの機能を提供するように求めてもよいです。このセクションでは、潜在的に相互作用の要因を考慮して、DUT / SUTの振る舞いの特性を支援するために手順を提供しています。
Objective:
目的：
To produce a set of multicast latency measurements from a single multicast ingress interface of a DUT/SUT through multiple egress multicast interfaces of that same DUT/SUT as provided for by the metric "Multicast Latency" in RFC 2432 [Du98] while forwarding meshed unicast traffic.
RFC 2432 [Du98】転送が噛合しながらユニキャストでメトリック「マルチキャストLatency」でのために提供されるものと同じDUT / SUTの複数の出口マルチキャストインタフェースを介してDUT / SUTの単一マルチキャスト入力インターフェイスからマルチキャストレイテンシ測定値のセットを生成しますトラフィック。
Procedure:
手順：
The Multicast Latency metrics can be influenced by forcing the DUT/SUT to perform extra processing of packets while multicast class traffic is being forwarded for latency measurements.
マルチキャスト遅延メトリックは、マルチキャストクラストラフィックがレイテンシ測定のために転送されている間にパケットの余分な処理を実行するためにDUT / SUTを強制することによって影響を与えることができます。
The Burdened Forwarding Multicast Latency test MUST follow the described setup for the Multicast Latency test in Section 5.1. In addition, another set of test ports MUST be used to burden the DUT/SUT (burdening ports). The burdening ports will be used to transmit unicast class traffic to the DUT/SUT in a fully meshed traffic distribution as described in RFC 2285 [Ma98]. The DUT/SUT MUST learn the appropriate unicast addresses and verified through some externally observable method.
背負っフォワーディングマルチキャスト遅延テストは、5.1節でのマルチキャスト遅延テストのために説明したセットアップに従わなければなりません。また、テストポートの別のセットは、（ポートに負担をかける）DUT / SUT負荷に使用されなければなりません。 RFC 2285に記載されているように負担ポートは[MA98]フルメッシュトラフィック分布にDUT / SUTにユニキャストクラスのトラフィックを送信するために使用されるであろう。 DUT / SUTは、適切なユニキャストアドレスを学習し、いくつかの外部から観察可能な方法で検証しなければなりません。
Perform a baseline measurement of Multicast Latency as described in Section 5.1. After the baseline measurement is obtained, start transmitting the unicast class traffic at a user-specified offered load on the set of burdening ports and rerun the Multicast Latency test. The offered load to the ingress port MUST be the same as was used in the baseline measurement.
セクション5.1で説明したように、マルチキャストレイテンシのベースライン測定を行います。ベースライン測定が得られた後、負担ポートのセットにユーザ指定提供された負荷にユニキャストクラスのトラフィックの送信を開始し、マルチキャスト遅延テストを再実行します。入口ポートに提供される負荷は、ベースラインの測定に用いたと同じでなければなりません。
Reporting Format:
報告フォーマット：
Similar to Section 5.1, the following configuration parameters MUST be reflected in the test report:
5.1節と同様に、次の構成パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Offered load to ingress interface o Total number of multicast groups o Offered load to burdening ports o Total number of burdening ports
負担ポートの総数Oポートを負担することを申し出負荷Oマルチキャストグループの総数O入力インターフェイスに提供された負荷O IGMPバージョンO DUT / SUT Oテスト時間でテスト出力インターフェイスの数O Oフレームサイズ（S）
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The set of all latencies related to the tested ingress and each tested egress DUT/SUT interface for both the baseline and burdened response.
O試験入力に関連するすべての待ち時間のセットとベースラインと負担応答の両方のために、各試験出力DUT / SUTインタフェース。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
提示待ち時間の時間単位は均一でなければならないし、媒体または媒体のために十分な精度で試験されます。
The latency results for each test SHOULD be reported in the form of a table, with a row for each of the tested frame sizes per the recommended frame sizes in section 3.1.3, and SHOULD preserve the relationship of latency to ingress/egress interface(s) to assist in trending across multiple trials.
各試験の待ち時間の結果はセクション3.1.3で推奨フレームサイズごとに試験したフレームサイズのそれぞれの行と、表の形で報告されるべきであり、入力/出力インターフェイス（に待ち時間の関係を維持するべきです複数の試行間でトレンドを支援するために秒）。
Objective:
目的：
To determine the time duration it takes a DUT/SUT to start forwarding multicast frames from the time a successful IGMP Group Membership Report has been issued to the DUT/SUT while forwarding meshed unicast traffic.
継続時間を決定するためには、メッシュ型ユニキャストトラフィックを転送しながら、成功したIGMPグループメンバーシップレポートは、DUT / SUTに発行された時点からのマルチキャストフレームの転送を開始するためにDUT / SUTをとります。
Procedure:
手順：
The Forwarding Burdened Group Join Delay test MUST follow the described setup for the Group Join Delay test in Section 6.1. In addition, another set of test ports MUST be used to burden the DUT/SUT (burdening ports). The burdening ports will be used to transmit unicast class traffic to the DUT/SUT in a fully meshed traffic pattern as described in RFC 2285 [Ma98]. The DUT/SUT MUST learn the appropriate unicast addresses and verified through some externally observable method.
グループは、遅延テストに参加負担フォワーディングは、6.1節でグループ参加遅延テストのために説明した設定に従わなければなりません。また、テストポートの別のセットは、（ポートに負担をかける）DUT / SUT負荷に使用されなければなりません。負担ポートは[MA98] RFC 2285に記載されているようにフルメッシュトラフィックパターンにおいてDUT / SUTにユニキャストクラスのトラフィックを送信するために使用されるであろう。 DUT / SUTは、適切なユニキャストアドレスを学習し、いくつかの外部から観察可能な方法で検証しなければなりません。
Perform a baseline measurement of Group Join Delay as described in Section 6.1. After the baseline measurement is obtained, start transmitting the unicast class traffic at a user-specified offered load on the set of burdening ports and rerun the Group Join Delay test. The offered load to the ingress port MUST be the same as was used in the baseline measurement.
グループのベースライン測定を行い、セクション6.1で説明したように遅延に参加。ベースライン測定が得られた後、負担ポートのセットにユーザ指定提供された負荷にユニキャストクラスのトラフィックの送信を開始し、グループは、遅延テストに参加再実行。入口ポートに提供される負荷は、ベースラインの測定に用いたと同じでなければなりません。
Reporting Format:
報告フォーマット：
Similar to Section 6.1, the following configuration parameters MUST be reflected in the test report:
第6.1節と同様に、次の構成パラメータは、試験報告書に反映されなければなりません。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Offered load to ingress interface o Total number of multicast groups o Offered load to burdening ports o Total number of burdening ports o Method used to measure the join delay metric
方法Oポートに負担をかけるの総数Oポートを負担することを申し出負荷Oマルチキャストグループの総数O入力インターフェイスに提供された負荷O DUT / SUT OのIGMPバージョンでテスト出力インターフェイスの数O Oフレームサイズ（複数可）を測定するために使用しました遅延メトリックに参加
The following results MUST be reflected in the test report:
以下の結果は、試験報告書に反映されなければなりません。
o The group join delay time in microseconds per egress interface(s) for both the baseline and burdened response.
O群のベースラインと負担応答の両方のための出力インターフェイス（複数可）あたりのマイクロ秒の遅延時間を参加。
The Group Join Delay results for each test MAY be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration MAY specify the group join delay time per egress interface, number of frames transmitted and number of frames received for that iteration.
各試験のグループ参加遅延結果をセクション3.1.3に推奨に従って試験されたフレームサイズのそれぞれの行と、表の形で報告することができます。各行又は反復グループを指定するかもしれ出力インターフェイス当たりの遅延時間を参加、フレームの数は、送信されたフレームの数は、その反復のために受け取りました。
As this document is solely for the purpose of providing metric methodology and describes neither a protocol nor a protocol's implementation, there are no security considerations associated with this document specifically. Results from these methodologies may identify a performance capability or limit of a device or system in a particular test context. However, such results might not be representative of the tested entity in an operational network.
このドキュメントは、メトリックの方法論を提供する目的のためだけで、プロトコルやプロトコルの実装どちらを記述したように、このドキュメントに関連したセキュリティ上の考慮事項は特にありません。これらの方法からの結果は、特定のテストコンテキストでデバイスまたはシステムの性能能力または制限を識別することができます。しかし、このような結果は、運用ネットワークにおいて試験したエンティティの代表ではないかもしれません。
The Benchmarking Methodology Working Group of the IETF and particularly Kevin Dubray, Juniper Networks, are to be thanked for the many suggestions they collectively made to help complete this document.
IETFのベンチマーク手法ワーキンググループ、特にケビンDubray、ジュニパーネットワークスは、彼らは総称して、この文書を完成助けるために作られた多くの提案を感謝すべきです。
The authors would like to acknowledge the following individuals for their help and participation of the compilation of this document: Hardev Soor, Ixia, and Ralph Daniels, Spirent Communications, both who made significant contributions to the earlier versions of this document. In addition, the authors would like to acknowledge the members of the task team who helped bring this document to fruition: Michele Bustos, Tony De La Rosa, David Newman and Jerry Perser.
Hardev SOOR、イクシア、そしてラルフ・ダニエルズ、Spirent社コミュニケーションズ、このドキュメントの以前のバージョンへの重要な貢献をした人の両方：著者は、彼らの助けとこの文書のコンパイルの参加のための以下の個人を確認したいと思います。ミケーレ・ブストス、トニー・デ・ラ・ロサ、デヴィッド・ニューマンとジェリーPerser：また、著者は、結実に、この文書を持って助けたタスクチームのメンバーを確認したいと思います。
[Br91] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[Br91]ブラドナーの、S.、 "ネットワーク相互接続デバイスのためのベンチマーキング用語"、RFC 1242、1991年7月。
[Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[BR96]ブラドナー、S.とJ. McQuaid、RFC 2544、1999年3月 "ベンチマーキング方法論は、ネットワークの相互接続デバイスのため"。
[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement Levels, RFC 2119, March 1997.
[Br97]ブラドナーの、要件レベルを反映するためのRFCでのキーワードのS.「使用、RFC 2119、1997年3月。
[Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[Du98] Dubray、K.、 "IPマルチキャストベンチマーキングのための用語"、RFC 2432、1998年10月。
[IANA1] IANA multicast address assignments, http://www.iana.org/assignments/multicast-addresses
【IANA1] IANAマルチキャストアドレス割り当て、http://www.iana.org/assignments/multicast-addresses
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[MA98]マンデビル、R.、RFC 2285、1998年2月 "LANのためのベンチマーキング用語は、デバイスの切り替え"。
[Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Me98]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[Ca02] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[CA02]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[De89]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Fe97]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
[Hu95]のHuitema、C.、 "インターネットでのルーティング"、プレンティス・ホール、1995。
[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive Corporate Networks", John Wiley & Sons Inc., 1998.
[Ka98] Kosiur、D.、 "IPマルチキャスト：対話型企業ネットワークへの完全なガイド"、ジョン・ワイリー＆サンズ社、1998。
[Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.
[Mt98] Maufer、T.、 "EnterpriseでIPマルチキャストの展開"、プレンティス・ホール、1998。
Debra Stopp Ixia 26601 W. Agoura Rd. Calabasas, CA 91302 USA
デブラSTOPPイクシア26601 W.アゴーラRdを。カラバサス、CA 91302 USA
Phone: + 1 818 871 1800 EMail: debby@ixiacom.com
電話：+ 1 818 871 1800 Eメール：debby@ixiacom.com
Brooks Hickman Spirent Communications 26750 Agoura Rd. Calabasas, CA 91302 USA
ブルックスヒックマンのSpirentコミュニケーションズ26750アゴーラRdを。カラバサス、CA 91302 USA
Phone: + 1 818 676 2412 EMail: brooks.hickman@spirentcom.com
電話：+ 1 818 676 2412 Eメール：brooks.hickman@spirentcom.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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/S HE 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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。