[要約] RFC 3918は、IPマルチキャストに対応したネットワークデバイスのパフォーマンスを客観的に評価するための「ベンチマーキング手法」を定義しています。スループット、遅延、パケット損失率、およびグループへの参加・離脱の応答時間（IGMP/MLD処理能力）を測定するための具体的なテスト構成と手順を規定しています。多様なマルチキャストプロトコルをサポートする機器の性能を一貫した基準で評価・比較可能にし、安定したマルチキャスト網の設計と選定を支援することを目的としています。
Network Working Group D. Stopp
Request for Comments: 3918 Ixia
Category: Informational B. Hickman
Spirent Communications
October 2004
Methodology for IP Multicast Benchmarking
IPマルチキャストベンチマークの方法論
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).
Copyright (C) The Internet Society (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 2544、RFC 2432、および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マルチキャストプロトコルに対応する装置について、スループット、転送、遅延、およびInternet Group Management Protocol (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.
以前の文書「Terminology for IP Multicast Benchmarking」[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およびマルチキャストネットワーキングの詳細については、[Hu95]、[Ka98]、[Mt98]を参照してください。
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」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「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に例示する、イングレスが1つでエグレスが複数あるマルチキャストシナリオを対象とします。イングレスとエグレスが複数あるマルチキャストシナリオの方法論は、この文書の対象範囲外です。
Figure 1 shows a typical setup for an IP multicast test, with one source to multiple destinations.
図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内の1台の装置の単一イングレスインターフェイスに入力します。次に、フレームをSUTのトポロジー内で転送し、最後にSUT内の装置の試験用エグレスインターフェイスから試験装置のフレーム受信部へ転送します。図2にSUTの試験トポロジーの例を示します。SUTを試験する場合、対応する試験結果とともに、試験トポロジーと関連するすべての構成情報を開示しなければなりません (MUST)。
*-----------------------------------------*
| |
+--------+ | +----------------+ | +--------+
| | | +------------+ |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.
通常、宛先側の試験ポートは、IGMP Group ReportメッセージをDUT/SUTに送信し、まず所定数のマルチキャストグループに参加します。すべての宛先側試験ポートが適切なグループに参加したことを確認するため、送信元側試験ポートはそれらのグループ宛てのIPマルチキャストフレームを送信しなければなりません (MUST)。試験の完了後、宛先側試験ポートはIGMP Leave Groupメッセージを送信して、DUT/SUTのIGMPテーブルを消去してもかまいません (MAY)。
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.
さらに、試験装置は、試験に関係するフレームを確実に受信できるよう、試験対象装置が正しく転送していることを検証しなければなりません (MUST)。
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、および測定対象の変数に影響するその他の非必須トラフィックやトラフィック制御機構は無効にしなければなりません (MUST)。実際に試験する伝送媒体に合わせて、データ収集手順を変更する必要が生じる場合があります。そのような調整内容は試験結果とともに提示しなければなりません (MUST)。
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イベントの処理や装置キャッシュの構築）が必要になる場合があります (MAY)。したがって、マルチキャストまたはユニキャストパケットの転送を必要とする試験の前に、試験装置は、後でDUT/SUTの応答を測定する際に使うものと同じアドレス特性の試験トラフィックをDUT/SUTに送信しなければなりません (MUST)。試験モニターは、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をサポートしなければなりません (MUST)。イングレスインターフェイスで使うIGMPのバージョンは、エグレスインターフェイスで試験するバージョンと同じでなければなりません (MUST)。
Each of the ingress and egress interfaces SHOULD be able to respond to IGMP queries during the test.
各イングレスおよびエグレスインターフェイスは、試験中にIGMPクエリーへ応答できるべきです (SHOULD)。
Each of the ingress and egress interfaces SHOULD also send LEAVE (running IGMP version 2 or later) [Ca02] [Fe97] after each test.
各イングレスおよびエグレスインターフェイスは、各試験の後にもLEAVE（IGMPバージョン2以降の場合）[Ca02] [Fe97]を送信すべきです (SHOULD)。
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] を遵守しなければなりません (MUST)。アドレス選択をAdministratively Scoped IP Multicastアドレス [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.
各試験は、複数のマルチキャストフレームサイズで実施すべきです (SHOULD)。Ethernetの場合、推奨されるサイズは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.
他のリンク層技術を使用してもかまいません (MAY)。使用するリンク層技術の最小および最大フレーム長も試験すべきです (SHOULD)。
When testing with different frame sizes, the DUT/SUT configuration MUST remain the same.
異なるフレームサイズで試験するとき、DUT/SUTの構成を変えてはなりません (MUST)。
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のバージョンに準拠しなければなりません (MUST)。
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秒にすべきです (SHOULD)。このパラメーターを各方法論の結果報告に含めなければなりません (MUST)。
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のフレーム転送特性を評価する試験について説明します。一部の指標は、RFC 1242で示されたスループットの概念を拡張します。Forwarding RateはRFC 2285 [Ma98]で参照されています。
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:
試験トラフィックを入力する前に、次のイベントが発生していなければなりません (MUST)。
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 マルチキャストトラフィックを受信するよう構成されたすべての宛先側試験ポートが、構成済みのすべてのマルチキャストグループに参加しなければなりません (MUST)。o DUT/SUTは、適切なユニキャストアドレスとマルチキャストアドレスを学習しなければなりません (MUST)。
o Group membership and unicast address learning MUST be verified through some externally observable method.
o グループメンバーシップとユニキャストアドレスの学習を、外部から観測可能な方法で検証しなければなりません (MUST)。
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] は、単一のイングレスインターフェイスにマルチキャストクラスフレームとユニキャストクラスフレームを交互に入力するよう構成すべきです (SHOULD)。ユニキャストクラスフレームは、すべての宛先ポートに対して重みなしラウンドロビン方式で送信するよう構成しなければなりません (MUST)。
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つあり、各ポートにユニキャストアドレスが1つずつ割り当てられた宛先ポートが3つある場合、送信元側試験ポートは次の順にフレームを入力します。
m1 u1 m2 u2 m3 u3 m4 u1 m5 u2 m6 u3 m1 ...
m1 u1 m2 u2 m3 u3 m4 u1 m5 u2 m6 u3 m1 ...
Where:
ここで：
m<Number> = Multicast Frame<Group>
u<Number> = Unicast Frame<Target Port>
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.
混合クラススループットの測定方法はRFC 2432 [Du98]で定義されています。混合クラススループットを求めるために、探索アルゴリズムを使用しなければなりません (MUST)。意図する負荷を変化させても、ユニキャストフレームとマルチキャストフレームの比率を同じに保たなければなりません (MUST)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o Mixed Class Throughput as defined in RFC 2432 [Du98], including: Throughput per unicast and multicast traffic classes.
o RFC 2432 [Du98]で定義される混合クラススループット。これには、ユニキャストおよびマルチキャストの各トラフィッククラスのスループットを含みます。
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の推奨に従い、試験した各フレームサイズを1行ずつ記載した表で報告すべきです (SHOULD)。各行には、意図する負荷、入力したマルチキャストフレーム数、入力したユニキャストフレーム数、およびクラスごとの測定スループットを記載すべきです (SHOULD)。
Objective:
目的：
To determine Forwarding Rate as a function of tested multicast groups for a fixed number of tested DUT/SUT ports.
試験対象のDUT/SUTポート数を固定し、試験するマルチキャストグループ数に応じたForwarding Rateを求めます。
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.
これは反復手順です。最初の反復では、宛先側試験ポートが初期数のマルチキャストグループに参加しなければなりません (MUST)。マルチキャストトラフィックを受信するよう構成されたすべての宛先側試験ポートは、構成済みのすべてのマルチキャストグループに参加しなければなりません (MUST)。最初の反復で参加するグループ数として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が推奨されますが、試験者はより細かい単位を選んでもかまいません (MAY)。その後、その反復で参加したすべてのグループ宛てにマルチキャストトラフィックを送信し、転送率を測定します。
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のマルチキャストグループ容量を超えてはなりません (MUST NOT)。この試験を実施する前に、グループ容量（セクション7.1）の結果が分かっていなければなりません (MUST)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version
o フレームサイズ o DUT/SUTで試験したエグレスインターフェイス数 o 試験時間 o IGMPバージョン
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o The total number of multicast groups joined for that iteration
o その反復で参加したマルチキャストグループの総数
o Forwarding rate determined for that iteration
o その反復で測定したForwarding Rate
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.
各試験のScaled Group Forwardingの結果は、試験の各反復を1行ずつ示す表で報告すべきです (SHOULD)。各行（反復）には、その反復で参加したグループの総数、入力負荷、送信フレーム総数、受信フレーム総数、およびその反復で測定した集約Forwarding Rateを記載すべきです (SHOULD)。
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個へ転送するために入力したフレームが1つも失われない、最大レートを求めます。
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.
インターフェイスの集合、グループ数、フレーム長、および試験時間を固定し、初期の最大入力負荷でマルチキャストトラフィックを送信します。すべての宛先側試験ポートは、指定されたすべてのマルチキャストグループに参加しなければなりません (MUST)。
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.
フレーム損失が検出された場合、入力負荷を下げて送信側が再度送信します。フレーム損失がゼロとなる最大入力フレームレートを求めるため、反復探索アルゴリズムを使用しなければなりません (MUST)。
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.
測定するパラメーターには、フレーム損失が発生しなかった最大入力負荷を含めなければなりません (MUST)。診断を目的として、他の入力負荷を測定してもかまいません (MAY)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 フレームサイズ o DUT/SUTで試験したエグレスインターフェイス数 o 試験時間 o IGMPバージョン o マルチキャストグループ総数
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o Aggregated Multicast Throughput as defined in RFC 2432 [Du98]
o RFC 2432 [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の推奨に従い、試験した各フレームサイズを1行ずつ示す表で報告すべきです (SHOULD)。各行（反復）には、入力負荷、入力フレーム総数、および測定したマルチキャスト集約スループットを記載すべきです (SHOULD)。
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の1つのイングレスインターフェイスに入力したフレームが、損失なくカプセル化され、DUT/SUTの1つ以上のエグレスインターフェイスへ正しく転送される最大レートを求めます。
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の各エグレスインターフェイスと宛先側試験ポートとの間に、1つ以上のトンネルを確立します。次に、送信元側試験ポートが非カプセル化マルチキャストトラフィックを入力し、DUT/SUTがこれをカプセル化して宛先側試験ポートへ転送します。
The DUT/SUT SHOULD be configured such that the traffic across each egress interface will consist of either:
各エグレスインターフェイスを通るトラフィックが、次のいずれかになるようDUT/SUTを構成すべきです (SHOULD)。
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を複数トンネル構成にする場合、各トンネル内のマルチキャストグループ数を同じにしなければなりません (MUST)。また、各エグレスインターフェイスに同じ数のトンネルを設定して試験することが推奨されます (SHOULD)。すべての宛先側試験ポートは、送信元側試験ポートから入力されるすべてのマルチキャストグループアドレスに参加しなければなりません (MUST)。各エグレスインターフェイスには同じMTUを設定しなければなりません (MUST)。
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.
注：大きなフレームを入力する場合、カプセル化処理のため、DUT/SUTがエグレスインターフェイスから転送する前にIPデータグラムを断片化しなければならない場合があります。DUT/SUTで断片化が不要となるよう、入力フレームサイズを制限することが推奨されます (SHOULD)。
A search algorithm MUST be utilized to determine the encapsulation throughput as defined in [Du98].
[Du98]で定義されるカプセル化スループットを求めるため、探索アルゴリズムを使用しなければなりません (MUST)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o Measured Encapsulated Throughput as defined in RFC 2432 [Du98] o Encapsulated frame size
o RFC 2432 [Du98]で定義される測定済みカプセル化スループット o カプセル化されたフレームサイズ
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.
カプセル化スループットの結果は表形式で報告すべきです (SHOULD)。この試験では、カプセル化前の各入力フレームサイズについて行を設けるべきです (SHOULD)。各行（反復）には、入力負荷、カプセル化方式、カプセル化後のフレームサイズ、入力フレーム総数、およびカプセル化スループットを記載すべきです (SHOULD)。
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つのイングレスインターフェイスに入力したフレームが、損失なくカプセル解除され、1つ以上のエグレスインターフェイスから正しく転送される最大レートを求めます。
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の間に1つ以上のトンネルを確立します。送信元側試験ポートがカプセル化済みのマルチキャストトラフィックを入力し、DUT/SUTがカプセル解除して宛先側試験ポートへ転送します。
The DUT/SUT SHOULD be configured such that the traffic across the ingress interface will consist of either:
イングレスインターフェイスを通るトラフィックが次のいずれかになるよう、DUT/SUTを構成すべきです (SHOULD)。
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を複数トンネル構成にする場合、トンネルごとのマルチキャストグループ数を同じにしなければなりません (MUST)。すべての宛先側試験ポートは、送信元側試験ポートから入力されるすべてのマルチキャストグループアドレスに参加しなければなりません (MUST)。各エグレスインターフェイスには同じMTUを設定しなければなりません (MUST)。
A search algorithm MUST be utilized to determine the decapsulation throughput as defined in [Du98].
[Du98]で定義されるカプセル解除スループットを求めるため、探索アルゴリズムを使用しなければなりません (MUST)。
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を参照）で報告されたカプセル化後のフレームサイズを使うべきです (SHOULD)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o Measured Decapsulated Throughput as defined in RFC 2432 [Du98] o Decapsulated frame size
o RFC 2432 [Du98]で定義される測定済みカプセル解除スループット o カプセル解除後のフレームサイズ
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.
カプセル解除スループットの結果は表形式で報告すべきです (SHOULD)。この試験では、各入力カプセル化フレームサイズについて行を設けるべきです (SHOULD)。各行（反復）には、入力負荷、カプセル解除後のフレームサイズ、入力フレーム総数、およびカプセル解除スループットを記載すべきです (SHOULD)。
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.
DUT/SUTの1つのイングレスインターフェイスに入力した、ある形式でカプセル化されたフレームを別のカプセル化形式に変換し、損失なく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に入力します。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を構成すべきです (SHOULD)。
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を複数トンネル構成にする場合、トンネルごとのマルチキャストグループ数を同じにしなければなりません (MUST)。また、イングレスおよび各エグレスインターフェイスのトンネル数が同じになるよう、DUT/SUTを構成すべきです (SHOULD)。すべての宛先側試験ポートは、送信元側試験ポートから入力されるすべてのマルチキャストグループアドレスに参加しなければなりません (MUST)。各エグレスインターフェイスには同じMTUを設定しなければなりません (MUST)。
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.
注：大きなフレームを入力する場合、カプセル化処理により、DUT/SUTはエグレスインターフェイスから転送する前にIPデータグラムを断片化しなければならない場合があります。DUT/SUTで断片化が不要になるよう、入力フレームサイズを制限することが推奨されます (SHOULD)。
A search algorithm MUST be utilized to determine the re-encapsulation throughput as defined in [Du98].
[Du98]で定義される再カプセル化スループットを求めるため、探索アルゴリズムを使用しなければなりません (MUST)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o Measured Re-encapsulated Throughput as defined in RFC 2432 [Du98] o Re-encapsulated frame size
o RFC 2432 [Du98]で定義される測定済み再カプセル化スループット o 再カプセル化後のフレームサイズ
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.
再カプセル化スループットの結果は表形式で報告すべきです (SHOULD)。この試験では、入力時の各カプセル化フレームサイズについて行を設けるべきです (SHOULD)。各行（反復）には、入力負荷、再カプセル化後のフレームサイズ、入力フレーム総数、および再カプセル化スループットを記載すべきです (SHOULD)。
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のパケットバッファリングに影響し、その結果、測定遅延にも影響する場合があります。以下の方法で意図する負荷を選択するときは、この点を考慮すべきです (SHOULD)。
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]の「Multicast 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]で示された方法に基づいています。この方法論では、2種類のトポロジーを扱います。1つは単一装置（DUT）の特性評価、もう1つは複数装置（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のようになります。すなわち、DUTの単一のイングレスインターフェイスが試験装置のフレーム送信部からマルチキャスト試験トラフィックを受信し、同じDUTのn個のエグレスインターフェイスがそのトラフィックを試験装置のフレーム受信部へ転送します。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秒にすべきです (SHOULD)。遅延測定の方式が「ストアアンドフォワード」か「ビット転送」かを、関連する試行に対応付け、結果報告で開示しなければなりません (MUST)。
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）のレートでトラフィックを入力することが推奨されます (SHOULD)。試行時間の中間点で、試験装置は識別可能な「タグ付き」フレームを試験トラフィックに挿入しなければなりません (MUST)。このフレームを遅延測定の基準にします。「識別可能」とは、試験装置が試験トラフィックを構成する他のフレームとタグ付きフレームを見分けられることを意味し、試験装置はこれが可能でなければなりません (MUST)。タグ付きフレームの送信完了時刻を表すフレーム生成タイムスタンプTimestamp Aを決定しなければなりません (MUST)。
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の試験対象エグレスインターフェイスから出るフレームを監視し、想定したタグ付きフレームを検出した時刻をTimestamp Bとして記録しなければなりません (MUST)。DUT/SUTのすべての試験対象エグレスインターフェイスについて、Timestamp Bの値を収集しなければなりません (MUST)。ストアアンドフォワード装置とビット転送装置の詳細についてはRFC 1242 [Br91]を参照してください。
A trial MUST be considered INVALID should any of the following conditions occur in the collection of the trial data:
試行データの収集中に次のいずれかが発生した場合、その試行を無効としなければなりません (MUST)。
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.
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は、有効な試行から求めなければなりません (MUST)。
M = { (Timestamp B(E0) - Timestamp A),
(Timestamp B(E1) - Timestamp A), ...
(Timestamp B(En) - Timestamp 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)は試験対象となったすべてのエグレスインターフェイスの範囲を表し、Timestamp Bは所定のDUT/SUT試験対象エグレスインターフェイスでタグ付きフレームを検出した事象を表します。
A more continuous profile MAY be built from a series of individual measurements.
個別測定を連続して行うことで、より連続的なプロファイルを作成してもかまいません (MAY)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 DUT/SUTで試験したエグレスインターフェイス数 o 試験時間 o IGMPバージョン o 入力負荷 o マルチキャストグループ総数
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o The set of all latencies with respective time units related to the tested ingress and each tested egress DUT/SUT interface.
o 試験対象となったDUT/SUTのイングレスインターフェイスと各エグレスインターフェイスの組み合わせについて、対応する時間単位を付したすべての遅延値。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
報告する遅延の時間単位は統一し、試験対象の伝送媒体に対して十分な精度を持たなければなりません (MUST)。
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.
結果は表形式で提示してもかまいません (MAY)。また、複数回の試行にわたる傾向を追えるよう、各マルチキャストグループについて遅延とイングレス/エグレスインターフェイスの対応関係を保つことが望ましいです。
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.
Multicast Latencyベンチマークで収集した遅延値の集合から、最大遅延測定値と最小遅延測定値の差を求めます。
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の規定に従い、1回の試験時間にわたってマルチキャスト遅延測定値を収集します。これによりマルチキャスト遅延の集合Mが得られます。Mは、DUTのフレームイングレスとフレームエグレスの各ポート組み合わせ間で測定した個々の転送遅延から成ります。例：
M = {L(I,E1),L(I,E2), ..., L(I,En)}
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はDUTの試験対象イングレスインターフェイスIと、同じDUTの特定の試験対象マルチキャストエグレスインターフェイスExとの間の遅延です。E1からEnは、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)
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 DUT/SUTで試験したエグレスインターフェイス数 o 試験時間 o IGMPバージョン o 入力負荷 o マルチキャストグループ総数
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o The Max/Min value
o 最大/最小値
The following results SHOULD be reflected in the test report:
次の結果を試験報告書に記載すべきです (SHOULD)。
o The set of all latencies with respective time units related to the tested ingress and each tested egress DUT/SUT interface.
o 試験対象となったDUT/SUTのイングレスインターフェイスと各エグレスインターフェイスの組み合わせについて、対応する時間単位を付したすべての遅延値。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
報告する遅延の時間単位は統一し、試験対象の伝送媒体に対して十分な精度を持たなければなりません (MUST)。
The results MAY be offered in a tabular format and should preserve the relationship of latency to ingress/egress interface for each multicast group.
結果は表形式で提示してもかまいません (MAY)。また、各マルチキャストグループについて遅延とイングレス/エグレスインターフェイスの対応関係を保つことが望ましいです。
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.
DUT/SUTに対するIGMPグループメンバーシップ報告が成功した時点から、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.
o 状態0：MFDBに指定されたマルチキャストグループアドレスが登録されていません。この状態で測定する遅延には、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 状態1：MFDBに指定されたマルチキャストグループアドレスが登録されています。この状態で測定する遅延には、新たに参加したノードをMFDBに反映し、そのノードへの転送を開始するまでの時間と、パケット複製にかかる時間が含まれます。状態1で測定した遅延から、同じ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つの代替手順を示します。DUT/SUTがMFDBを管理する能力を把握するため、各手順を個別に、または組み合わせて使用してもかまいません (MAY)。
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.
ユーザーは、マルチキャストグループ参加遅延の測定にどちらの方法を使ってもかまいません (MAY)。ただし、報告形式にはデータ収集方法を明記しなければなりません (MUST)。
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つにして試験すべきです (SHOULD)。さらに、すべての宛先側試験ポートは、DUT/SUTのイングレスインターフェイスに入力する指定のマルチキャストグループに参加しなければなりません (MUST)。
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では、DUT/SUTのマルチキャスト転送データベース<MFDB>に指定されたマルチキャストグループアドレスが登録も学習もされていないものとします。つまり、MFDBは状態0でなければなりません (MUST)。この場合の指標は、DUT/SUTがマルチキャストアドレスをMFDBに追加し、マルチキャストパケットの転送を開始するまでの時間です。この指標を測定するには、イングレスを1つ、エグレスを1つだけ使わなければなりません (MUST)。
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 Group Membership Reportを送信する前に、宛先側試験ポートが指定のマルチキャストグループに現在参加していないことを、外部から観測可能な方法で確認しなければなりません (MUST)。さらに、DUT/SUTのMFDBに指定のマルチキャストアドレスが登録されていないことも、外部から観測可能な方法で確認しなければなりません (MUST)。
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でなければなりません (MUST)。この場合の指標は、DUT/SUTが追加ノードとそれに対応するインターフェイスをMFDBに反映し、マルチキャストパケットの転送を開始するまでの時間です。この指標の測定には、1つ以上のエグレスポートを使用してもかまいません (MAY)。
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 Group Membership Reportを送信する前に、MFDBに指定のマルチキャストグループアドレスが登録されていることを、外部から観測可能な方法で確認しなければなりません (MUST)。試験トラフィックを送信する前に、計測機器を接続しない試験ポートを1つ使って、指定のマルチキャストグループアドレスに参加しなければなりません (MUST)。このポートは、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).
検証が完了したら、DUT/SUTがIGMP Group Membership Reportメッセージを受信する前から、指定のマルチキャストグループアドレス宛てのトラフィックをイングレスインターフェイスに入力しなければなりません (MUST)。測定したマルチキャスト集約スループットのレート（セクション4.3）でトラフィックを入力することが推奨されます (SHOULD)。
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 Group Membership Reportを1つ送信しなければなりません (MUST)。
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 Group Membershipメッセージの送信時刻（Timestamp A）から、マルチキャストグループの最初のフレームが受信側エグレスインターフェイスへ転送された時刻（Timestamp B）までの差です。
Group Join delay time = timestamp B - timestamp A
Group Join delay time = timestamp B - timestamp A
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.
Timestamp Aは、宛先側試験ポートがIGMP Group Membership Reportの最後のビットを送信した時刻でなければなりません (MUST)。Timestamp Bは、DUT/SUTのエグレスインターフェイスで最初の有効なマルチキャストフレームの先頭ビットが転送された時刻でなければなりません (MUST)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 DUT/SUTで試験したエグレスインターフェイス数 o IGMPバージョン o マルチキャストグループ総数 o イングレスインターフェイスへの入力負荷 o グループ参加遅延指標の測定方法
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
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の推奨に従い、試験した各フレームサイズを1行ずつ示す表で報告してもかまいません (MAY)。各行（反復）には、その反復におけるエグレスインターフェイスごとのグループ参加遅延を記載してもかまいません (MAY)。
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つにして試験すべきです (SHOULD)。さらに、すべての宛先側試験ポートは、DUT/SUTのイングレスインターフェイスに入力する指定のマルチキャストグループに参加しなければなりません (MUST)。
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メッセージを送信する前に、宛先側試験ポートが現在指定のマルチキャストグループに参加していることを、外部から観測可能な方法で確認しなければなりません (MUST)。いずれかのエグレスインターフェイスが検証用マルチキャストフレームを転送しない場合、試験は無効です。
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 Leave Groupメッセージを受信または処理する前から、指定のマルチキャストグループアドレス宛てのトラフィックをイングレスインターフェイスに入力しなければなりません (MUST)。測定したマルチキャスト集約スループットのレート（セクション4.3）でトラフィックを入力することが推奨されます (SHOULD)。
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参照）は、指定のマルチキャストグループについてIGMP Leave Groupメッセージを1つ送信しなければなりません (MUST)。
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メッセージの送信時刻（Timestamp A）から、マルチキャストグループの最後のフレームが受信側エグレスインターフェイスへ転送された時刻（Timestamp B）までの差です。
Group Leave delay time = timestamp B - timestamp A
Group Leave delay time = timestamp B - timestamp 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.
Timestamp Aは、宛先側試験ポートがIGMP Leave Groupメッセージの最後のビットを送信した時刻でなければなりません (MUST)。Timestamp Bは、DUT/SUTのエグレスインターフェイスで最後の有効なマルチキャストフレームの最後のビットが転送された時刻でなければなりません (MUST)。
Reporting Format:
報告形式：
The following configuration parameters MUST be reflected in the test report:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 DUT/SUTで試験したエグレスインターフェイス数 o IGMPバージョン o マルチキャストグループ総数 o イングレスインターフェイスへの入力負荷
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
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の推奨に従い、試験した各フレームサイズを1行ずつ示す表で報告してもかまいません (MAY)。各行（反復）には、その反復におけるエグレスインターフェイスごとのグループ離脱遅延を記載してもかまいません (MAY)。
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が登録済みのすべてのマルチキャストグループ宛てにマルチキャストフレームを転送できる状態を維持しながら、サポートできるグループの最大数を求めます。
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で測定した最小遅延が経過した後、送信元側試験ポートは、指定された入力負荷で各グループ宛てに送信しなければなりません (MUST)。
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.
参加対象の各エグレスインターフェイスで、各マルチキャストグループ宛てのフレームが少なくとも1つ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:
次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Offered load
o フレームサイズ o DUT/SUTで試験したエグレスインターフェイス数 o IGMPバージョン o 入力負荷
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
o The total number of multicast group addresses that were successfully forwarded through the DUT/SUT
o DUT/SUTを通じて正常に転送されたマルチキャストグループアドレスの総数
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の推奨に従い、試験した各フレームサイズを1行ずつ示す表で報告すべきです (SHOULD)。各行（反復）には、宛先インターフェイスごとの参加マルチキャストグループ数、その反復で送信したフレーム数、および受信したフレーム数を記載すべきです (SHOULD)。
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]の「Multicast 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で説明したマルチキャスト遅延試験の構成に従わなければなりません (MUST)。さらに、DUT/SUTに負荷をかけるための別の試験ポート群（負荷ポート）を使用しなければなりません (MUST)。負荷ポートは、RFC 2285 [Ma98]で説明されるフルメッシュのトラフィック分布に従い、ユニキャストクラスのトラフィックをDUT/SUTへ送信します。DUT/SUTは適切なユニキャストアドレスを学習し、その学習を外部から観測可能な方法で検証しなければなりません (MUST)。
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の説明に従って、マルチキャスト遅延のベースラインを測定します。ベースラインを取得した後、負荷ポート群からユーザー指定の入力負荷でユニキャストクラスのトラフィックを送信し、マルチキャスト遅延試験を再実施します。イングレスポートへの入力負荷は、ベースライン測定時と同じでなければなりません (MUST)。
Reporting Format:
報告形式：
Similar to Section 5.1, the following configuration parameters MUST be reflected in the test report:
セクション5.1と同様に、次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 DUT/SUTで試験したエグレスインターフェイス数 o 試験時間 o IGMPバージョン o イングレスインターフェイスへの入力負荷 o マルチキャストグループ総数 o 負荷ポートへの入力負荷 o 負荷ポート総数
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
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.
報告する遅延の時間単位は統一し、試験対象の伝送媒体に対して十分な精度を持たなければなりません (MUST)。
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で推奨される各フレームサイズについて行を設けた表で報告すべきです (SHOULD)。複数回の試行にわたる傾向を追えるよう、遅延とイングレス/エグレスインターフェイスの対応関係も保つべきです (SHOULD)。
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.
ユニキャストトラフィックをフルメッシュで転送しながら、DUT/SUTに対してIGMP Group Membership Reportを正常に送信した時点から、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で説明したグループ参加遅延試験の構成に従わなければなりません (MUST)。さらに、DUT/SUTに負荷をかけるための別の試験ポート群（負荷ポート）を使用しなければなりません (MUST)。負荷ポートは、RFC 2285 [Ma98]で説明されるフルメッシュのトラフィックパターンに従い、ユニキャストクラスのトラフィックをDUT/SUTへ送信します。DUT/SUTは適切なユニキャストアドレスを学習し、その学習を外部から観測可能な方法で検証しなければなりません (MUST)。
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の説明に従って、グループ参加遅延のベースラインを測定します。ベースライン取得後、負荷ポート群からユーザー指定の入力負荷でユニキャストクラスのトラフィックを送信し、グループ参加遅延試験を再実施します。イングレスポートへの入力負荷は、ベースライン測定時と同じでなければなりません (MUST)。
Reporting Format:
報告形式：
Similar to Section 6.1, the following configuration parameters MUST be reflected in the test report:
セクション6.1と同様に、次の構成パラメーターを試験報告書に記載しなければなりません (MUST)。
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 DUT/SUTで試験したエグレスインターフェイス数 o IGMPバージョン o イングレスインターフェイスへの入力負荷 o マルチキャストグループ総数 o 負荷ポートへの入力負荷 o 負荷ポート総数 o グループ参加遅延指標の測定方法
The following results MUST be reflected in the test report:
次の結果を試験報告書に記載しなければなりません (MUST)。
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の推奨に従い、試験した各フレームサイズを1行ずつ示す表で報告してもかまいません (MAY)。各行（反復）には、その反復におけるエグレスインターフェイスごとのグループ参加遅延、送信フレーム数、および受信フレーム数を記載してもかまいません (MAY)。
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ベンチマーク方法論ワーキンググループ、特にJuniper NetworksのKevin 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（Ixia）とRalph Daniels（Spirent Communications）に謝意を表します。両名はこの文書の初期版に大きく貢献しました。また、この文書の完成に協力したタスクチームのメンバーであるMichele Bustos、Tony De La Rosa、David Newman、Jerry Perserにも謝意を表します。
[Br91] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[Br91] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement Levels, RFC 2119, March 1997.
[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement Levels, RFC 2119, March 1997.
[Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[IANA1] IANA multicast address assignments, http://www.iana.org/assignments/multicast-addresses
[IANA1] IANA multicast address assignments, http://www.iana.org/assignments/multicast-addresses
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Ca02] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[Ca02] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
[Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive Corporate Networks", John Wiley & Sons Inc., 1998.
[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive Corporate Networks", John Wiley & Sons Inc., 1998.
[Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.
[Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.
Debra Stopp Ixia 26601 W. Agoura Rd. Calabasas, CA 91302 USA
Debra Stopp Ixia 26601 W. Agoura Rd. Calabasas, CA 91302 USA
Phone: + 1 818 871 1800
EMail: debby@ixiacom.com
Brooks Hickman Spirent Communications 26750 Agoura Rd. Calabasas, CA 91302 USA
Brooks Hickman Spirent Communications 26750 Agoura Rd. Calabasas, CA 91302 USA
Phone: + 1 818 676 2412
EMail: brooks.hickman@spirentcom.com
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (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に定める権利、ライセンス、制限が適用されます。同BCPに別段の定めがある場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状有姿」で提供されます。貢献者、その貢献者が代表する、または支援を受ける組織（該当する場合）、Internet SocietyおよびInternet Engineering Task Forceは、明示または黙示を問わず、すべての保証を否認します。これには、ここに含まれる情報の使用がいかなる権利も侵害しないとの保証、および商品性や特定目的への適合性に関する黙示保証が含まれますが、これらに限定されません。
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.
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に知らせるよう呼びかけています。情報はietf-ipr@ietf.org宛てにお送りください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editorの機能に対する資金は、現在Internet Societyが提供しています。