[要約] RFC 3918は、IPマルチキャストのベンチマークテスト方法論に関するドキュメントです。このRFCの目的は、ネットワーク環境でのマルチキャストの性能を評価するための一貫した方法を提供することです。

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).

著作権(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
        
1. Introduction
1. はじめに

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.

この方法論は、多くの目的地に1つのソースに焦点を当てますが、説明されているテストの多くは、複数のソースを複数の宛先トポロジに使用するように拡張される場合があります。

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]にあります。

2. Key Words to Reflect Requirements
2. 要件を反映するキーワード

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document.

「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [BR97]に記載されているように解釈される。RFC 2119は、これらのキーワードの使用を定義して、標準の意図を可能な限り明確に追跡するのに役立ちます。このドキュメントではこれらのキーワードを使用していますが、このドキュメントは標準トラックドキュメントではありません。

3. Test set up
3. テスト設定

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は、IPマルチキャストテストの典型的なセットアップを示しており、複数の宛先から1つのソースがあります。

                     +------------+         +--------------+
                     |            |         |  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.

一般に、宛先テストポートは、IGMPグループレポートメッセージをDUT/SUTに送信することにより、最初に必要な数のマルチキャストグループに参加します。すべての宛先テストポートが適切なグループに正常に結合されたことを確認するために、ソーステストポートは、これらのグループ向けのIPマルチキャストフレームを送信する必要があります。テストの完了後、宛先テストポートは、IGMPを残してグループメッセージを送信して、DUT/SUTのIGMPテーブルをクリアする場合があります。

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.

さらに、テスト機器は、テストに関与するフレームを確実に受信するために、テストするデバイスの正しい適切な転送アクションを検証する必要があります。

3.1. Test Considerations
3.1. テスト上の考慮事項

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.

マルチキャスト分布ツリーの形成は、マルチキャストパフォーマンスの重要なコンポーネントである可能性があることに留意されています。このコンポーネントは、このメモに示されている測定値またはシナリオのいくつかに存在する場合がありますが、このメモは、マルチキャスト分布ツリーの形成を明示的にベンチマークすることを求めていません。マルチキャスト分布ツリー形成のベンチマークは、特定のツリーフォーメーションビークルに固有のよりターゲットを絞った作業として残されています。

3.1.1. IGMP Support
3.1.1. IGMPサポート

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のバージョンをサポートする必要があります。Ingressインターフェイス上の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.

各テストの後、インターフェイスと出口インターフェイスのそれぞれも休暇(IGMPバージョン2以降の実行)[CA02] [FE97]を送信する必要があります。

3.1.2. Group Addresses
3.1.2. グループアドレス

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]。

3.1.3. Frame Sizes
3.1.3. フレームサイズ

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構成は同じままでなければなりません。

3.1.4. TTL
3.1.4. TTL

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のバージョンに準拠している必要があります。

3.1.5. Trial Duration
3.1.5. 試用期間

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秒でなければなりません。このパラメーターは、各方法論の結果レポートの一部として含める必要があります。

4. Forwarding and Throughput
4. 転送とスループット

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で提示されたスループットの概念を拡張します。転送率はRFC 2285 [MA98]で引用されています。

4.1. Mixed Class Throughput
4.1. 混合クラススループット

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.

Unicastクラスフレームとマルチキャストクラスフレームの両方が、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:

たとえば、ポートごとに1つのユニキャストアドレスを備えた6つのマルチキャストグループと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]で定義されています。検索アルゴリズムを使用して、混合クラスのスループットを決定する必要があります。ユニキャストに対するマルチキャストフレームの比率は、意図した負荷を変更する場合、同じままでなければなりません。

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 DUT/SUT oテスト期間上のテスト済み出力インターフェイスの数o IGMPバージョンoマルチキャストグループの総数oユニキャストおよびマルチキャストトラフィッククラスのトラフィック分布oマルチキャストとユニキャストクラストラフィックの比率

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.

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の推奨事項に従って、テストされたフレームサイズごとに行を持つテーブルの形で報告する必要があります。各行は、意図した負荷、提供されるマルチキャストフレームの数、クラスごとに提供され、スループットを測定するユニキャストフレームの数を指定する必要があります。

