RFC3918 日本語訳

3918 Methodology for IP Multicast Benchmarking. D. Stopp, B. Hickman. October 2004. (Format: TXT=64652 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           D. Stopp
Request for Comments: 3918                                          Ixia
Category: Informational                                       B. Hickman
                                                  Spirent Communications
                                                            October 2004

Stoppがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3918年のイキシアカテゴリ: 情報のB.ヒックマンSpirentコミュニケーション2004年10月

               Methodology for IP Multicast Benchmarking

IPマルチキャストベンチマーキングのための方法論

Status of this Memo

この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)インターネット協会(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推進装置のベンチマーキングに特定の方法論について説明することです。 それはRFC2544(RFC2432と他のIETF Benchmarking Methodology作業部会(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つの主要なクラスのドキュメントを製作します: ベンチマーキングTerminologyドキュメントとBenchmarking Methodologyドキュメント。 Terminologyドキュメントはベンチマークと他の関連する用語を提示します。Methodologyドキュメントは対応するTerminologyドキュメントで引用されたベンチマークを集めるのに必要である手順を定義します。

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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件を反映するキーワード。 . . . . . . . . . . . . . . 3 3. テストはセットアップされました。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. 問題をテストしてください。 . . . . . . . . . . . . . . . . . . 4 3.1.1. IGMPサポート。 . . . . . . . . . . . . . . . . . . 5 3.1.2. .3にアドレス. . . . . . . . . . . . . . . . . 5 3.1を分類してください。 フレーム・サイズ. . . . . . . . . . . . . . . . . . . 5 3.1.4。 TTL. . . . . . . . . . . . . . . . . . . . . . . 6 3.1.5。 トライアル持続時間。 . . . . . . . . . . . . . . . . . 6 4. 推進とスループット。 . . . . . . . . . . . . . . . . . . 6 4.1. Mixedクラススループット. . . . . . . . . . . . . . . . . 6 4.2。 スケーリングされたグループ推進マトリクス. . . . . . . . . . . . . 8 4.3。 マルチキャストスループットに集めました。 . . . . . . . . . . . . 9

Stopp & Hickman              Informational                      [Page 1]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[1ページ]のRFC3918Methodology

       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

4.4. カプセル化/被膜剥離術(トンネリング)スループット. . . 10 4.4.1。 カプセル化スループット。 . . . . . . . . . . . . 10 4.4.2. 被膜剥離術スループット。 . . . . . . . . . . . . 12 4.4.3. 再カプセル化スループット. . . . . . . . . . . 14 5。 潜在. . . . . . . . . . . . . . . . . . . . . . 15 5.1を進めます。 マルチキャスト潜在。 . . . . . . . . . . . . . . . . . . . 16 5.2. 分/マックスマルチキャスト潜在。 . . . . . . . . . . . . . . . 18 6. オーバーヘッド. . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.1。 グループは遅れ. . . . . . . . . . . . . . . . . . . . 20 6.2に合流します。 グループは遅れを残します。 . . . . . . . . . . . . . . . . . . . 22 7. 容量. . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1。 マルチキャストグループ容量. . . . . . . . . . . . . . . . 24 8。 相互作用。 . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.1. 推進はマルチキャスト潜在を負いました。 . . . . . . . . . 25 8.2. 背負い込んでいるグループを転送して、遅れ. . . . . . . . . . 27 9を接合してください。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 28 10. 承認. . . . . . . . . . . . . . . . . . . . . . . 28 11。 貢献。 . . . . . . . . . . . . . . . . . . . . . . . . 28 12. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 28 12.1。 引用規格. . . . . . . . . . . . . . . . . . 28 12.2。 有益な参照. . . . . . . . . . . . . . . . . 29 13。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 30 14。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 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マルチキャストプロトコルをサポートする装置の潜在とインターネットGroup Managementプロトコル(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つのソースに焦点を合わせるでしょう、説明されたテストの多くが複数の目的地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マルチキャストと関連するマルチキャストルーティング・プロトコル性能を記述するかもしれません。 [Hu95]、[Ka98]、および[Mt98]でIPでの追加洞察とマルチキャストネットワークを見つけることができます。

Stopp & Hickman              Informational                      [Page 2]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[2ページ]のRFC3918Methodology

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.

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[Br97]で説明されるように本書では解釈されることであるべきです。 RFC2119は、標準化過程ドキュメントの意図をできるだけ明確にするのを助けるためにこれらのキーワードの使用を定義します。 このドキュメントはこれらのキーワードを使用しますが、このドキュメントは標準化過程ドキュメントではありません。

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は複数の目的地への1つのソースと共にIPマルチキャストテストのための典型的なセットアップを示しています。

                     +------------+         +--------------+
                     |            |         |  destination |
   +--------+        |     Egress(-)------->|    test      |
   | source |        |            |         |   port(E1)   |
   |  test  |------>(|)Ingress    |         +--------------+
   |  port  |        |            |         +--------------+
   +--------+        |     Egress(-)------->|  destination |
                     |            |         |    test      |
                     |            |         |   port(E2)   |
                     |    DUT     |         +--------------+
                     |            |               . . .
                     |            |         +--------------+
                     |            |         |  destination |
                     |     Egress(-)------->|    test      |
                     |            |         |   port(En)   |
                     +------------+         +--------------+

+------------+ +--------------+ | | | 目的地| +--------+ | 出口(-)------->| テスト| | ソース| | | | ポート(1E)| | テスト|------>、(|、)イングレス| +--------------+ | ポート| | | +--------------+ +--------+ | 出口(-)------->| 目的地| | | | テスト| | | | ポート(2E)| | DUT| +--------------+ | | . . . | | +--------------+ | | | 目的地| | 出口(-)------->| テスト| | | | ポート(アン)| +------------+ +--------------+

                          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.

マルチキャスト測定基準がSystem Under Test(SUT)を形成しながら複数の装置の向こう側に取ることであるなら、テストフレームを次にSUTトポロジーの向こう側に進められたSUTの装置で単一のイングレスインタフェースに提供して、装置のテスト出口のインタフェースはSUTで最終的にテスト装置のフレームを受信するコンポーネントに送ります。 図2は例のSUTテストトポロジーを提供します。 SUTがテストされるなら、対応する試験の成績でテストトポロジーとすべての関連構成の詳細を明らかにしなければなりません。

Stopp & Hickman              Informational                      [Page 3]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[3ページ]のRFC3918Methodology

               *-----------------------------------------*
               |                                         |
   +--------+  |                     +----------------+  |  +--------+
   |        |  |   +------------+    |DUT B Egress E0(-)-|->|        |
   |        |  |   |DUT A       |--->|                |  |  |        |
   | source |  |   |            |    |      Egress E1(-)-|->|  dest. |
   |  test  |--|->(-)Ingress, I |    +----------------+  |  |  test  |
   |  port  |  |   |            |    +----------------+  |  |  port  |
   |        |  |   |            |--->|DUT C Egress E2(-)-|->|        |
   |        |  |   +------------+    |                |  |  |        |
   |        |  |                     |      Egress En(-)-|->|        |
   +--------+  |                     +----------------+  |  +--------+
               |                                         |
               *------------------SUT--------------------*

*-----------------------------------------* | | +--------+ | +----------------+ | +--------+ | | | +------------+ |DUT B出口E0(-)、-|、-、>|、|、|、|、| |DUT A|、-、--、>|、|、|、|、|、| ソース| | | | | 出口E1(-)、-|、-、>| dest。 | | テスト|--|->(-)イングレス、I| +----------------+ | | テスト| | ポート| | | | +----------------+ | | ポート| | | | | |、-、--、>|DUT C出口E2(-)、-|、-、>|、|、|、|、| +------------+ | | | | | | | | | 出口アン(-)、-|、-、>|、| +--------+ | +----------------+ | +--------+ | | *------------------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マルチキャストフレームを伝えなければなりません。 テスト完成の後に、目的地テスト港はIGMPテーブルからDUT/SUTを取り除くメッセージをIGMP Leave Groupに送るかもしれません。

   In addition, test equipment MUST validate the correct and proper
   forwarding actions of the devices they test in order to ensure the
   receipt of the frames that are involved in the test.

さらに、テスト設備はそれらがテストにかかわるフレームの領収書を確実にするために検査する装置の正しくて適切な推進機能を有効にしなければなりません。

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

用意する交通が必要であるかもしれないテストの実際の流れは、その後の交通を最適に進めるためにメカニズム、(例えば、過程RPFイベント、体格装置キャッシュなど)を関係づけました。 したがって、進めるのを必要とするマルチキャストかユニキャストパケットのどんなテストも走らせる前に、テスト装置はテスト交通利用を発生させなければなりません。

Stopp & Hickman              Informational                      [Page 4]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[4ページ]のRFC3918Methodology

   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.

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のバージョンを支持しなければなりません。 イングレスインタフェースのIGMPバージョンは出口のインタフェースでテストされているIGMPの同じバージョンであるに違いありません。

   Each of the ingress and egress interfaces SHOULD be able to respond
   to IGMP queries during the test.

それぞれイングレスと出口のインタフェースSHOULDでは、テストの間、IGMP質問に応じることができてください。

   Each of the ingress and egress interfaces SHOULD also send LEAVE
   (running IGMP version 2 or later) [Ca02] [Fe97] after each test.

また、それぞれ、イングレスと出口のインタフェースでは、SHOULDは各テストの後にLEAVE(走行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]の使用への制限は全くありません。 操作上の一貫性のためにマルチキャストアドレス[IANA1]のためのIANA課題を見なさなければなりません。 アドレス選択によってAdministratively Scoped IP Multicastアドレス[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.

それぞれが異なったマルチキャストがある走行がフレーム・サイズであったならSHOULDをテストします。 イーサネットのために、お勧めのサイズは64、128、256、512、1024、1280、および1518年のバイトのフレームです。

Stopp & Hickman              Informational                      [Page 5]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[5ページ]のRFC3918Methodology

   Other link layer technologies MAY be used.  The minimum and maximum
   frame lengths of the link layer technology in use SHOULD be tested.

他のリンクレイヤ技術は使用されるかもしれません。 リンクの長さが技術を層にする最小の、そして、最大のフレームはSHOULDを使用します。テストされます。

   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.

データ飛行機テスト通信で、TTL値はDUT/SUTを横断できるくらい大きくなるべきです。

   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が秒であったなら各トライアルSHOULDを分配します。 各方法論を届け出る結果の一部としてこのパラメタを含まなければなりません。

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のフレーム推進の特殊化に関連するテストの記述を含みます。 いくつかの測定基準がRFC1242に提示されたスループットの概念について敷衍しています。 推進RateはRFC2285[Ma98]で引用されます。

4.1.  Mixed Class Throughput

4.1. Mixedクラススループット

   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.

同時にRFC2432で定義されるようにユニキャストクラスフレームとマルチキャストクラスフレームの両方をインタフェースの定数まで提供するとき、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 MUSTは適切なユニキャストとマルチキャストアドレスを学びます。 そして

Stopp & Hickman              Informational                      [Page 6]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[6ページ]のRFC3918Methodology

      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]SHOULDを積み込みます。 「非-重みを加え」られた連続ファッションで仕向港のすべてに伝わるようにユニキャストクラスフレームを構成しなければなりません。

   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ポートあたり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>

m<数>=マルチキャストフレーム<グループ>u<番号>はユニキャストフレーム<目標ポート>と等しいです。

   Mixed class throughput measurement is defined in RFC 2432 [Du98].  A
   search algorithm MUST be utilized to determine the Mixed Class
   Throughput.  The ratio of unicast to multicast frames MUST remain the
   same when varying the intended load.

Mixedクラススループット測定はRFC2432[Du98]で定義されます。 Mixed Class Throughputを決定するのに検索アルゴリズムを利用しなければなりません。 意図している負荷を変えるとき、ユニキャスト対マルチキャストフレームの比率は同じままで残らなければなりません。

   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 Numberはユニキャストとマルチキャスト対ユニキャストクラス交通の比率のマルチキャスト交通のクラスoのためにマルチキャストグループoのDUT/SUT o Test持続時間o IGMPバージョンo Total番号でTraffic分配を連結します。

   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 RFC2432[Du98]で定義されるMixed Class Throughput、含み: 1ユニキャストあたりのスループットとマルチキャスト交通は属します。

Stopp & Hickman              Informational                      [Page 7]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[7ページ]のRFC3918Methodology

   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.

それぞれのためのMixed Class Throughput結果は報告されたコネがそれぞれのセクション3.1.3における推薦あたりのテストされたフレーム・サイズのための列があるテーブルのフォームであったならSHOULDをテストします。 それぞれの列のSHOULDは意図している負荷を指定します、フレームが提供したマルチキャストの数、1クラスあたりのスループットに提供されて、測定されたユニキャストフレームの数。

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.

テストされたマルチキャストの機能としてForwarding Rateを決定するのはテストされた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のマルチキャストグループ容量を超えてはいけません。 このテストを走らせる前に、Group Capacity(セクション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 DUT/SUT o Test持続時間o IGMPバージョンのテストされた出口のインタフェースのフレーム・サイズo Number

   The following results MUST be reflected in the test report:

以下の結果を試験報告書に反映しなければなりません:

      o  The total number of multicast groups joined for that
         iteration

o その繰り返しが一緒に楽しまれたマルチキャストグループの総数

Stopp & Hickman              Informational                      [Page 8]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[8ページ]のRFC3918Methodology

      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.

それぞれのためのScaled Group Forwarding結果は報告されたコネが列がテストの各繰り返しを表しているテーブルのフォームであったならSHOULDをテストします。 各列か繰り返しSHOULDがその繰り返しが一緒に楽しまれたグループの総数を指定します、と総数のフレームが、総数のフレームが受け取ったと伝えた提供された負荷と集合伝送速度はその繰り返しのために決定しました。

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 マルチキャストグループのDUT/SUT o Test持続時間o IGMPバージョンo Total番号のテストされた出口のインタフェースのフレーム・サイズo Number

Stopp & Hickman              Informational                      [Page 9]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[9ページ]のRFC3918Methodology

   The following results MUST be reflected in the test report:

以下の結果を試験報告書に反映しなければなりません:

      o  Aggregated Multicast Throughput as defined in RFC 2432
         [Du98]

o RFC2432で定義されるMulticast Throughputに集めます。[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.

Aggregated Multicast Throughput結果SHOULD、列があるテーブルの形式では、それぞれのテストされたフレーム・サイズには、.3にセクション3.1で報告されてください推薦単位で。 各列か繰り返しSHOULDが提供された負荷、総数の提供されたフレーム、および測定Aggregated Multicast Throughputを指定します。

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か1セットのDUTsがトンネル終点として機能しているときスループット測定値の決断に関連するテストの記述を提供します。

   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.

最高率を測定するのは1つ以上の出口で損失なしでDUT/SUTのインタフェースをDUT/SUTの1つのイングレスインタフェースまで提供されたどのフレームが要約されるかにおいて正しく進めました。

   Procedure:

手順:

     Source              DUT/SUT                Destination
    Test Port                                   Test Port(s)
   +---------+        +-----------+             +---------+
   |         |        |           |             |         |
   |         |        |     Egress|--(Tunnel)-->|         |
   |         |        |           |             |         |
   |         |------->|Ingress    |             |         |
   |         |        |           |             |         |
   |         |        |     Egress|--(Tunnel)-->|         |
   |         |        |           |             |         |
   +---------+        +-----------+             +---------+

ソースDUT/SUT目的地テストポートテスト港+---------+ +-----------+ +---------+ | | | | | | | | | 出口|--(トンネル)-->|、|、|、|、|、|、|、|、| |、-、-、-、-、-、--、>|イングレス| | | | | | | | | | | | 出口|--(トンネル)-->|、|、|、|、|、|、|、| +---------+ +-----------+ +---------+

                         Figure 3

図3

Stopp & Hickman              Informational                     [Page 10]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[10ページ]のRFC3918Methodology

   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に関するカプセル化スループットをテストするためのセットアップを示しています。 1つ以上のトンネルがDUT/SUTのそれぞれの出口のインタフェースと目的地テスト港の間で作成されます。 次に、非要約のマルチキャスト交通をソーステスト港で提供して、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つ以上のマルチキャストアドレスを要約する単一のトンネルはOR 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が複数のトンネル構成で構成されるとき、1トンネルあたりのマルチキャストグループの数は同じであるに違いありません。 さらに、それは同じ数のトンネルがそれぞれの出口のインタフェースにある状態でテストするRECOMMENDEDです。 すべての目的地テスト港がソーステスト港によって提供されたすべてのマルチキャストグループアドレスを接合しなければなりません。 同じ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データグラムを断片化するのを必要とするかもしれません。 それが提供されたフレーム・サイズを制限するRECOMMENDEDであるので、断片化は全く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 テストされた出口の数はマルチキャストグループoのDUT/SUT o Test持続時間o IGMPバージョンo Total番号でOriginatingが不-トンネルのトンネルo Encapsulationアルゴリズムあたりのマルチキャストグループかパケットにトンネルを堀るのに使用される形式の出口のインタフェースo Numberあたりのフレーム・サイズo Numberに要約したDUT/SUTインタフェースoのMTUサイズを連結します。

Stopp & Hickman              Informational                     [Page 11]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[11ページ]のRFC3918Methodology

   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 RFC2432[Du98]o Encapsulatedフレーム・サイズで定義される測定Encapsulated Throughput

   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.

Encapsulated Throughput結果SHOULD、aのフォームが見送る報告されたコネとそこでのこのテストへの詳細がSHOULDであったなら、それぞれの由来している不-要約されたフレーム・サイズのための列はそうです。 各列か繰り返しSHOULDが提供された負荷、カプセル化方法、要約のフレーム・サイズ、総数の提供されたフレーム、およびカプセル化スループットを指定します。

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.

1つ以上の出口のDUT/SUTによってDUT/SUTの1つのイングレスインタフェースまで提供されたどのフレームがdecapsulatedされるかにおいて正しく進められた最高率を測定するのは損失なしで連結します。

   Procedure:

手順:

     Source                  DUT/SUT            Destination
    Test Port                                   Test Port(s)
   +---------+             +-----------+        +---------+
   |         |             |           |        |         |
   |         |             |     Egress|------->|         |
   |         |             |           |        |         |
   |         |--(Tunnel)-->|Ingress    |        |         |
   |         |             |           |        |         |
   |         |             |     Egress|------->|         |
   |         |             |           |        |         |
   +---------+             +-----------+        +---------+

ソースDUT/SUT目的地テストポートテスト港+---------+ +-----------+ +---------+ | | | | | | | | | 出口|、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、| |--(トンネル)-->|イングレス| | | | | | | | | | | | 出口|、-、-、-、-、-、--、>|、|、|、|、|、|、|、| +---------+ +-----------+ +---------+

                             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に関する被膜剥離術スループットをテストするためのセットアップを示しています。 1つ以上のトンネルがソーステスト港とDUT/SUTの間で作成されます。 次に、要約のマルチキャスト交通をソーステスト港で提供して、DUT/SUTがdecapsulatedして、目的地テスト港に送るでしょう。

Stopp & Hickman              Informational                     [Page 12]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[12ページ]のRFC3918Methodology

   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つ以上のマルチキャストアドレスを要約する単一のトンネルはOR 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が複数のトンネル構成で構成されるとき、1トンネルあたりのマルチキャストグループの数は同じであるに違いありません。 すべての目的地テスト港がソーステスト港によって提供されたすべてのマルチキャストグループアドレスを接合しなければなりません。 同じ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のカプセル化と被膜剥離術の過程の間で性能比較をするとき、提供されたフレーム・サイズSHOULDはセクション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 Originatingカプセル化アルゴリズムか形式がパケットo Originatingにトンネルを堀るのに使用したマルチキャストグループoのDUT/SUT o Test持続時間o IGMPバージョンo Total番号のテストされた出口のインタフェースの数はマルチキャストグループの1トンネルあたりのNumberにトンネルoのフレーム・サイズo Numberを要約しました。

   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 RFC2432[Du98]o Decapsulatedフレーム・サイズで定義される測定Decapsulated Throughput

   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.

Decapsulated Throughput結果SHOULD、aの形式が見送る報告されたコネとそこでのこのテストへの詳細がSHOULDであったなら、それぞれの由来している要約のフレーム・サイズのための列はそうです。 各列か繰り返しSHOULDが提供された負荷、decapsulatedフレーム・サイズ、総数の提供されたフレーム、および被膜剥離術スループットを指定します。

Stopp & Hickman              Informational                     [Page 13]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[13ページ]のRFC3918Methodology

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つの要約の形式のフレームが別の要約の形式に変換されて、1つ以上の出口のDUT/SUTによって正しく送られる最高率を測定するのは損失なしで連結します。

   Procedure:

手順:

     Source                DUT/SUT             Destination
    Test Port                                  Test Port(s)
   +---------+           +---------+           +---------+
   |         |           |         |           |         |
   |         |           |   Egress|-(Tunnel)->|         |
   |         |           |         |           |         |
   |         |-(Tunnel)->|Ingress  |           |         |
   |         |           |         |           |         |
   |         |           |   Egress|-(Tunnel)->|         |
   |         |           |         |           |         |
   +---------+           +---------+           +---------+

ソースDUT/SUT目的地テストポートテスト港+---------+ +---------+ +---------+ | | | | | | | | | 出口|-(トンネル)->|、|、|、|、|、|、|、|、| |-(トンネル)->|イングレス| | | | | | | | | | | | 出口|-(トンネル)->|、|、|、|、|、|、|、| +---------+ +---------+ +---------+

                          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に関するRe-カプセル化スループットをテストするためのセットアップを示しています。 ポートが提供するソーステストは1つのタイプの交通を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つ以上のマルチキャストアドレスを要約する単一のトンネルはOR 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が複数のトンネル構成で構成されるとき、1トンネルあたりのマルチキャストグループの数は同じであるに違いありません。 添加、DUT/SUT SHOULD、イングレスのトンネルとそれぞれの出口のインタフェースの数が同じであるように、構成されてください。 すべての目的地テスト港がソーステスト港によって提供されたすべてのマルチキャストグループアドレスを接合しなければなりません。 同じMTUでそれぞれの出口のインタフェースを構成しなければなりません。

Stopp & Hickman              Informational                     [Page 14]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[14ページ]のRFC3918Methodology

   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データグラムを断片化するのを必要とするかもしれないことに注意してください。 それが提供されたフレーム・サイズを制限するRECOMMENDEDであるので、断片化は全く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 Originatingカプセル化アルゴリズムか形式がパケットo Re-カプセル化アルゴリズムにトンネルを堀るのに使用したDUT/SUTインタフェースoか形式のMTUサイズがパケットo Originatingにトンネルを堀るのに使用したマルチキャストグループoのDUT/SUT o Test持続時間o IGMPバージョンo Total番号のテストされた出口のインタフェースの数は1トンネルあたりのマルチキャストグループのインタフェースo Numberあたりのトンネルのフレーム・サイズo Numberを要約しました。

   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 RFC2432[Du98]のo Reによって要約されたフレーム・サイズで定義される測定Reによって要約されたThroughput

   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.

aの形式が見送る報告されたコネとそこでのこのテストへの詳細がSHOULDであったなら各由来のための列が要約のフレーム・サイズであったならThroughput結果SHOULDをRe要約しました。 各列か繰り返しSHOULDが提供された負荷、Reによって要約されたフレーム・サイズ、総数の提供されたフレーム、およびReによって要約された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の推進潜在の特殊化に関連する方法論を提示します。 それはRFC2544に提示された潜在特殊化の概念について敷衍しています。

Stopp & Hickman              Informational                     [Page 15]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[15ページ]のRFC3918Methodology

   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.

RFC1242とRFC2544は装置タイプの間で区別をつけます: 「」 「ビット推進」を格納して、進めてください。 各タイプは潜在がどう集められて、次に提示されるかに影響を与えます。 詳しい情報に関して関連する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].

シングルからのマルチキャスト潜在測定値、倍数を通したDUT/SUTのマルチキャストイングレスインタフェース、1セットのRFC2432にメートル法の「マルチキャスト潜在」によって備えられるその同じDUT/SUT[Du98]の出口のマルチキャストインタフェースを生産するために。

   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.

RFC2544[Br96]の潜在のための収集方法論からのドローの下における手順。 方法論は2つの位相的なシナリオを記述します: 単一の装置(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).

テストトライアルが独身のDevice Under Test(DUT)の向こう側に潜在を特徴付けることであるなら、例のテストトポロジーはセクション3で図1の形を取るかもしれません。 すなわち、1つのイングレスインタフェースがテスト装置とn出口のコンポーネントを伝えながらフレームからのマルチキャストテスト交通を受けている独身のDUTはテスト装置のフレームを受信する部品にマルチキャストテスト交通を送って戻す同じDUTに連結します。 nがテスト交通を進めると実際に予想されたDUTにTESTED出口のインタフェースの数を反映することに注意してください(構成されますが、試されていないことと対照的に、非推進は例えば、連結します)。

   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.

マルチキャスト潜在がSystem Under Test(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.

トライアル持続時間SHOULD、RFC2544[Br96]と一致している120秒になってください。 潜在測定の本質、「店とフォワード」に「推進に噛み付い」て、関連するテストトライアルに関連づけられて、結果レポートで明らかにしなければなりません。

Stopp & Hickman              Informational                     [Page 16]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[16ページ]のRFC3918Methodology

   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)での交通を提供するRECOMMENDEDです。 トライアルの持続時間の中点では、テスト装置は唯一身元保証可能な(「タグ付けをされた」)フレームを贈られるテスト交通フレームに注入しなければなりません。 このタグ付けをされたフレームは潜在測定値の基礎になるでしょう。 「唯一身元保証可能」で、テスト装置が、テスト交通を包括する他のフレームからの「タグ付けをされた」フレームがセットしたのを裁量できなければならないことが意味されます。 フレーム世代タイムスタンプ、テスト装置でタグ付けをされたフレームのトランスミッションの完成を反映して、Timestamp 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のテストされた出口のインタフェースから予想されたタグ付けをされたフレームにフレームをモニターして、タイムスタンプとのテストされた出口のインタフェースからタグ付けをされたフレームのうまくいっている検出の時間を記録しなければならなくて、Aが設定したTimestamp B値のTimestamp B.をDUT/SUTのすべてのテストされた出口のインタフェースに集めなければなりません。 装置を進めて、追加議論のためのRFC1242[Br91]が店と前進の装置を見なして、噛み付かれるのを見てください。

   A trial MUST be considered INVALID should any of the following
   conditions occur in the collection of the trial data:

以下の条件のどれかがトライアルデータの収集に現れるなら、INVALIDであるとトライアルを考えなければなりません:

      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 . o Forwardedテストが不適切に縁どるDUT/SUT出口港のIntended LoadとOffered Loadの予期していなかった違いかOffered Loadと結果として起こるForwarding Rate(s)の予期していなかった違いが、不適切に操られたヘッダーフィールドを、形成するか、または縁どっています。すべてで必要なタグ付けをされたフレームを進めるo Failureはテスト交通の休止の5秒以上後にソーステスト港のそばでテスト装置でタグ付けをされたフレームの出口のインタフェースo Receptionを予想しました。

   The set of latency measurements, M, composed from each latency
   measurement taken from every ingress/tested egress interface pairing
   MUST be determined from a valid test trial:

潜在測定値のセット、あらゆるイングレス/テストされた出口インタフェース組み合わせから取られたそれぞれの潜在測定から構成されたMは有効なテストトライアルによって断固としているに違いありません:

      M = { (Timestamp B(E0) - Timestamp A),
            (Timestamp B(E1) - Timestamp A), ...
            (Timestamp B(En) - Timestamp A) }

M=(タイムスタンプB(0E)--タイムスタンプa)、(タイムスタンプB(1E)--タイムスタンプa)… (タイムスタンプB(アン)--、タイムスタンプ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.

(0…Eのアン)がBが表すすべてのテストされた出口のインタフェースとTimestampの範囲を表すところでは、与えられたDUT/SUTのためのタグ付けをされたフレーム検出出来事は出口のインタフェースをテストしました。

   A more continuous profile MAY be built from a series of individual
   measurements.

より連続したプロフィールは一連の個々の測定値から造られるかもしれません。

Stopp & Hickman              Informational                     [Page 17]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[17ページ]のRFC3918Methodology

   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 マルチキャストグループのDUT/SUT o Test持続時間o IGMPバージョンo Offered負荷o Total番号のテストされた出口のインタフェースのフレーム・サイズo Number

   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. 分/マックスマルチキャスト潜在

   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セットのマルチキャスト潜在測定をただ一つのテスト持続時間の上に集めてください。 これは1セットのマルチキャスト潜在を生産するでしょう、M、MがDUTフレームイングレスとDUTフレーム出口ポート組の間の個々の推進潜在で構成されるところで。 例えば:

      M = {L(I,E1),L(I,E2), ..., L(I,En)}

M=L(1Eの私)、L(2Eの私)、…、L(I、アン)

   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が潜在であるところでは、aはイングレスインタフェースをテストして、私はDUT、Ex a特有であるのについてDUTのマルチキャスト出口のインタフェースをテストしました。 Enを通して、1E、DUTの上のユニークな出口のインタフェースがあります。

Stopp & Hickman              Informational                     [Page 18]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[18ページ]のRFC3918Methodology

   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)

結果=最大(M)--分(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 マルチキャストグループのDUT/SUT o Test持続時間o IGMPバージョンo Offered負荷o Total番号のテストされた出口のインタフェースのフレーム・サイズo Number

   The following results MUST be reflected in the test report:

以下の結果を試験報告書に反映しなければなりません:

      o  The Max/Min value

o マックス/分値

   The following results SHOULD be reflected in the test report:

以下の結果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.

提示された潜在のタイム・ユニットは、一定でなければならなく、媒体かメディアに、十分な精度で検査されています。

   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.

このセクションはマルチキャスト環境で見つけられる明白な操作に関連している頭上の遅れの特殊化に関連する方法論を提示します。

Stopp & Hickman              Informational                     [Page 19]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[19ページ]のRFC3918Methodology

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.

それが取る時間持続時間を決定するために、うまくいっているIGMPグループ会員資格レポートを時間からのマルチキャストフレームに転送し始めるDUT/SUTはDUT/SUTに発行されました。

   Procedure:

手順:

   The Multicast Group Join Delay measurement may be influenced by the
   state of the Multicast Forwarding Database <MFDB> of the DUT/SUT. The
   states of the MFDB may be described as follows:

Multicast Group Join Delay測定はDUT/SUTのMulticast Forwarding Database<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が指定されたマルチキャストグループアドレスを含みます。 この状態では、遅れ測定はDUT/SUTが新たに接合されたノード<s>でMFDBをアップデートして、>とパケット模写時間を新しいノード<sに送り始めるのを必要とする時間を含んでいます。 州1から測定された遅れはDUT/SUTが新しいノードのために同じIPマルチキャストアドレスのための他のノードにパケットを伝えている間、MFDBをおよそどれくらいよくアップデートできるかという情報を提供します。 例は、マルチキャストパケットを通して促進されている出来事に新しいユーザを加えるのを含んでいます。

   The methodology for the Multicast Group Join Delay measurement
   provides two alternate methods, based on the state of the MFDB, to
   measure the delay metric.  The methods MAY be used independently or
   in conjunction to provide meaningful insight into the DUT/SUT ability
   to manage the MFDB.

Multicast Group Join Delay測定のための方法論は、メートル法で遅れを測定するために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.

ユーザは、Multicast Group Join Delayを決定する方法を使用するのを選ぶかもしれません。 しかしながら、報告形式の一部として収集方法を指定しなければなりません。

   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、テストSHOULDでの負担を最小にするのと同じくらい良い遅れ計算では、1つのマルチキャストグループと共に実行されてください。 さらに、すべての目的地テスト港がDUT/SUTのイングレスインタフェースまで提供された指定されたマルチキャストグループに加わらなければなりません。

Stopp & Hickman              Informational                     [Page 20]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[20ページ]のRFC3918Methodology

   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の>がするMulticast Forwarding Database<MFDBが指定されたマルチキャストグループアドレスを含んでいるか、または学んだと仮定します。 明確に、MFDB MUSTは州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.

Multicast Group Join Delayについて計算するのに使用されるどんなIGMP Group Membership Reportsも送る前に、目的地テスト港が現在指定されたマルチキャストグループのメンバーでないことを外部的に観察可能な手段で確かめなければなりません。 さらに、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 MUSTは州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.

Group Join Delayについて計算するのに使用されるどんなIGMP Group Membership Reportsも送る前に、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 Group Membership Reportメッセージも受け取るDUT/SUTの前にイングレスインタフェースまで提供しなければなりません。 それは測定集められたマルチキャスト押出量(セクション4.3)での交通を提供するRECOMMENDEDです。

   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を見る)は指定されたマルチキャストグループのために1IGMP Group Membership Reportを送らなければなりません。

Stopp & Hickman              Informational                     [Page 21]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[21ページ]のRFC3918Methodology

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

接合してください。時間内に、(タイムスタンプA)をIGMP Group Membershipメッセージに送って、マルチキャストグループの最初のフレームを送る時から受信出口のインタフェース(タイムスタンプB)まで遅れは違いです。

      Group Join delay time = timestamp B - timestamp A

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

タイムスタンプAはIGMPグループ会員資格レポートの最後のビットが目的地テスト港から送られる時であるに違いありません。 タイムスタンプBは最初の有効なマルチキャストフレームの最初のビットがDUT/SUTの出口のインタフェースで進められる時であるに違いありません。

   Reporting Format:

報告形式:

   The following configuration parameters MUST be reflected in the test
   report:

以下の設定パラメータを試験報告書に反映しなければなりません:

      o  Frame size(s)
      o  Number of tested egress interfaces on the DUT/SUT
      o  IGMP version
      o  Total number of multicast groups
      o  Offered load to ingress interface
      o  Method used to measure the join delay metric

o Offeredがイングレスインタフェースo MethodにロードするマルチキャストグループoのDUT/SUT o IGMPバージョンo Total番号のテストされた出口のインタフェースのフレーム・サイズo Numberが以前はよく測定していた、メートル法で遅れを接合してください。

   The following results MUST be reflected in the test report:

以下の結果を試験報告書に反映しなければなりません:

      o  The group join delay time in microseconds per egress
         interface(s)

o グループは出口のインタフェースあたりのマイクロセカンドのときに遅延時間に合流します。(s)

   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.

各テストのためのGroup Join Delay結果はテーブルの形で報告されるかもしれません、それぞれのセクション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.

それが取る時間持続時間を決定するために、首尾よく対応するIGMP Leave Groupメッセージの後にマルチキャストフレームを送るのをやめるDUT/SUTをDUT/SUTに提供しました。

Stopp & Hickman              Informational                     [Page 22]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[22ページ]のRFC3918Methodology

   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、テストSHOULDでの負担を最小にするのと同じくらい良い遅れ計算では、1つのマルチキャストグループと共に実行されてください。 さらに、すべての目的地テスト港がDUT/SUTのイングレスインタフェースまで提供された指定されたマルチキャストグループに加わらなければなりません。

   Prior to sending any IGMP Leave Group messages used to calculate the
   group leave delay, it MUST be verified through externally observable
   means that the destination test ports are currently members of the
   specified multicast group.  If any of the egress interfaces do not
   forward validation multicast frames then the test is invalid.

グループが遅れを残すと見込むのに使用されるどんなIGMP Leave Groupメッセージも送る前に、目的地テスト港が現在指定されたマルチキャストグループのメンバーであることを外部的に観察可能な手段で確かめなければなりません。 出口のインタフェースのいずれも合法化マルチキャストフレームを進めないなら、テストは無効です。

   Once verification is complete, multicast traffic for the specified
   multicast group address MUST be offered to the ingress interface
   prior to receipt or processing of any IGMP Leave Group messages. It
   is RECOMMENDED to offer traffic at the measured aggregated multicast
   throughput rate (Section 4.3).

検証がいったん完全になると、どんなIGMP Leave Groupメッセージの領収書か処理の前にも指定されたマルチキャストグループアドレスのためのマルチキャスト交通をイングレスインタフェースまで提供しなければなりません。 それは測定集められたマルチキャスト押出量(セクション4.3)での交通を提供するRECOMMENDEDです。

   After the multicast traffic has been started, each destination test
   port (See Figure 1) MUST send one IGMP Leave Group message for the
   specified multicast group.

マルチキャスト交通が始められた後に、それぞれの目的地テスト港(図1を見る)は指定されたマルチキャストグループへの1つのIGMP Leave Groupメッセージを送らなければなりません。

   The leave delay is the difference in time from when the IGMP Leave
   Group message is sent (timestamp A) and the last frame of the
   multicast group is forwarded to a receiving egress interface
   (timestamp B).

いなくなってください。時間内に、(タイムスタンプA)をIGMP Leave Groupメッセージに送って、マルチキャストグループの最後のフレームを送る時から受信出口のインタフェース(タイムスタンプB)まで遅れは違いです。

           Group Leave delay time = timestamp B - timestamp A

グループLeave遅延時間=タイムスタンプB--タイムスタンプA

   Timestamp A MUST be the time the last bit of the IGMP Leave Group
   message is sent from the destination test port; timestamp B MUST be
   the time the last bit of the last valid multicast frame is forwarded
   on the egress interface of the DUT/SUT.

タイムスタンプAはIGMP Leave Groupメッセージの最後のビットが目的地テスト港から送られる時であるに違いありません。 タイムスタンプBは最後の有効なマルチキャストフレームの最後のビットがDUT/SUTの出口のインタフェースで進められる時であるに違いありません。

   Reporting Format:

報告形式:

   The following configuration parameters MUST be reflected in the test
   report:

以下の設定パラメータを試験報告書に反映しなければなりません:

      o  Frame size(s)
      o  Number of tested egress interfaces on the DUT/SUT
      o  IGMP version
      o  Total number of multicast groups
      o  Offered load to ingress interface

o OfferedがイングレスにロードするマルチキャストグループoのDUT/SUT o IGMPバージョンo Total番号のテストされた出口のインタフェースのフレーム・サイズo Numberは連結します。

Stopp & Hickman              Informational                     [Page 23]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[23ページ]のRFC3918Methodology

   The following results MUST be reflected in the test report:

以下の結果を試験報告書に反映しなければなりません:

      o  The group leave delay time in microseconds per egress
         interface(s)

o グループは1出口あたりのマイクロセカンドの遅延時間をインタフェースに残します。(s)

   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.

各テストのためのGroup Leave Delay結果はテーブルの形で報告されるかもしれません、それぞれのセクション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.

繰り返しがいったん失敗すると、最後のうまくいっている繰り返しは述べられたMaximum Group Capacity結果です。

Stopp & Hickman              Informational                     [Page 24]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[24ページ]のRFC3918Methodology

   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 DUT/SUT o IGMPバージョンo Offered荷重のテストされた出口のインタフェースのフレーム・サイズo Number

   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.

それぞれのテストSHOULDのためのMulticast Group Capacity結果がテーブルの形で報告されて、それぞれのテストのための列で、セクション3.1.3で1推薦あたりのサイズを縁どってください。 各列か繰り返しSHOULDが目的地のインタフェース単位で加わられたマルチキャストグループの数を指定するのをフレームの数は送信して、フレームの数は、その繰り返しのために受けました。

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の単一のマルチキャストイングレスインタフェースからRFC2432にメートル法の「マルチキャスト潜在」によって備えられるその同じDUT/SUT[Du98]の複数の出口のマルチキャストインタフェースまで1セットのマルチキャスト潜在測定を起こすために。

   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にパケットの余分な処理を実行させることによって、Multicast Latency測定基準に影響を及ぼすことができます。

Stopp & Hickman              Informational                     [Page 25]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[25ページ]のRFC3918Methodology

   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.

Burdened Forwarding Multicast Latencyテストはセクション5.1でのMulticast Latencyテストのための説明されたセットアップに続かなければなりません。 さらに、DUT/SUTを負うのにもう1セットのテストポートを使用しなければなりません(ポートを負って)。 負っているポートは、RFC2285[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で説明されるようにMulticast Latencyの基線測定を実行してください。 基線測定を得た後に、ポートを負うセットでユーザによって指定された提供された負荷でユニキャストクラス交通を伝え始めてください、そして、Multicast Latencyテストを再放送してください。 ポートが同じであるに違いないイングレスへの提供された負荷は基線測定に使用されました。

   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 DUT/SUT o Test持続時間o IGMPバージョンo Offeredの上のテストされた出口のインタフェースのフレーム・サイズo NumberはOfferedが負うことのTotal番号が移植するポートoを負うのにロードするマルチキャストグループoのイングレスインタフェースo Total番号にロードします。

   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.

それぞれのテストSHOULDのための潜在結果がテーブルの形で報告されて、それぞれのテストのための列で、セクション3.1.3でお勧めのフレーム・サイズあたりのサイズを縁どってください。そうすれば、SHOULDは、複数のトライアルの向こう側に傾くのを助けるためにイングレス/出口のインタフェースへの潜在の関係を保存します。

Stopp & Hickman              Informational                     [Page 26]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[26ページ]のRFC3918Methodology

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.

それが取る時間持続時間を決定するために、推進はユニキャスト交通を網の目にかけましたが、時間からのマルチキャストフレームにうまくいっているIGMP Group Membership Reportを送り始めるDUT/SUTはDUT/SUTに発行されました。

   Procedure:

手順:

   The Forwarding Burdened Group Join Delay test MUST follow the
   described setup for the Group Join Delay test in Section 6.1.  In
   addition, another set of test ports MUST be used to burden the
   DUT/SUT (burdening ports).  The burdening ports will be used to
   transmit unicast class traffic to the DUT/SUT in a fully meshed
   traffic pattern as described in RFC 2285 [Ma98].  The DUT/SUT MUST
   learn the appropriate unicast addresses and verified through some
   externally observable method.

Forwarding Burdened Group Join Delayテストはセクション6.1でのGroup Join Delayテストのための説明されたセットアップに続かなければなりません。 さらに、DUT/SUTを負うのにもう1セットのテストポートを使用しなければなりません(ポートを負って)。 負っているポートは、RFC2285[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で説明されるようにGroup Join Delayの基線測定を実行してください。 基線測定を得た後に、ポートを負うセットでユーザによって指定された提供された負荷でユニキャストクラス交通を伝え始めてください、そして、Group Join Delayテストを再放送してください。 ポートが同じであるに違いないイングレスへの提供された負荷は基線測定に使用されました。

   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 DUT/SUT o IGMPバージョンo Offeredの上のテストされた出口のインタフェースのフレーム・サイズo NumberがOfferedが負うことのTotal番号が測定するために使用されるo Methodを移植するポートoを負うのにロードするマルチキャストグループoのイングレスインタフェースo Total番号にロードする、メートル法で遅れを接合してください。

   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 グループは出口のインタフェースあたりのマイクロセカンドのときに基線と背負い込んでいる応答の両方のために遅延時間に合流します。

Stopp & Hickman              Informational                     [Page 27]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[27ページ]のRFC3918Methodology

   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.

各テストのためのGroup Join Delay結果はテーブルの形で報告されるかもしれません、それぞれのセクション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と特にケビンDubrayのBenchmarking Methodology作業部会、Juniper Networksはそれらがこのドキュメントを完成するのを助けるためにまとめてした多くの提案について感謝されることになっています。

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とラルフ・ダニエル、Spirent Communicationsの両方。 さらに、作者はこのドキュメントを実現しているのを助けたタスクチームのメンバーを承認したがっています: ミシェル・ブストス、トニー・De Laローザ、デヴィッド・ニューマン、およびジェリーPerser。

12.  References

12. 参照

12.1.  Normative References

12.1. 引用規格

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

[Br91] ブラドナー、S.、「ネットワーク相互接続装置のためのベンチマーキング用語」、RFC1242、1991年7月。

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

[Br96] ブラドナーとS.とJ.McQuaid、「ネットワーク内部連絡装置のためのベンチマーキング方法論」、RFC2544、1999年3月。

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

S. [Br97]ブラドナー、「1997年3月に要件レベル、RFC2119を反映するRFCsにおけるキーワードの使用。」

   [Du98]   Dubray, K., "Terminology for IP Multicast Benchmarking", RFC
            2432, October 1998.

[Du98] Dubray、K.、「IPマルチキャストベンチマーキングのための用語」、RFC2432、1998年10月。

Stopp & Hickman              Informational                     [Page 28]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[28ページ]のRFC3918Methodology

   [IANA1]  IANA multicast address assignments,
            http://www.iana.org/assignments/multicast-addresses

[IANA1]IANAマルチキャストアドレス課題、 http://www.iana.org/assignments/multicast-addresses

   [Ma98]   Mandeville, R., "Benchmarking Terminology for LAN Switching
            Devices", RFC 2285, February 1998.

[Ma98] マンデヴィル、R.、「LAN切換装置のためのベンチマーキング用語」、RFC2285、1998年2月。

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

[Me98] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、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] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」

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

[De89] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。

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

w.[Fe97]フェナー、「インターネット集団経営はRFC2236、1997年11月についてバージョン2インチ議定書の中で述べます」。

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

[Hu95] Huitema、C.、「インターネットのルート設定」、新米のホール、1995。

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

[Ka98]Kosiur、D.、「IPマルチキャスティング:」 「対話的な企業ネットワークへの完全なガイド」、ジョンワイリーと息子株式会社、1998。

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

T. [Mt98]Maufer、「エンタープライズでIPマルチキャストを配備すること」での新米のホール、1998。

Stopp & Hickman              Informational                     [Page 29]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[29ページ]のRFC3918Methodology

13.  Authors' Addresses

13. 作者のアドレス

   Debra Stopp
   Ixia
   26601 W. Agoura Rd.
   Calabasas, CA  91302
   USA

デブラStopp Ixia26601W.Agoura通り カラバサス、カリフォルニア91302米国

   Phone: + 1 818 871 1800
   EMail: debby@ixiacom.com

以下に電話をしてください。 1800がメールする+1 818 871: debby@ixiacom.com

   Brooks Hickman
   Spirent Communications
   26750 Agoura Rd.
   Calabasas, CA  91302
   USA

ブルックスヒックマンSpirent Communications26750Agoura通り カラバサス、カリフォルニア91302米国

   Phone: + 1 818 676 2412
   EMail: brooks.hickman@spirentcom.com

以下に電話をしてください。 2412がメールする+1 818 676: brooks.hickman@spirentcom.com

Stopp & Hickman              Informational                     [Page 30]

RFC 3918       Methodology for IP Multicast Benchmarking   October 2004

IPマルチキャストベンチマーキング2004年10月のためのStoppとヒックマン情報[30ページ]のRFC3918Methodology

14.  Full Copyright Statement

14. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Stopp & Hickman              Informational                     [Page 31]

StoppとヒックマンInformationalです。[31ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

PHPを動作させる

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る