4.2. Scaled Group Forwarding Matrix
4.2. スケーリングされたグループ転送マトリックス

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

o フレームサイズo dut/sut oテスト期間のテスト済み出力インターフェイスの数o Igmpバージョン

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.

各テストのスケーリングされたグループ転送結果は、テストの各反復を表す行を持つテーブルの形で報告する必要があります。各行または反復では、その反復、提供された負荷、送信されたフレームの総数、受信したフレームの総数、およびその反復で決定される総転送速度の合計グループの総数を指定する必要があります。

4.3. Aggregated Multicast Throughput
4.3. 集約されたマルチキャストスループット

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 フレームサイズo dut/sut oテスト期間上のテストされた出力インターフェイスの数o IGMPバージョンoマルチキャストグループの総数

The following results MUST be reflected in the test report:

次の結果は、テストレポートに反映する必要があります。

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の推奨事項に従って、テストされたフレームサイズごとに行を持つテーブルの形式で報告する必要があります。各行または反復は、提供された負荷、提供されたフレームの総数、測定された集約されたマルチキャストスループットを指定する必要があります。

4.4. Encapsulation/Decapsulation (Tunneling) Throughput
4.4. カプセル化/脱カプセル化(トンネリング)スループット

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でサポートされている形式のサポートされていないプロトコル機能を含むパケットを指します。

4.4.1. Encapsulation Throughput
4.4.1. カプセル化スループット

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は、各出口インターフェイスのトラフィックが次のいずれかで構成されるように構成する必要があります。

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.

注:大きなフレームサイズを提供する場合、カプセル化プロセスでは、出口インターフェイスに転送される前に、DUT/SUTがIPデータグラムを断片化する必要があります。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 Oテスト期間のテストされた出力インターフェイスの数o IGMPバージョンoマルチキャストグループの総数DUT/SUTインターフェイスのサイズ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

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.

カプセル化されたスループットの結果は、テーブルの形で報告され、このテストに固有のものは、発信されていないフレームサイズの発生ごとに行が必要です。各行または反復では、提供される負荷、カプセル化方法、カプセル化されたフレームサイズ、提供されるフレームの総数、およびカプセル化スループットを指定する必要があります。

4.4.2. Decapsulation Throughput
4.4.2. 脱カプセル化スループット

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によって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の間に1つ以上のトンネルが作成されます。その後、カプセル化されたマルチキャストトラフィックは、ソーステストポートによって提供され、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 DUT/SUT Oテスト期間のテストされた出力インターフェイスの数o IGMPバージョンoマルチキャストグループの総数o発信カプセル化アルゴリズムまたはフォーマットパケットのトンネルoカプセル化されたフレームサイズ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

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.

脱カプセル化されたスループットの結果は、テーブルの形式で報告され、このテストに固有のカプセル化されたフレームサイズごとに行があるはずです。各行または反復では、提供される負荷、脱カプセル化フレームサイズ、提供されたフレームの総数、および脱カプセル化スループットを指定する必要があります。

4.4.3. Re-encapsulation Throughput
4.4.3. スループットの再エンコーシング

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つのカプセル化された形式のフレームが別のカプセル化された形式に変換され、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の再エンコールスループットをテストするためのセットアップを示しています。ソーステストポートは、1つのタイプのカプセル化されたトラフィックを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は、侵入と各出口インターフェイス全体のトラフィックが次のいずれかで構成されるように構成する必要があります。

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.

大きなフレームサイズを提供する場合、カプセル化プロセスでは、出口インターフェイスに転送される前に、DUT/SUTがIPデータグラムを断片化する必要がある場合があります。提供されるフレームサイズを制限することをお勧めします。これにより、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 DUT/SUT Oテスト期間のテストされた出力インターフェイスの数o IGMPバージョンoマルチキャストグループの総数o DUT/SUTインターフェイスのサイズoプロビリットカプセル化アルゴリズムまたはフォーマット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

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.

再エンコールされたスループットの結果は、テーブルの形式で報告され、このテストに固有のカプセル化されたフレームサイズごとに行があるはずです。各行または反復では、提供された負荷、再エンコープフォーインタードフレームサイズ、提供されたフレームの総数、および再エンコールされたスループットを指定する必要があります。

5. Forwarding Latency
5. 転送待ち

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は、「ストアとフォワード」と「ビットフォワード」のデバイスタイプを区別します。各タイプは、遅延が収集され、その後提示される方法に影響を与えます。詳細については、関連するRFCSを参照してください。

5.1. Multicast Latency
5.1. マルチキャストレイテンシ

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]のメトリック「マルチキャストレイテンシ」によって規定されているように、同じ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)特性評価のためです。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の形をとる可能性があります。 - マルチキャストテストトラフィックをテスト装置のフレーム受信コンポーネントに戻す同じ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秒でなければなりません。レイテンシ測定の性質「ストアアンドフォワード」または「ビット転送」は、関連するテスト試験に関連付けられ、結果レポートで開示されなければなりません。

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のテスト済みEgressインターフェイスからのフレームを監視し、タイムスタンプを使用したテスト済みの出力インターフェイスからタグ付きフレームの検出を成功させる時間を記録する必要があります。Timestampの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.

o 意図した負荷と提供された負荷または提供された負荷と、DUT/SUT出口ポートの結果として生じる転送レートの間の予期しない違い。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 = { (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)は、すべてのテストされた出力インターフェイスの範囲を表し、タイムスタンプ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 dut/sut oテスト期間上のテスト済み出力インターフェイスの数o IGMPバージョンo提供された負荷oマルチキャストグループの総数

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.

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 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.

結果は表形式で提供される場合があり、各マルチキャストグループの潜伏/出力インターフェイスとの潜時の関係を保持して、複数の試行でトレンドを支援する必要があります。

5.2. Min/Max Multicast Latency
5.2. Min/Maxマルチキャストレイテンシ

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が生成されます。ここで、MはDUTフレームイングレスと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はテスト済みのインターフェースインターフェース、I、DUTの間の遅延と、DUTの特定のテスト済みマルチキャストエグレスインターフェイスとの間の遅延です。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の収集されたマルチキャスト潜伏測定から、最大(m)を識別します。ここで、最大はセットMから最大のレイテンシ値を生成する関数です。

Identify MIN(M), when MIN is a function that yields the smallest latency value from set M.

MINがセットMから最小のレイテンシ値を生成する関数である最小(m)を識別します。

The Max/Min value is determined from the following formula:

最大/min値は、次の式から決定されます。

      Result = 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 dut/sut oテスト期間上のテスト済み出力インターフェイスの数o IGMPバージョンo提供された負荷oマルチキャストグループの総数

The following results MUST be reflected in the test report:

次の結果は、テストレポートに反映する必要があります。

o The Max/Min value

o 最大/min値

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.

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 results MAY be offered in a tabular format and should preserve the relationship of latency to ingress/egress interface for each multicast group.

結果は表形式で提供される場合があり、各マルチキャストグループの潜伏/出力インターフェイスとのレイテンシの関係を維持する必要があります。

6. Overhead
6. オーバーヘッド

This section presents methodology relating to the characterization of the overhead delays associated with explicit operations found in multicast environments.

このセクションでは、マルチキャスト環境で見つかった明示的な操作に関連するオーバーヘッド遅延の特性評価に関連する方法論を示します。

6.1. Group Join Delay
6.1. グループ結合遅延

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に追加して転送を開始するために必要な時間が含まれます。State 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には指定されたマルチキャストグループアドレスが含まれています。この状態では、遅延測定には、DUT/SUTが新しく結合したNode <s>でMFDBを更新し、新しいノード<S>プラスパケット複製時間への転送を開始するために必要な時間が含まれます。State 1から測定された遅延は、DUT/SUTが新しいノードのMFDBをどの程度適切に更新できるかについての情報を提供し、同じIPマルチキャストアドレスの他のノードにパケットを送信します。例には、マルチキャストパケットを介して宣伝されているイベントに新しいユーザーを追加することが含まれます。

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は、DUT/SUTのマルチキャスト転送データベース<MFDB>には、指定されたマルチキャストグループアドレスが含まれていないか、学習されていないことを前提としています。具体的には、MFDBは状態0になければなりません。このシナリオでは、メトリックはDUT/SUTがMFDBにマルチキャストアドレスを追加してマルチキャストパケットの転送を開始するのにかかる時間を表します。このメトリックを決定するには、1つの入り口と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を更新し、マルチキャストパケットの転送を開始するために取る時間を表します。このメトリックを決定するために、1つ以上の出力ポートを使用できます。

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の前に、指定されたマルチキャストグループアドレスのマルチキャストトラフィックをIngressインターフェイスに提供する必要があります。測定された集約されたマルチキャストスループットレートでトラフィックを提供することをお勧めします(セクション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を参照)は、指定されたマルチキャストグループに1つのIGMPグループメンバーシップレポートを送信する必要があります。

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

グループ結合遅延時間=タイムスタンプB-タイムスタンプ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.

タイムスタンプは、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 DUT/SUT O IGMPバージョン上のテストされた出力インターフェイスの数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の推奨事項に従って、テストされたフレームサイズごとに行が行われ、テーブルの形式で報告される場合があります。各行または反復では、グループがその反復のために出口インターフェイスごとに遅延時間に結合することを指定する場合があります。

6.2. Group Leave Delay
6.2. グループ休暇遅延

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.

時間を判断するには、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休暇グループメッセージを送信する前に、宛先テストポートが現在指定されたマルチキャストグループのメンバーであることを意味する外部観察可能なことを介して検証する必要があります。出力インターフェイスのいずれかが検証マルチキャストフレームを転送しない場合、テストは無効です。

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休暇グループメッセージを送信する必要があります。

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の休暇グループメッセージが送信され(タイムスタンプ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.

タイムスタンプは、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 フレームサイズo DUT/SUT O IGMPバージョン上のテスト済み出力インターフェイスの数oマルチキャストグループの総数oインターフェースを侵入する負荷

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の推奨事項ごとにテストされたフレームサイズごとに行があります。各行または反復では、グループがその反復のために出口インターフェイスごとに遅延時間を残すことを指定する場合があります。

7. Capacity
7. 容量

This section offers a procedure relating to the identification of multicast group limits of a DUT/SUT.

このセクションでは、DUT/SUTのマルチキャストグループ制限の識別に関する手順を説明します。

7.1. Multicast Group Capacity
7.1. マルチキャストグループ容量

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.

各マルチキャストグループの少なくとも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つまたは複数の出力インターフェイスが、構成されたマルチキャストグループの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 フレームサイズo dut/sut o igmpバージョンのテストされた出力インターフェイスの数o提供された負荷

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

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の推奨事項に従って、テストされたフレームサイズごとに行を行い、テーブルの形式で報告する必要があります。各行または反復では、宛先インターフェイスごとに参加するマルチキャストグループの数、送信されたフレーム数、その反復に対して受け取ったフレーム数を指定する必要があります。

8. Interaction
8. 交流

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の行動の特性評価を支援する手順を提供します。

8.1. Forwarding Burdened Multicast Latency
8.1. 負担のあるマルチキャストレイテンシを転送します

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.

DUT/SUTの単一のマルチキャストイングレスインターフェイスから、RFC 2432 [DU98]のメトリック「マルチキャストレイテンシ」によって提供されているように、同じ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 dut/sut oテスト期間上のテスト済み出力インターフェイスの数o Igmpバージョンoインターフェイスに浸透したインターフェースoマルチキャストグループの総数o負荷ポートに提供された負荷ポート

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の推奨フレームサイズごとにテストされたフレームサイズごとに行を行うテーブルの形式で報告する必要があり、レイテンシの関係を侵入/出口インターフェースと保持する必要があります(s)複数の試行でトレンドを支援する。

8.2. Forwarding Burdened Group Join Delay
8.2. 負担のあるグループが遅れを順方向にします

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がメッシュ化されたユニキャストトラフィックを転送しながら、DUT/SUTに成功したIGMPグループメンバーシップレポートが発行された時からマルチキャストフレームの転送を開始します。

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(負担ポート)に負担をかけるために、別のテストポートセットを使用する必要があります。負担ポートは、RFC 2285 [MA98]に記載されているように、完全にメッシュ化されたトラフィックパターンでUnicastクラストラフィックを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 DUT/SUT O IGMPバージョンのテストされた出力インターフェイスの数oインターフェイスへの荷重の提供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の推奨事項に従って、テストされたフレームサイズごとに行が行われ、テーブルの形式で報告される場合があります。各行または反復では、グループが発生インターフェイスごとに遅延時間、送信されたフレーム数、およびその反復に対して受け取ったフレーム数を指定する場合があります。

9. Security Considerations
9. セキュリティに関する考慮事項

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.

このドキュメントは、メトリック方法論を提供する目的でのみであり、プロトコルもプロトコルの実装も説明していないため、このドキュメントに関連するセキュリティ上の考慮事項は特にありません。これらの方法論の結果は、特定のテストコンテキストでデバイスまたはシステムのパフォーマンス機能または制限を特定する場合があります。ただし、そのような結果は、運用ネットワーク内のテスト済みエンティティを代表するものではない可能性があります。

10. Acknowledgements
10. 謝辞

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のベンチマークメソッドワーキンググループ、特にジュニパーネットワークのケビンダブレイは、このドキュメントを完成させるために集合的に行った多くの提案に感謝する必要があります。

11. Contributions
11. 貢献

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。さらに、著者は、この文書を実現するのを手伝ったタスクチームのメンバー、ミケーレ・バストス、トニー・デ・ラ・ローザ、デビッド・ニューマン、ジェリー・ペルサーを認めたいと考えています。

12. References
12. 参考文献
12.1. Normative References
12.1. 引用文献

[Br91] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.

[BR91] Bradner、S。、「ネットワーク相互接続デバイスのベンチマーク用語」、RFC 1242、1991年7月。

[Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.

[BR96] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。

[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement Levels, RFC 2119, March 1997.

[BR97] Bradner、S。「要件レベルを反映するためのRFCでのキーワードの使用、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] Mandeville、R。、「LANスイッチングデバイスのベンチマーク用語」、RFC 2285、1998年2月。

[Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.

[Me98] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。

12.2. Informative References
12.2. 参考引用

[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。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。

[De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.

[De89] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。

[Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.

[Fe97] Fenner、W。、「インターネットグループ管理プロトコル、バージョン2」、RFC 2236、1997年11月。

[Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.

[Hu95] Huitema、C。、「インターネットでのルーティング」、Prentice-Hall、1995。

[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive Corporate Networks", John Wiley & Sons Inc., 1998.

[Ka98] Kosiur、D。、「IPマルチリキャスト:インタラクティブ企業ネットワークの完全なガイド」、John Wiley&Sons Inc.、1998。

[Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.

[MT98] Maufer、T。、「エンタープライズにIPマルチキャストの展開」、Prentice-Hall、1998。

13. Authors' Addresses
13. 著者のアドレス

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
        
14. 完全な著作権声明

Copyright (C) The Internet Society (2004).

著作権(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に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

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.

このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織(もしあれば)が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

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-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。