Network Working Group D. Stopp
Request for Comments: 3918 Ixia
Category: Informational B. Hickman
Spirent Communications
October 2004
Network Working Group D. Stopp
Request for Comments: 3918 Ixia
Category: Informational B. Hickman
Spirent Communications
October 2004
Methodology for IP Multicast Benchmarking
IP多播基准测试方法
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
本文档旨在描述多播IP转发设备的基准测试方法。它建立在RFC 2544、RFC 2432和其他IETF基准方法工作组（BMWG）工作中规定的原则基础上。本文档旨在将这些工作扩展到多播范例。
The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents.
BMWG产生两大类文件：基准术语文件和基准方法文件。术语文件介绍了基准和其他相关术语。方法文件规定了收集相应术语文件中引用的基准所需的程序。
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Key Words to Reflect Requirements. . . . . . . . . . . . . . . 3
3. Test Set Up. . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Test Considerations. . . . . . . . . . . . . . . . . . . 4
3.1.1. IGMP Support. . . . . . . . . . . . . . . . . . . 5
3.1.2. Group Addresses . . . . . . . . . . . . . . . . . 5
3.1.3. Frame Sizes . . . . . . . . . . . . . . . . . . . 5
3.1.4. TTL . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.5. Trial Duration. . . . . . . . . . . . . . . . . . 6
4. Forwarding and Throughput. . . . . . . . . . . . . . . . . . . 6
4.1. Mixed Class Throughput . . . . . . . . . . . . . . . . . 6
4.2. Scaled Group Forwarding Matrix . . . . . . . . . . . . . 8
4.3. Aggregated Multicast Throughput. . . . . . . . . . . . . 9
4.4. Encapsulation/Decapsulation (Tunneling) Throughput . . . 10
4.4.1. Encapsulation Throughput. . . . . . . . . . . . . 10
4.4.2. Decapsulation Throughput. . . . . . . . . . . . . 12
4.4.3. Re-encapsulation Throughput . . . . . . . . . . . 14
5. Forwarding Latency . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Multicast Latency. . . . . . . . . . . . . . . . . . . . 16
5.2. Min/Max Multicast Latency. . . . . . . . . . . . . . . . 18
6. Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Group Join Delay . . . . . . . . . . . . . . . . . . . . 20
6.2. Group Leave Delay. . . . . . . . . . . . . . . . . . . . 22
7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Multicast Group Capacity . . . . . . . . . . . . . . . . 24
8. Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Forwarding Burdened Multicast Latency. . . . . . . . . . 25
8.2. Forwarding Burdened Group Join Delay . . . . . . . . . . 27
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. Contributions. . . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
4.4. Encapsulation/Decapsulation (Tunneling) Throughput . . . 10
4.4.1. Encapsulation Throughput. . . . . . . . . . . . . 10
4.4.2. Decapsulation Throughput. . . . . . . . . . . . . 12
4.4.3. Re-encapsulation Throughput . . . . . . . . . . . 14
5. Forwarding Latency . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Multicast Latency. . . . . . . . . . . . . . . . . . . . 16
5.2. Min/Max Multicast Latency. . . . . . . . . . . . . . . . 18
6. Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Group Join Delay . . . . . . . . . . . . . . . . . . . . 20
6.2. Group Leave Delay. . . . . . . . . . . . . . . . . . . . 22
7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Multicast Group Capacity . . . . . . . . . . . . . . . . 24
8. Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Forwarding Burdened Multicast Latency. . . . . . . . . . 25
8.2. Forwarding Burdened Group Join Delay . . . . . . . . . . 27
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. Contributions. . . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
This document defines tests for measuring and reporting the throughput, forwarding, latency and Internet Group Management Protocol (IGMP) group membership characteristics of devices that support IP multicast protocols. The results of these tests will provide the user with meaningful data on multicast performance.
本文档定义了用于测量和报告支持IP多播协议的设备的吞吐量、转发、延迟和Internet组管理协议（IGMP）组成员特征的测试。这些测试的结果将为用户提供有关多播性能的有意义的数据。
A previous document, "Terminology for IP Multicast Benchmarking" [Du98], defined many of the terms that are used in this document. The terminology document should be consulted before attempting to make use of this document.
先前的文档“IP多播基准测试术语”[Du98]定义了本文档中使用的许多术语。在尝试使用本文件之前，应查阅术语文件。
This methodology will focus on one source to many destinations, although many of the tests described may be extended to use multiple source to multiple destination topologies.
该方法将重点关注一个源到多个目的地，尽管所描述的许多测试可以扩展为使用多个源到多个目的地拓扑。
Subsequent documents may address IPv6 multicast and related multicast routing protocol performance. Additional insight on IP and multicast networking can be found in [Hu95], [Ka98] and [Mt98].
后续文档可能涉及IPv6多播和相关多播路由协议性能。[Hu95]、[Ka98]和[Mt98]中提供了有关IP和多播网络的更多信息。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[Br97]中的说明进行解释。RFC 2119定义了这些关键词的使用，以帮助尽可能明确标准跟踪文档的意图。虽然本文档使用这些关键字，但本文档不是标准跟踪文档。
The set of methodologies presented in this document are for single ingress, multiple egress multicast scenarios as exemplified by Figures 1 and 2. Methodologies for multiple ingress and multiple egress multicast scenarios are beyond the scope of this document.
如图1和图2所示，本文档中介绍的一组方法适用于单入口、多出口多播场景。多入口和多出口多播场景的方法超出了本文档的范围。
Figure 1 shows a typical setup for an IP multicast test, with one source to multiple destinations.
图1显示了IP多播测试的典型设置，一个源到多个目的地。
+------------+ +--------------+
| | | destination |
+--------+ | Egress(-)------->| test |
| source | | | | port(E1) |
| test |------>(|)Ingress | +--------------+
| port | | | +--------------+
+--------+ | Egress(-)------->| destination |
| | | test |
| | | port(E2) |
| DUT | +--------------+
| | . . .
| | +--------------+
| | | destination |
| Egress(-)------->| test |
| | | port(En) |
+------------+ +--------------+
+------------+ +--------------+
| | | destination |
+--------+ | Egress(-)------->| test |
| source | | | | port(E1) |
| test |------>(|)Ingress | +--------------+
| port | | | +--------------+
+--------+ | Egress(-)------->| destination |
| | | test |
| | | port(E2) |
| DUT | +--------------+
| | . . .
| | +--------------+
| | | destination |
| Egress(-)------->| test |
| | | port(En) |
+------------+ +--------------+
Figure 1
图1
If the multicast metrics are to be taken across multiple devices forming a System Under Test (SUT), then test frames are offered to a single ingress interface on a device of the SUT, subsequently forwarded across the SUT topology, and finally forwarded to the test apparatus' frame-receiving components by the test egress interface(s) of devices in the SUT. Figure 2 offers an example SUT test topology. If a SUT is tested, the test topology and all relevant configuration details MUST be disclosed with the corresponding test results.
如果多播度量要跨形成被测系统（SUT）的多个设备进行，则将测试帧提供给SUT设备上的单个入口接口，随后跨SUT拓扑转发，最后通过测试出口接口转发给测试设备的帧接收组件SUT中的设备数量。图2提供了一个示例SUT测试拓扑。如果测试了SUT，则必须将测试拓扑和所有相关配置细节与相应的测试结果一起披露。
*-----------------------------------------*
| |
+--------+ | +----------------+ | +--------+
| | | +------------+ |DUT B Egress E0(-)-|->| |
| | | |DUT A |--->| | | | |
| source | | | | | Egress E1(-)-|->| dest. |
| test |--|->(-)Ingress, I | +----------------+ | | test |
| port | | | | +----------------+ | | port |
| | | | |--->|DUT C Egress E2(-)-|->| |
| | | +------------+ | | | | |
| | | | Egress En(-)-|->| |
+--------+ | +----------------+ | +--------+
| |
*------------------SUT--------------------*
*-----------------------------------------*
| |
+--------+ | +----------------+ | +--------+
| | | +------------+ |DUT B Egress E0(-)-|->| |
| | | |DUT A |--->| | | | |
| source | | | | | Egress E1(-)-|->| dest. |
| test |--|->(-)Ingress, I | +----------------+ | | test |
| port | | | | +----------------+ | | port |
| | | | |--->|DUT C Egress E2(-)-|->| |
| | | +------------+ | | | | |
| | | | Egress En(-)-|->| |
+--------+ | +----------------+ | +--------+
| |
*------------------SUT--------------------*
Figure 2
图2
Generally, the destination test ports first join the desired number of multicast groups by sending IGMP Group Report messages to the DUT/SUT. To verify that all destination test ports successfully joined the appropriate groups, the source test port MUST transmit IP multicast frames destined for these groups. After test completion, the destination test ports MAY send IGMP Leave Group messages to clear the IGMP table of the DUT/SUT.
通常，目标测试端口首先通过向DUT/SUT发送IGMP组报告消息来加入所需数量的多播组。要验证所有目标测试端口是否成功加入了相应的组，源测试端口必须传输以这些组为目的地的IP多播帧。测试完成后，目标测试端口可发送IGMP离开组消息以清除DUT/SUT的IGMP表。
In addition, test equipment MUST validate the correct and proper forwarding actions of the devices they test in order to ensure the receipt of the frames that are involved in the test.
此外，测试设备必须验证其测试的设备的正确和正确的转发动作，以确保接收到测试中涉及的帧。
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事件、构建设备缓存等），以优化后续流量的转发。因此，在运行要求转发多播或单播分组的任何测试之前，测试设备必须使用与随后将被转发的DUT/SUT相同的寻址特性来生成测试通信量
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.
已经注意到，多播分布树的形成可能是多播性能的重要组成部分。虽然此组件可能出现在本备忘录中介绍的一些度量或场景中，但本备忘录并不寻求明确地对多播分发树的形成进行基准测试。多播分发树形成的基准测试留待将来进行，针对特定树形成载体的更具针对性的工作。
All of the ingress and egress interfaces MUST support a version of IGMP. The IGMP version on the ingress interface MUST be the same version of IGMP that is being tested on the egress interfaces.
所有入口和出口接口必须支持IGMP版本。入口接口上的IGMP版本必须与出口接口上测试的IGMP版本相同。
Each of the ingress and egress interfaces SHOULD be able to respond to IGMP queries during the test.
每个入口和出口接口应能够在测试期间响应IGMP查询。
Each of the ingress and egress interfaces SHOULD also send LEAVE (running IGMP version 2 or later) [Ca02] [Fe97] after each test.
每个入口和出口接口也应在每次测试后发送LEAVE（运行IGMP版本2或更高版本）[Ca02][Fe97]。
There is no restriction to the use of multicast addresses [De89] to compose the test traffic other than those assignments imposed by IANA. The IANA assignments for multicast addresses [IANA1] MUST be regarded for operational consistency. Address selection does not need to be restricted to Administratively Scoped IP Multicast addresses [Me98].
除了IANA强加的那些分配之外，对使用多播地址[De89]组成测试流量没有任何限制。多播地址的IANA分配[IANA1]必须考虑到操作一致性。地址选择不需要限制为管理范围的IP多播地址[Me98]。
Each test SHOULD be run with different multicast frame sizes. For Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280, and 1518 byte frames.
每个测试都应该使用不同的多播帧大小运行。对于以太网，建议的大小为64、128、256、512、1024、1280和1518字节帧。
Other link layer technologies MAY be used. The minimum and maximum frame lengths of the link layer technology in use SHOULD be tested.
可以使用其他链路层技术。应测试正在使用的链路层技术的最小和最大帧长度。
When testing with different frame sizes, the DUT/SUT configuration MUST remain the same.
当使用不同的机架尺寸进行测试时，DUT/SUT配置必须保持不变。
The data plane test traffic should have a TTL value large enough to traverse the DUT/SUT.
数据平面测试通信应具有足够大的TTL值，以穿过DUT/SUT。
The TTL in IGMP control plane messages MUST be in compliance with the version of IGMP in use.
IGMP控制平面消息中的TTL必须符合使用中的IGMP版本。
The duration of the test portion of each trial SHOULD be at least 30 seconds. This parameter MUST be included as part of the results reporting for each methodology.
每次试验的试验部分的持续时间应至少为30秒。必须将此参数作为每种方法的结果报告的一部分。
This section contains the description of the tests that are related to the characterization of the frame forwarding of a DUT/SUT in a multicast environment. Some metrics extend the concept of throughput presented in RFC 1242. Forwarding Rate is cited in RFC 2285 [Ma98].
本节描述了与多播环境中DUT/SUT的帧转发特性相关的测试。一些指标扩展了RFC 1242中提出的吞吐量概念。RFC 2285[Ma98]中引用了转发速率。
Objective:
目标：
To determine the throughput of a DUT/SUT when both unicast class frames and multicast class frames are offered simultaneously to a fixed number of interfaces as defined in RFC 2432.
当单播类帧和多播类帧同时提供给RFC 2432中定义的固定数量的接口时，确定DUT/SUT的吞吐量。
Procedure:
程序：
Multicast and unicast traffic are mixed together in the same aggregated traffic stream in order to simulate a heterogeneous networking environment.
为了模拟异构网络环境，将多播和单播业务混合在同一聚合业务流中。
The following events MUST occur before offering test traffic:
在提供测试流量之前，必须发生以下事件：
o All destination test ports configured to receive multicast traffic MUST join all configured multicast groups; o The DUT/SUT MUST learn the appropriate unicast and multicast addresses; and
o 配置为接收多播流量的所有目标测试端口必须加入所有配置的多播组；o DUT/SUT必须学习适当的单播和多播地址；和
o Group membership and unicast address learning MUST be verified through some externally observable method.
o 组成员资格和单播地址学习必须通过一些外部可观察的方法进行验证。
The intended load [Ma98] SHOULD be configured as alternating multicast class frames and unicast class frames to a single ingress interface. The unicast class frames MUST be configured to transmit in an unweighted round-robin fashion to all of the destination ports.
预期负载[Ma98]应配置为交替多播类帧和单播类帧到单个入口接口。单播类帧必须配置为以未加权的循环方式传输到所有目标端口。
For example, with six multicast groups and 3 destination ports with one unicast addresses per port, the source test port will offer frames in the following order:
例如，对于六个多播组和三个目标端口，每个端口有一个单播地址，源测试端口将按以下顺序提供帧：
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<Number> = Multicast Frame<Group>
u<Number> = Unicast Frame<Target Port>
Mixed class throughput measurement is defined in RFC 2432 [Du98]. A search algorithm MUST be utilized to determine the Mixed Class Throughput. The ratio of unicast to multicast frames MUST remain the same when varying the intended load.
RFC 2432[Du98]中定义了混合类吞吐量测量。必须使用搜索算法来确定混合类吞吐量。改变预期负载时，单播与多播帧的比率必须保持不变。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o Traffic distribution for unicast and multicast traffic classes o The ratio of multicast to unicast class traffic
o 帧大小o DUT/SUT上测试出口接口的数量o测试持续时间o IGMP版本o多播组的总数o单播和多播流量类别的流量分布o多播与单播流量类别的比率
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o Mixed Class Throughput as defined in RFC 2432 [Du98], including: Throughput per unicast and multicast traffic classes.
o RFC 2432[Du98]中定义的混合类吞吐量，包括：每单播和多播流量类的吞吐量。
The Mixed Class Throughput results for each test SHOULD be reported in the form of a table with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row SHOULD specify the intended load, number of multicast frames offered, number of unicast frames offered and measured throughput per class.
应按照第3.1.3节中的建议，以表格的形式报告每个测试的混合类吞吐量结果，并为每个测试的机架尺寸指定一行。每行应指定预期负载、提供的多播帧数、提供的单播帧数以及每个类的测量吞吐量。
Objective:
目标：
To determine Forwarding Rate as a function of tested multicast groups for a fixed number of tested DUT/SUT ports.
为固定数量的测试DUT/SUT端口确定作为测试多播组函数的转发速率。
Procedure:
程序：
This is an iterative procedure. The destination test port(s) MUST join an initial number of multicast groups on the first iteration. All destination test ports configured to receive multicast traffic MUST join all configured multicast groups. The recommended number of groups to join on the first iteration is 10 groups. Multicast traffic is subsequently transmitted to all groups joined on this iteration and the forwarding rate is measured.
这是一个迭代过程。目标测试端口必须在第一次迭代时加入初始数量的多播组。配置为接收多播通信的所有目标测试端口必须加入所有配置的多播组。建议在第一次迭代中加入10个组。随后将多播通信量传输到在该迭代中加入的所有组，并测量转发速率。
The number of multicast groups joined by each destination test port is then incremented, or scaled, by an additional number of multicast groups. The recommended granularity of additional groups to join per iteration is 10, although the tester MAY choose a finer granularity. Multicast traffic is subsequently transmitted to all groups joined during this iteration and the forwarding rate is measured.
然后，每个目标测试端口加入的多播组的数量会增加，或按多播组的额外数量进行缩放。每个迭代要加入的其他组的建议粒度为10，尽管测试人员可以选择更细的粒度。随后，多播通信量被传输到该迭代期间加入的所有组，并测量转发速率。
The total number of multicast groups joined MUST not exceed the multicast group capacity of the DUT/SUT. The Group Capacity (Section 7.1) results MUST be known prior to running this test.
加入的多播组总数不得超过DUT/SUT的多播组容量。在运行本测试之前，必须知道组容量（第7.1节）结果。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version
o 帧大小o DUT/SUT上测试出口接口的数量o测试持续时间o IGMP版本
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The total number of multicast groups joined for that iteration
o 为该迭代加入的多播组的总数
o Forwarding rate determined for that iteration
o 为该迭代确定的转发速率
The Scaled Group Forwarding results for each test SHOULD be reported in the form of a table with a row representing each iteration of the test. Each row or iteration SHOULD specify the total number of groups joined for that iteration, offered load, total number of frames transmitted, total number of frames received and the aggregate forwarding rate determined for that iteration.
每个测试的缩放组转发结果应以表格的形式报告，表格中的一行表示测试的每个迭代。每一行或每一次迭代都应指定为该次迭代加入的组总数、提供的负载、传输的帧总数、接收的帧总数以及为该次迭代确定的聚合转发速率。
Objective:
目标：
To determine the maximum rate at which none of the offered frames to be forwarded through N destination interfaces of the same multicast groups are dropped.
确定要通过相同多播组的N个目标接口转发的所有提供帧都不会被丢弃的最大速率。
Procedure:
程序：
Offer multicast traffic at an initial maximum offered load to a fixed set of interfaces with a fixed number of groups at a fixed frame length for a fixed duration of time. All destination test ports MUST join all specified multicast groups.
以初始最大提供负载向一组固定的接口提供多播流量，该接口具有固定数量的组，具有固定的帧长度和固定的持续时间。所有目标测试端口必须加入所有指定的多播组。
If any frame loss is detected, the offered load is decreased and the sender will transmit again. An iterative search algorithm MUST be utilized to determine the maximum offered frame rate with a zero frame loss.
如果检测到任何帧丢失，则提供的负载将减少，发送方将再次发送。必须使用迭代搜索算法来确定零帧丢失情况下的最大提供帧速率。
Each iteration will involve varying the offered load of the multicast traffic, while keeping the set of interfaces, number of multicast groups, frame length and test duration fixed, until the maximum rate at which none of the offered frames are dropped is determined.
每次迭代将涉及改变多播通信量的提供负载，同时保持接口集、多播组的数量、帧长度和测试持续时间固定，直到确定不丢弃任何提供帧的最大速率。
Parameters to be measured MUST include the maximum offered load at which no frame loss occurred. Other offered loads MAY be measured for diagnostic purposes.
要测量的参数必须包括没有发生帧丢失的最大提供负载。出于诊断目的，可测量其他提供的负载。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups
o 帧大小o DUT/SUT上测试的出口接口数量o测试持续时间o IGMP版本o多播组总数
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o Aggregated Multicast Throughput as defined in RFC 2432 [Du98]
o RFC 2432[Du98]中定义的聚合多播吞吐量
The Aggregated Multicast Throughput results SHOULD be reported in the format of a table with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration SHOULD specify offered load, total number of offered frames and the measured Aggregated Multicast Throughput.
根据第3.1.3节中的建议，聚合多播吞吐量结果应以表格的形式报告，表格中的每一个测试帧大小都有一行。每一行或每一次迭代都应该指定提供的负载、提供的帧总数和测量的聚合多播吞吐量。
This sub-section provides the description of tests related to the determination of throughput measurements when a DUT/SUT or a set of DUTs are acting as tunnel endpoints.
本小节描述了当DUT/SUT或一组DUT用作隧道端点时，与吞吐量测量确定相关的测试。
For this specific testing scenario, encapsulation or tunneling refers to a packet that contains an unsupported protocol feature in a format that is supported by the DUT/SUT.
对于这个特定的测试场景，封装或隧道指的是一个数据包，该数据包包含DUT/SUT支持的格式的不受支持的协议特性。
Objective:
目标：
To determine the maximum rate at which frames offered to one ingress interface of a DUT/SUT are encapsulated and correctly forwarded on one or more egress interfaces of the DUT/SUT without loss.
确定提供给DUT/SUT的一个入口接口的帧被封装并在DUT/SUT的一个或多个出口接口上正确转发而不丢失的最大速率。
Procedure:
程序：
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
| |------->|Ingress | | |
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
+---------+ +-----------+ +---------+
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
| |------->|Ingress | | |
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
+---------+ +-----------+ +---------+
Figure 3
图3
Figure 3 shows the setup for testing the encapsulation throughput of the DUT/SUT. One or more tunnels are created between each egress interface of the DUT/SUT and a destination test port. Non-Encapsulated multicast traffic will then be offered by the source test port, encapsulated by the DUT/SUT and forwarded to the destination test port(s).
图3显示了测试DUT/SUT封装吞吐量的设置。在DUT/SUT的每个出口接口和目标测试端口之间创建一个或多个隧道。然后，非封装的多播通信将由源测试端口提供，由DUT/SUT封装并转发到目标测试端口。
The DUT/SUT SHOULD be configured such that the traffic across each egress interface will consist of either:
DUT/SUT的配置应确保每个出口接口上的流量包括：
a) A single tunnel encapsulating one or more multicast address groups OR b) Multiple tunnels, each encapsulating one or more multicast address groups.
a) 封装一个或多个多播地址组的单个隧道或b）多个隧道，每个隧道封装一个或多个多播地址组。
The number of multicast groups per tunnel MUST be the same when the DUT/SUT is configured in a multiple tunnel configuration. In addition, it is RECOMMENDED to test with the same number of tunnels on each egress interface. All destination test ports MUST join all multicast group addresses offered by the source test port. Each egress interface MUST be configured with the same MTU.
在多隧道配置中配置DUT/SUT时，每个隧道的多播组数必须相同。此外，建议在每个出口接口上使用相同数量的隧道进行测试。所有目标测试端口必须加入源测试端口提供的所有多播组地址。每个出口接口必须配置相同的MTU。
Note: when offering large frames sizes, the encapsulation process may require the DUT/SUT to fragment the IP datagrams prior to being forwarded on the egress interface. It is RECOMMENDED to limit the offered frame size such that no fragmentation is required by the DUT/SUT.
注：当提供大的帧大小时，封装过程可能要求DUT/SUT在出口接口上转发之前对IP数据报进行分段。建议限制提供的帧大小，以便DUT/SUT不需要碎片。
A search algorithm MUST be utilized to determine the encapsulation throughput as defined in [Du98].
必须使用搜索算法来确定[Du98]中定义的封装吞吐量。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o MTU size of DUT/SUT interfaces o Originating un-encapsulated frame size o Number of tunnels per egress interface o Number of multicast groups per tunnel o Encapsulation algorithm or format used to tunnel the packets
o DUT/SUT上测试的出口接口数量o测试持续时间o IGMP版本o多播组总数o DUT/SUT接口的MTU大小o原始未封装帧大小o每个出口接口的隧道数量o每个隧道的多播组数量o用于隧道数据包的封装算法或格式
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o Measured Encapsulated Throughput as defined in RFC 2432 [Du98] o Encapsulated frame size
o 按照RFC 2432[Du98]o封装帧大小中的定义测量封装吞吐量
The Encapsulated Throughput results SHOULD be reported in the form of a table and specific to this test there SHOULD be rows for each originating un-encapsulated frame size. Each row or iteration SHOULD specify the offered load, encapsulation method, encapsulated frame size, total number of offered frames, and the encapsulation throughput.
封装的吞吐量结果应以表格的形式报告，针对该测试，每个原始未封装的帧大小应有行。每一行或迭代都应该指定提供的负载、封装方法、封装的帧大小、提供的帧总数以及封装吞吐量。
Objective:
目标：
To determine the maximum rate at which frames offered to one ingress interface of a DUT/SUT are decapsulated and correctly forwarded by the DUT/SUT on one or more egress interfaces without loss.
确定提供给DUT/SUT的一个入口接口的帧被DUT/SUT在一个或多个出口接口上解封装并正确转发而不丢失的最大速率。
Procedure:
程序：
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|------->| |
| | | | | |
| |--(Tunnel)-->|Ingress | | |
| | | | | |
| | | Egress|------->| |
| | | | | |
+---------+ +-----------+ +---------+
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|------->| |
| | | | | |
| |--(Tunnel)-->|Ingress | | |
| | | | | |
| | | Egress|------->| |
| | | | | |
+---------+ +-----------+ +---------+
Figure 4
图4
Figure 4 shows the setup for testing the decapsulation throughput of the DUT/SUT. One or more tunnels are created between the source test port and the DUT/SUT. Encapsulated multicast traffic will then be offered by the source test port, decapsulated by the DUT/SUT and forwarded to the destination test port(s).
图4显示了测试DUT/SUT脱封吞吐量的设置。在源测试端口和DUT/SUT之间创建一个或多个隧道。封装的多播通信量随后将由源测试端口提供，由DUT/SUT解除封装并转发到目标测试端口。
The DUT/SUT SHOULD be configured such that the traffic across the ingress interface will consist of either:
DUT/SUT的配置应确保通过入口接口的通信量包括：
a) A single tunnel encapsulating one or more multicast address groups OR b) Multiple tunnels, each encapsulating one or more multicast address groups.
a) 封装一个或多个多播地址组的单个隧道或b）多个隧道，每个隧道封装一个或多个多播地址组。
The number of multicast groups per tunnel MUST be the same when the DUT/SUT is configured in a multiple tunnel configuration. All destination test ports MUST join all multicast group addresses offered by the source test port. Each egress interface MUST be configured with the same MTU.
在多隧道配置中配置DUT/SUT时，每个隧道的多播组数必须相同。所有目标测试端口必须加入源测试端口提供的所有多播组地址。每个出口接口必须配置相同的MTU。
A search algorithm MUST be utilized to determine the decapsulation throughput as defined in [Du98].
必须使用搜索算法来确定[Du98]中定义的脱封吞吐量。
When making performance comparisons between the encapsulation and decapsulation process of the DUT/SUT, the offered frame sizes SHOULD reflect the encapsulated frame sizes reported in the encapsulation test (See section 4.4.1) in place of those noted in section 3.1.3.
在对DUT/SUT的封装和去封装过程进行性能比较时，提供的框架尺寸应反映封装试验（见第4.4.1节）中报告的封装框架尺寸，而不是第3.1.3节中说明的尺寸。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o Originating encapsulation algorithm or format used to tunnel the packets o Originating encapsulated frame size o Number of tunnels o Number of multicast groups per tunnel
o DUT/SUT上测试的出口接口数量o测试持续时间o IGMP版本o多播组总数o用于隧道数据包的原始封装算法或格式o原始封装帧大小o隧道数量o每个隧道的多播组数量
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o Measured Decapsulated Throughput as defined in RFC 2432 [Du98] o Decapsulated frame size
o 根据RFC 2432[Du98]o脱封帧大小中的定义测量的脱封吞吐量
The Decapsulated Throughput results SHOULD be reported in the format of a table and specific to this test there SHOULD be rows for each originating encapsulated frame size. Each row or iteration SHOULD specify the offered load, decapsulated frame size, total number of offered frames and the decapsulation throughput.
应以表格的形式报告解封吞吐量结果，针对该测试，每个原始封装帧大小应有行。每行或每一次迭代都应指定提供的负载、解封帧大小、提供的帧总数和解封吞吐量。
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的一个入口接口的一种封装格式的帧转换为另一种封装格式并由DUT/SUT在一个或多个出口接口上正确转发而不丢失的最大速率。
Procedure:
程序：
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +---------+ +---------+
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
| |-(Tunnel)->|Ingress | | |
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
+---------+ +---------+ +---------+
Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +---------+ +---------+
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
| |-(Tunnel)->|Ingress | | |
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
+---------+ +---------+ +---------+
Figure 5
图5
Figure 5 shows the setup for testing the Re-encapsulation throughput of the DUT/SUT. The source test port will offer encapsulated traffic of one type to the DUT/SUT, which has been configured to re-encapsulate the offered frames using a different encapsulation format. The DUT/SUT will then forward the re-encapsulated frames to the destination test port(s).
图5显示了测试DUT/SUT重新封装吞吐量的设置。源测试端口将向DUT/SUT提供一种类型的封装通信量，DUT/SUT已配置为使用不同的封装格式重新封装提供的帧。然后，DUT/SUT将重新封装的帧转发到目标测试端口。
The DUT/SUT SHOULD be configured such that the traffic across the ingress and each egress interface will consist of either:
DUT/SUT的配置应确保通过入口和每个出口接口的通信量包括：
a) A single tunnel encapsulating one or more multicast address groups OR b) Multiple tunnels, each encapsulating one or more multicast address groups.
a) 封装一个或多个多播地址组的单个隧道或b）多个隧道，每个隧道封装一个或多个多播地址组。
The number of multicast groups per tunnel MUST be the same when the DUT/SUT is configured in a multiple tunnel configuration. In addition, the DUT/SUT SHOULD be configured such that the number of tunnels on the ingress and each egress interface are the same. All destination test ports MUST join all multicast group addresses offered by the source test port. Each egress interface MUST be configured with the same MTU.
在多隧道配置中配置DUT/SUT时，每个隧道的多播组数必须相同。此外，DUT/SUT的配置应确保入口和每个出口接口上的隧道数量相同。所有目标测试端口必须加入源测试端口提供的所有多播组地址。每个出口接口必须配置相同的MTU。
Note that when offering large frames sizes, the encapsulation process may require the DUT/SUT to fragment the IP datagrams prior to being forwarded on the egress interface. It is RECOMMENDED to limit the offered frame sizes, such that no fragmentation is required by the DUT/SUT.
注意，当提供大的帧大小时，封装过程可能要求DUT/SUT在被转发到出口接口之前对IP数据报进行分段。建议限制提供的机架尺寸，以便DUT/SUT不需要碎片。
A search algorithm MUST be utilized to determine the re-encapsulation throughput as defined in [Du98].
必须使用搜索算法来确定[Du98]中定义的重新封装吞吐量。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Total number of multicast groups o MTU size of DUT/SUT interfaces o Originating encapsulation algorithm or format used to tunnel the packets o Re-encapsulation algorithm or format used to tunnel the packets o Originating encapsulated frame size o Number of tunnels per interface o Number of multicast groups per tunnel
o DUT/SUT上测试的出口接口数量o测试持续时间o IGMP版本o多播组总数o DUT/SUT接口的MTU大小o用于隧道数据包的原始封装算法或格式o用于隧道数据包的重新封装算法或格式o原始封装帧大小o隧道数量每个接口o每个隧道的多播组数
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o Measured Re-encapsulated Throughput as defined in RFC 2432 [Du98] o Re-encapsulated frame size
o RFC 2432[Du98]中定义的测量的重新封装吞吐量o重新封装的帧大小
The Re-encapsulated Throughput results SHOULD be reported in the format of a table and specific to this test there SHOULD be rows for each originating encapsulated frame size. Each row or iteration SHOULD specify the offered load, Re-encapsulated frame size, total number of offered frames, and the Re-encapsulated Throughput.
重新封装的吞吐量结果应以表格的形式报告，针对该测试，每个原始封装帧大小应有行。每一行或迭代都应该指定提供的负载、重新封装的帧大小、提供的帧总数以及重新封装的吞吐量。
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中提出的延迟特性的概念。
The offered load accompanying the latency-measured packet can affect the DUT/SUT packet buffering, which may subsequently impact measured packet latency. This SHOULD be a consideration when selecting the intended load for the described methodologies below.
随延迟测量数据包一起提供的负载可影响DUT/SUT数据包缓冲，这可能随后影响测量数据包延迟。在为下面描述的方法选择预期负载时，应考虑这一点。
RFC 1242 and RFC 2544 draw a distinction between device types: "store and forward" and "bit-forwarding." Each type impacts how latency is collected and subsequently presented. See the related RFCs for more information.
RFC 1242和RFC 2544对设备类型进行了区分：“存储转发”和“位转发”。每种类型都会影响延迟的收集和后续呈现方式。有关更多信息，请参阅相关RFC。
Objective:
目标：
To produce a set of multicast latency measurements from a single, multicast ingress interface of a DUT/SUT through multiple, egress multicast interfaces of that same DUT/SUT as provided for by the metric "Multicast Latency" in RFC 2432 [Du98].
根据RFC 2432[Du98]中的度量“多播延迟”，从DUT/SUT的单个多播入口接口通过该DUT/SUT的多个出口多播接口生成一组多播延迟测量值。
The procedures below draw from the collection methodology for latency in RFC 2544 [Br96]. The methodology addresses two topological scenarios: one for a single device (DUT) characterization; a second scenario is presented or multiple device (SUT) characterization.
以下程序借鉴了RFC 2544[Br96]中的延迟收集方法。该方法解决了两种拓扑场景：一种是单器件（DUT）特性描述；第二个场景是多设备（SUT）特性描述。
Procedure:
程序：
If the test trial is to characterize latency across a single Device Under Test (DUT), an example test topology might take the form of Figure 1 in section 3. That is, a single DUT with one ingress interface receiving the multicast test traffic from frame-transmitting component of the test apparatus and n egress interfaces on the same DUT forwarding the multicast test traffic back to the frame-receiving component of the test apparatus. Note that n reflects the number of TESTED egress interfaces on the DUT actually expected to forward the test traffic (as opposed to configured but untested, non-forwarding interfaces, for example).
如果测试测试是为了表征单个被测设备（DUT）的延迟，那么示例测试拓扑可能采用第3节中图1的形式。也就是说，具有一个入口接口的单个DUT从测试设备的帧发送组件接收多播测试业务，并且在同一DUT上具有n个出口接口，将多播测试业务转发回测试设备的帧接收组件。注意，n反映DUT上实际预期转发测试流量的已测试出口接口的数量（例如，与已配置但未测试的非转发接口相反）。
If the multicast latencies are to be taken across multiple devices forming a System Under Test (SUT), an example test topology might take the form of Figure 2 in section 3.
如果多播延迟要跨构成被测系统（SUT）的多个设备进行，则示例测试拓扑可能采用第3节中图2的形式。
The trial duration SHOULD be 120 seconds to be consistent with RFC 2544 [Br96]. The nature of the latency measurement, "store and forward" or "bit forwarding", MUST be associated with the related test trial(s) and disclosed in the results report.
试验持续时间应为120秒，以符合RFC 2544[Br96]。延迟测量的性质，“存储转发”或“比特转发”必须与相关测试试验相关联，并在结果报告中披露。
A test traffic stream is presented to the DUT. It is RECOMMENDED to offer traffic at the measured aggregated multicast throughput rate (Section 4.3). At the mid-point of the trial's duration, the test apparatus MUST inject a uniquely identifiable ("tagged") frame into the test traffic frames being presented. This tagged frame will be the basis for the latency measurements. By "uniquely identifiable", it is meant that the test apparatus MUST be able to discern the "tagged" frame from the other frames comprising the test traffic set. A frame generation timestamp, Timestamp A, reflecting the completion of the transmission of the tagged frame by the test apparatus, MUST be determined.
向DUT呈现测试业务流。建议以测量的聚合多播吞吐量率提供流量（第4.3节）。在试验持续时间的中点，试验装置必须将唯一可识别（“标记”）的帧注入正在呈现的试验交通帧中。此标记帧将作为延迟测量的基础。通过“唯一可识别”，意味着测试设备必须能够从包含测试业务集的其他帧中识别“标记”帧。必须确定帧生成时间戳，时间戳A，该时间戳反映测试设备完成标记帧的传输。
The test apparatus will monitor frames from the DUT's tested egress interface(s) for the expected tagged frame(s) and MUST record the time of the successful detection of a tagged frame from a tested egress interface with a timestamp, Timestamp B. A set of Timestamp B values MUST be collected for all tested egress interfaces of the DUT/SUT. See RFC 1242 [Br91] for additional discussion regarding store and forward devices and bit forwarding devices.
测试设备将监控来自DUT测试出口接口的帧，以获得预期的标记帧，并且必须使用时间戳（时间戳B）记录成功检测来自测试出口接口的标记帧的时间。必须为DUT/SUT的所有测试出口接口收集一组时间戳B值。有关存储转发设备和位转发设备的更多讨论，请参阅RFC 1242[Br91]。
A trial MUST be considered INVALID should any of the following conditions occur in the collection of the trial data:
如果在收集试验数据时出现以下任何情况，则试验必须视为无效：
o Unexpected differences between Intended Load and Offered Load or unexpected differences between Offered Load and the resulting Forwarding Rate(s) on the DUT/SUT egress ports. o Forwarded test frames improperly formed or frame header fields improperly manipulated. o Failure to forward required tagged frame(s) on all expected egress interfaces. o Reception of tagged frames by the test apparatus more than 5 seconds after the cessation of test traffic by the source test port.
o 预期负载和提供负载之间的意外差异，或提供负载和DUT/SUT出口端口上产生的转发速率之间的意外差异。o转发的测试帧格式不正确或帧头字段操作不正确。o未能在所有预期出口接口上转发所需的标记帧。o在源测试端口停止测试通信后5秒以上，测试设备接收标记帧。
The set of latency measurements, M, composed from each latency measurement taken from every ingress/tested egress interface pairing MUST be determined from a valid test trial:
从每个入口/测试出口接口配对中获取的每个延迟测量值组成的延迟测量值集M必须通过有效的测试试验确定：
M = { (Timestamp B(E0) - Timestamp A),
(Timestamp B(E1) - Timestamp A), ...
(Timestamp B(En) - Timestamp A) }
M = { (Timestamp B(E0) - Timestamp A),
(Timestamp B(E1) - Timestamp A), ...
(Timestamp B(En) - Timestamp A) }
where (E0 ... En) represents the range of all tested egress interfaces and Timestamp B represents a tagged frame detection event for a given DUT/SUT tested egress interface.
其中（E0…En）表示所有测试出口接口的范围，时间戳B表示给定DUT/SUT测试出口接口的标记帧检测事件。
A more continuous profile MAY be built from a series of individual measurements.
可通过一系列单独测量建立更连续的轮廓。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Offered load o Total number of multicast groups
o 帧大小o DUT/SUT上测试出口接口的数量o测试持续时间o IGMP版本o提供的负载o多播组的总数
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The set of all latencies with respective time units related to the tested ingress and each tested egress DUT/SUT interface.
o 所有延迟的集合，以及与测试的入口和每个测试的出口DUT/SUT接口相关的各自时间单位。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
所呈现延迟的时间单位必须统一，且对于所测试的介质或介质具有足够的精度。
The results MAY be offered in a tabular format and should preserve the relationship of latency to ingress/egress interface for each multicast group to assist in trending across multiple trials.
结果可能以表格形式提供，并且应保留每个多播组的延迟与入口/出口接口的关系，以帮助在多个试验中进行趋势分析。
Objective:
目标：
To determine the difference between the maximum latency measurement and the minimum latency measurement from a collected set of latencies produced by the Multicast Latency benchmark.
从多播延迟基准生成的一组收集的延迟中确定最大延迟度量和最小延迟度量之间的差异。
Procedure:
程序：
Collect a set of multicast latency measurements over a single test duration, as prescribed in section 5.1. This will produce a set of multicast latencies, M, where M is composed of individual forwarding latencies between DUT frame ingress and DUT frame egress port pairs. E.g.:
按照第5.1节的规定，在单个测试持续时间内收集一组多播延迟测量值。这将产生一组多播延迟M，其中M由DUT帧入口和DUT帧出口端口对之间的单个转发延迟组成。例如。：
M = {L(I,E1),L(I,E2), ..., L(I,En)}
M = {L(I,E1),L(I,E2), ..., L(I,En)}
where L is the latency between a tested ingress interface, I, of the DUT, and Ex a specific, tested multicast egress interface of the DUT. E1 through En are unique egress interfaces on the DUT.
其中，L是DUT的测试入口接口I与DUT的特定测试多播出口接口Ex之间的延迟。E1至En是DUT上唯一的出口接口。
From the collected multicast latency measurements in set M, identify MAX(M), where MAX is a function that yields the largest latency value from set M.
从集合M中收集的多播延迟测量值中，确定MAX（M），其中MAX是从集合M中产生最大延迟值的函数。
Identify MIN(M), when MIN is a function that yields the smallest latency value from set M.
标识MIN（M），当MIN是从集合M中产生最小延迟值的函数时。
The Max/Min value is determined from the following formula:
最大/最小值由以下公式确定：
Result = MAX(M) - MIN(M)
Result = MAX(M) - MIN(M)
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Offered load o Total number of multicast groups
o 帧大小o DUT/SUT上测试出口接口的数量o测试持续时间o IGMP版本o提供的负载o多播组的总数
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The Max/Min value
o 最大/最小值
The following results SHOULD be reflected in the test report:
试验报告中应反映以下结果：
o The set of all latencies with respective time units related to the tested ingress and each tested egress DUT/SUT interface.
o 所有延迟的集合，以及与测试的入口和每个测试的出口DUT/SUT接口相关的各自时间单位。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
所呈现延迟的时间单位必须统一，且对于所测试的介质或介质具有足够的精度。
The results MAY be offered in a tabular format and should preserve the relationship of latency to ingress/egress interface for each multicast group.
结果可以以表格格式提供，并且应该为每个多播组保留延迟与入口/出口接口的关系。
This section presents methodology relating to the characterization of the overhead delays associated with explicit operations found in multicast environments.
本节介绍了与多播环境中的显式操作相关的开销延迟的表征方法。
Objective:
目标：
To determine the time duration it takes a DUT/SUT to start forwarding multicast frames from the time a successful IGMP group membership report has been issued to the DUT/SUT.
为了确定DUT/SUT从成功向DUT/SUT发送IGMP组成员资格报告开始转发多播帧所需的持续时间。
Procedure:
程序：
The Multicast Group Join Delay measurement may be influenced by the state of the Multicast Forwarding Database <MFDB> of the DUT/SUT. The states of the MFDB may be described as follows:
多播组加入延迟测量可能受到DUT/SUT的多播转发数据库<MFDB>的状态的影响。MFDB的状态可描述如下：
o State 0, where the MFDB does not contain the specified multicast group address. In this state, the delay measurement includes the time the DUT/SUT requires to add the address to the MFDB and begin forwarding. Delay measured from State 0 provides information about how the DUT/SUT is able to add new addresses into MFDB.
o 状态0，其中MFDB不包含指定的多播组地址。在此状态下，延迟测量包括DUT/SUT向MFDB添加地址并开始转发所需的时间。从状态0测量的延迟提供有关DUT/SUT如何能够向MFDB添加新地址的信息。
o State 1, where the MFDB does contain the specified multicast group address. In this state, the delay measurement includes the time the DUT/SUT requires to update the MFDB with the newly joined node<s> and begin forwarding to the new node<s> plus packet replication time. Delay measured from State 1 provides information about how well the DUT/SUT is able to update the MFDB for new nodes while transmitting packets to other nodes for the same IP multicast address. Examples include adding a new user to an event that is being promoted via multicast packets.
o 状态1，其中MFDB不包含指定的多播组地址。在此状态下，延迟测量包括DUT/SUT使用新加入的节点<s>更新MFDB并开始转发到新节点<s>所需的时间加上数据包复制时间。从状态1测量的延迟提供了有关DUT/SUT在向其他节点发送相同IP多播地址的数据包时，能够为新节点更新MFDB的程度的信息。示例包括向通过多播数据包提升的事件添加新用户。
The methodology for the Multicast Group Join Delay measurement provides two alternate methods, based on the state of the MFDB, to measure the delay metric. The methods MAY be used independently or in conjunction to provide meaningful insight into the DUT/SUT ability to manage the MFDB.
多播组加入延迟测量方法基于MFDB的状态提供了两种备选方法来测量延迟度量。这些方法可以单独使用，也可以结合使用，以便对DUT/SUT管理MFDB的能力提供有意义的见解。
Users MAY elect to use either method to determine the Multicast Group Join Delay; however the collection method MUST be specified as part of the reporting format.
用户可以选择使用任一种方法来确定多播组加入延迟；但是，必须将收集方法指定为报告格式的一部分。
In order to minimize the variation in delay calculations as well as minimize burden on the DUT/SUT, the test SHOULD be performed with one multicast group. In addition, all destination test ports MUST join the specified multicast group offered to the ingress interface of the DUT/SUT.
为了最小化延迟计算中的变化以及DUT/SUT上的负担，应使用一个多播组执行测试。此外，所有目标测试端口必须加入提供给DUT/SUT入口接口的指定多播组。
Method A:
方法A：
Method A assumes that the Multicast Forwarding Database <MFDB> of the DUT/SUT does not contain or has not learned the specified multicast group address; specifically, the MFDB MUST be in State 0. In this scenario, the metric represents the time the DUT/SUT takes to add the multicast address to the MFDB and begin forwarding the multicast packet. Only one ingress and one egress MUST be used to determine this metric.
方法A假设DUT/SUT的多播转发数据库<MFDB>不包含或未读入指定的多播组地址；具体而言，MFDB必须处于状态0。在这种情况下，度量表示DUT/SUT将多播地址添加到MFDB并开始转发多播数据包所需的时间。只能使用一个入口和一个出口来确定该度量。
Prior to sending any IGMP Group Membership Reports used to calculate the Multicast Group Join Delay, it MUST be verified through externally observable means that the destination test port is not currently a member of the specified multicast group. In addition, it MUST be verified through externally observable means that the MFDB of the DUT/SUT does not contain the specified multicast address.
在发送用于计算多播组加入延迟的任何IGMP组成员报告之前，必须通过外部可观察手段验证目标测试端口当前不是指定多播组的成员。此外，必须通过外部可观察手段验证DUT/SUT的MFDB不包含指定的多播地址。
Method B:
方法B：
Method B assumes that the MFDB of the DUT/SUT does contain the specified multicast group address; specifically, the MFDB MUST be in State 1. In this scenario, the metric represents the time the DUT/SUT takes to update the MFDB with the additional nodes and their corresponding interfaces and to begin forwarding the multicast packet. One or more egress ports MAY be used to determine this metric.
方法B假设DUT/SUT的MFDB包含指定的多播组地址；具体而言，MFDB必须处于状态1。在这种情况下，度量表示DUT/SUT使用附加节点及其相应接口更新MFDB并开始转发多播数据包所需的时间。一个或多个出口端口可用于确定该度量。
Prior to sending any IGMP Group Membership Reports used to calculate the Group Join Delay, it MUST be verified through externally observable means that the MFDB contains the specified multicast group address. A single un-instrumented test port MUST be used to join the specified multicast group address prior to sending any test traffic. This port will be used only for insuring that the MFDB has been populated with the specified multicast group address and can successfully forward traffic to the un-instrumented port.
在发送用于计算组加入延迟的任何IGMP组成员报告之前，必须通过外部可观察手段验证MFDB是否包含指定的多播组地址。在发送任何测试流量之前，必须使用单个未检测的测试端口加入指定的多播组地址。此端口将仅用于确保MFDB已填充指定的多播组地址，并且可以成功地将流量转发到未检测的端口。
Join Delay Calculation
连接延迟计算
Once verification is complete, multicast traffic for the specified multicast group address MUST be offered to the ingress interface prior to the DUT/SUT receiving any IGMP Group Membership Report messages. It is RECOMMENDED to offer traffic at the measured aggregated multicast throughput rate (Section 4.3).
验证完成后，在DUT/SUT接收任何IGMP组成员报告消息之前，必须向入口接口提供指定多播组地址的多播通信量。建议以测量的聚合多播吞吐量率提供流量（第4.3节）。
After the multicast traffic has been started, the destination test port (See Figure 1) MUST send one IGMP Group Membership Report for the specified multicast group.
启动多播通信后，目标测试端口（见图1）必须为指定的多播组发送一个IGMP组成员报告。
The join delay is the difference in time from when the IGMP Group Membership message is sent (timestamp A) and the first frame of the multicast group is forwarded to a receiving egress interface (timestamp B).
加入延迟是从发送IGMP组成员资格消息（时间戳A）到多播组的第一帧被转发到接收出口接口（时间戳B）的时间差。
Group Join delay time = timestamp B - timestamp A
组连接延迟时间=时间戳B-时间戳A
Timestamp A MUST be the time the last bit of the IGMP group membership report is sent from the destination test port; timestamp B MUST be the time the first bit of the first valid multicast frame is forwarded on the egress interface of the DUT/SUT.
时间戳A必须是从目标测试端口发送IGMP组成员报告的最后一位的时间；时间戳B必须是在DUT/SUT的出口接口上转发第一个有效多播帧的第一位的时间。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Total number of multicast groups o Offered load to ingress interface o Method used to measure the join delay metric
o 帧大小o DUT/SUT上测试的出口接口数量o IGMP版本o多播组总数o提供的负载到入口接口o用于测量连接延迟度量的方法
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The group join delay time in microseconds per egress interface(s)
o 每个出口接口的组连接延迟时间（微秒）
The Group Join Delay results for each test MAY be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration MAY specify the group join delay time per egress interface for that iteration.
每个测试的组连接延迟结果可以表格的形式报告，根据第3.1.3节中的建议，每个测试帧尺寸都有一行。每一行或迭代可指定该迭代的每个出口接口的组加入延迟时间。
Objective:
目标：
To determine the time duration it takes a DUT/SUT to cease forwarding multicast frames after a corresponding IGMP Leave Group message has been successfully offered to the DUT/SUT.
为了确定DUT/SUT在相应的IGMP离开组消息成功提供给DUT/SUT后停止转发多播帧所需的持续时间。
Procedure:
程序：
In order to minimize the variation in delay calculations as well as minimize burden on the DUT/SUT, the test SHOULD be performed with one multicast group. In addition, all destination test ports MUST join the specified multicast group offered to the ingress interface of the DUT/SUT.
为了最小化延迟计算中的变化以及DUT/SUT上的负担，应使用一个多播组执行测试。此外，所有目标测试端口必须加入提供给DUT/SUT入口接口的指定多播组。
Prior to sending any IGMP Leave Group messages used to calculate the group leave delay, it MUST be verified through externally observable means that the destination test ports are currently members of the specified multicast group. If any of the egress interfaces do not forward validation multicast frames then the test is invalid.
在发送用于计算组离开延迟的任何IGMP离开组消息之前，必须通过外部可观察手段验证目标测试端口当前是指定多播组的成员。如果任何出口接口不转发验证多播帧，则测试无效。
Once verification is complete, multicast traffic for the specified multicast group address MUST be offered to the ingress interface prior to receipt or processing of any IGMP Leave Group messages. It is RECOMMENDED to offer traffic at the measured aggregated multicast throughput rate (Section 4.3).
验证完成后，在接收或处理任何IGMP离开组消息之前，必须向入口接口提供指定多播组地址的多播通信量。建议以测量的聚合多播吞吐量率提供流量（第4.3节）。
After the multicast traffic has been started, each destination test port (See Figure 1) MUST send one IGMP Leave Group message for the specified multicast group.
启动多播通信后，每个目标测试端口（见图1）必须为指定的多播组发送一条IGMP Leave Group消息。
The leave delay is the difference in time from when the IGMP Leave Group message is sent (timestamp A) and the last frame of the multicast group is forwarded to a receiving egress interface (timestamp B).
离开延迟是从发送IGMP离开组消息（时间戳A）到多播组的最后一帧被转发到接收出口接口（时间戳B）的时间差。
Group Leave delay time = timestamp B - timestamp A
团体休假延迟时间=时间戳B-时间戳A
Timestamp A MUST be the time the last bit of the IGMP Leave Group message is sent from the destination test port; timestamp B MUST be the time the last bit of the last valid multicast frame is forwarded on the egress interface of the DUT/SUT.
时间戳A必须是从目标测试端口发送IGMP离开组消息的最后一位的时间；时间戳B必须是最后一个有效多播帧的最后一位在DUT/SUT的出口接口上转发的时间。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Total number of multicast groups o Offered load to ingress interface
o 帧大小o DUT/SUT上测试的出口接口数量o IGMP版本o多播组总数o提供的入口接口负载
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The group leave delay time in microseconds per egress interface(s)
o 每个出口接口的组离开延迟时间（微秒）
The Group Leave Delay results for each test MAY be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration MAY specify the group leave delay time per egress interface for that iteration.
每次测试的团体休假延迟结果可以表格的形式报告，并根据第3.1.3节中的建议为每个测试帧尺寸提供一行。每一行或迭代可指定该迭代的每个出口接口的组离开延迟时间。
This section offers a procedure relating to the identification of multicast group limits of a DUT/SUT.
本节提供与DUT/SUT的多播组限制的识别相关的程序。
Objective:
目标：
To determine the maximum number of multicast groups a DUT/SUT can support while maintaining the ability to forward multicast frames to all multicast groups registered to that DUT/SUT.
确定DUT/SUT可以支持的最大多播组数，同时保持将多播帧转发给注册到该DUT/SUT的所有多播组的能力。
Procedure:
程序：
One or more destination test ports of DUT/SUT will join an initial number of multicast groups.
DUT/SUT的一个或多个目标测试端口将加入初始数量的多播组。
After a minimum delay as measured by section 6.1, the source test ports MUST transmit to each group at a specified offered load.
在第6.1节测量的最小延迟后，源测试端口必须以规定的提供负载向每组传输。
If at least one frame for each multicast group is forwarded properly by the DUT/SUT on each participating egress interface, the iteration is said to pass at the current capacity.
如果DUT/SUT在每个参与的出口接口上正确地转发了每个多播组的至少一个帧，则称迭代以当前容量通过。
For each successful iteration, each destination test port will join an additional user-defined number of multicast groups and the test repeats. The test stops iterating when one or more of the egress interfaces fails to forward traffic on one or more of the configured multicast groups.
对于每个成功的迭代，每个目标测试端口将加入额外的用户定义数量的多播组，并重复测试。当一个或多个出口接口无法转发一个或多个配置的多播组上的流量时，测试停止迭代。
Once the iteration fails, the last successful iteration is the stated Maximum Group Capacity result.
一旦迭代失败，最后一次成功的迭代就是规定的最大组容量结果。
Reporting Format:
报告格式：
The following configuration parameters MUST be reflected in the test report:
测试报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Offered load
o 帧大小o DUT/SUT o IGMP版本o提供负载上测试的出口接口数量
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The total number of multicast group addresses that were successfully forwarded through the DUT/SUT
o 通过DUT/SUT成功转发的多播组地址总数
The Multicast Group Capacity results for each test SHOULD be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration SHOULD specify the number of multicast groups joined per destination interface, number of frames transmitted and number of frames received for that iteration.
每个测试的多播组容量结果应以表格的形式报告，并根据第3.1.3节中的建议，为每个测试帧大小提供一行。每一行或每一次迭代都应指定每个目标接口加入的多播组的数量、为该迭代发送的帧数量和接收的帧数量。
Network forwarding devices are generally required to provide more functionality than just the forwarding of traffic. Moreover, network-forwarding devices may be asked to provide those functions in a variety of environments. This section offers procedures to assist in the characterization of DUT/SUT behavior in consideration of potentially interacting factors.
网络转发设备通常需要提供比转发流量更多的功能。此外，可以要求网络转发设备在各种环境中提供这些功能。本节提供了考虑潜在交互因素的DUT/SUT行为特征描述的程序。
Objective:
目标：
To produce a set of multicast latency measurements from a single multicast ingress interface of a DUT/SUT through multiple egress multicast interfaces of that same DUT/SUT as provided for by the metric "Multicast Latency" in RFC 2432 [Du98] while forwarding meshed unicast traffic.
从DUT/SUT的单个多播入口接口通过该DUT/SUT的多个出口多播接口生成一组多播延迟测量值，如RFC 2432[Du98]中的度量“多播延迟”所规定，同时转发网状单播流量。
Procedure:
程序：
The Multicast Latency metrics can be influenced by forcing the DUT/SUT to perform extra processing of packets while multicast class traffic is being forwarded for latency measurements.
当多播类通信量被转发以进行延迟测量时，强制DUT/SUT执行额外的数据包处理可以影响多播延迟度量。
The Burdened Forwarding Multicast Latency test MUST follow the described setup for the Multicast Latency test in Section 5.1. In addition, another set of test ports MUST be used to burden the DUT/SUT (burdening ports). The burdening ports will be used to transmit unicast class traffic to the DUT/SUT in a fully meshed traffic distribution as described in RFC 2285 [Ma98]. The DUT/SUT MUST learn the appropriate unicast addresses and verified through some externally observable method.
负载转发多播延迟测试必须遵循第5.1节中描述的多播延迟测试设置。此外，必须使用另一组测试端口来加载DUT/SUT（加载端口）。负载端口将用于以RFC 2285[Ma98]中所述的全网状流量分布将单播类流量传输到DUT/SUT。DUT/SUT必须学习适当的单播地址，并通过一些外部可观察的方法进行验证。
Perform a baseline measurement of Multicast Latency as described in Section 5.1. After the baseline measurement is obtained, start transmitting the unicast class traffic at a user-specified offered load on the set of burdening ports and rerun the Multicast Latency test. The offered load to the ingress port MUST be the same as was used in the baseline measurement.
如第5.1节所述，对多播延迟进行基线测量。在获得基线测量值后，在负载端口集上以用户指定的提供负载开始传输单播类流量，并重新运行多播延迟测试。提供给入口端口的负载必须与基线测量中使用的负载相同。
Reporting Format:
报告格式：
Similar to Section 5.1, the following configuration parameters MUST be reflected in the test report:
与第5.1节类似，试验报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o Test duration o IGMP version o Offered load to ingress interface o Total number of multicast groups o Offered load to burdening ports o Total number of burdening ports
o 帧大小o DUT/SUT上测试出口接口的数量o测试持续时间o IGMP版本o提供的负载到入口接口o多播组的总数o提供的负载到负载端口的总数o负载端口的总数
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The set of all latencies related to the tested ingress and each tested egress DUT/SUT interface for both the baseline and burdened response.
o 与基线和负载响应的测试入口和每个测试出口DUT/SUT接口相关的所有延迟集。
The time units of the presented latency MUST be uniform and with sufficient precision for the medium or media being tested.
所呈现延迟的时间单位必须统一，且对于所测试的介质或介质具有足够的精度。
The latency results for each test SHOULD be reported in the form of a table, with a row for each of the tested frame sizes per the recommended frame sizes in section 3.1.3, and SHOULD preserve the relationship of latency to ingress/egress interface(s) to assist in trending across multiple trials.
应以表格的形式报告每个测试的延迟结果，根据第3.1.3节中的建议帧大小，每个测试帧大小对应一行，并且应保留延迟与入口/出口接口的关系，以帮助在多个测试中进行趋势分析。
Objective:
目标：
To determine the time duration it takes a DUT/SUT to start forwarding multicast frames from the time a successful IGMP Group Membership Report has been issued to the DUT/SUT while forwarding meshed unicast traffic.
为了确定DUT/SUT在转发网状单播流量时，从成功向DUT/SUT发出IGMP组成员资格报告开始转发多播帧所需的持续时间。
Procedure:
程序：
The Forwarding Burdened Group Join Delay test MUST follow the described setup for the Group Join Delay test in Section 6.1. In addition, another set of test ports MUST be used to burden the DUT/SUT (burdening ports). The burdening ports will be used to transmit unicast class traffic to the DUT/SUT in a fully meshed traffic pattern as described in RFC 2285 [Ma98]. The DUT/SUT MUST learn the appropriate unicast addresses and verified through some externally observable method.
转发负载组加入延迟测试必须遵循第6.1节中描述的组加入延迟测试设置。此外，必须使用另一组测试端口来加载DUT/SUT（加载端口）。负载端口将用于以RFC 2285[Ma98]中所述的全网状业务模式向DUT/SUT发送单播类业务。DUT/SUT必须学习适当的单播地址，并通过一些外部可观察的方法进行验证。
Perform a baseline measurement of Group Join Delay as described in Section 6.1. After the baseline measurement is obtained, start transmitting the unicast class traffic at a user-specified offered load on the set of burdening ports and rerun the Group Join Delay test. The offered load to the ingress port MUST be the same as was used in the baseline measurement.
如第6.1节所述，对组连接延迟进行基线测量。在获得基线测量值后，在负载端口集上以用户指定的提供负载开始传输单播类流量，并重新运行组加入延迟测试。提供给入口端口的负载必须与基线测量中使用的负载相同。
Reporting Format:
报告格式：
Similar to Section 6.1, the following configuration parameters MUST be reflected in the test report:
与第6.1节类似，试验报告中必须反映以下配置参数：
o Frame size(s) o Number of tested egress interfaces on the DUT/SUT o IGMP version o Offered load to ingress interface o Total number of multicast groups o Offered load to burdening ports o Total number of burdening ports o Method used to measure the join delay metric
o 帧大小o DUT/SUT上测试的出口接口数量o IGMP版本o提供的负载到入口接口o多播组的总数o提供的负载到负载端口的总数o负载端口的总数o用于测量连接延迟度量的方法
The following results MUST be reflected in the test report:
试验报告中必须反映以下结果：
o The group join delay time in microseconds per egress interface(s) for both the baseline and burdened response.
o 基线和负载响应的组连接延迟时间（单位：微秒/出口接口）。
The Group Join Delay results for each test MAY be reported in the form of a table, with a row for each of the tested frame sizes per the recommendations in section 3.1.3. Each row or iteration MAY specify the group join delay time per egress interface, number of frames transmitted and number of frames received for that iteration.
每个测试的组连接延迟结果可以表格的形式报告，根据第3.1.3节中的建议，每个测试帧尺寸都有一行。每一行或迭代可指定每个出口接口的组加入延迟时间、为该迭代发送的帧数和接收的帧数。
As this document is solely for the purpose of providing metric methodology and describes neither a protocol nor a protocol's implementation, there are no security considerations associated with this document specifically. Results from these methodologies may identify a performance capability or limit of a device or system in a particular test context. However, such results might not be representative of the tested entity in an operational network.
由于本文件仅用于提供度量方法，并且既不描述协议也不描述协议的实现，因此本文件没有具体的安全注意事项。这些方法的结果可以识别特定测试环境中设备或系统的性能能力或限制。然而，这些结果可能无法代表运行网络中的测试实体。
The Benchmarking Methodology Working Group of the IETF and particularly Kevin Dubray, Juniper Networks, are to be thanked for the many suggestions they collectively made to help complete this document.
IETF的基准测试方法工作组，特别是Juniper Networks的Kevin Dubrey，感谢他们为帮助完成本文件而集体提出的许多建议。
The authors would like to acknowledge the following individuals for their help and participation of the compilation of this document: Hardev Soor, Ixia, and Ralph Daniels, Spirent Communications, both who made significant contributions to the earlier versions of this document. In addition, the authors would like to acknowledge the members of the task team who helped bring this document to fruition: Michele Bustos, Tony De La Rosa, David Newman and Jerry Perser.
作者要感谢以下个人对本文件编写的帮助和参与：Hardev Soor、Ixia和Ralph Daniels，Spirent Communications，他们都对本文件的早期版本做出了重大贡献。此外，作者还要感谢工作组的成员，他们帮助实现了本文件：米歇尔·布斯托斯、托尼·德拉罗萨、大卫·纽曼和杰瑞·珀瑟。
[Br91] Bradner, S., "Benchmarking Terminology for Network Interconnection Devices", RFC 1242, July 1991.
[Br91]Bradner，S.，“网络互连设备的基准术语”，RFC 1242，1991年7月。
[Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[Br96]Bradner，S.和J.McQuaid，“网络互连设备的基准测试方法”，RFC 2544，1999年3月。
[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement Levels, RFC 2119, March 1997.
[Br97]Bradner，S.“在RFC中使用关键字反映需求水平”，RFC 211997年3月。
[Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[Du98]Dubrey，K.，“IP多播基准测试术语”，RFC 2432，1998年10月。
[IANA1] IANA multicast address assignments,
http://www.iana.org/assignments/multicast-addresses
[IANA1] IANA multicast address assignments,
http://www.iana.org/assignments/multicast-addresses
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
[Ma98]Mandeville，R.，“局域网交换设备的基准术语”，RFC 2285，1998年2月。
[Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Me98]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[Ca02] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[Ca02]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[De89]Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[Fe97]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
[Hu95]Huitema，C.，“互联网中的路由”，Prentice Hall，1995年。
[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive Corporate Networks", John Wiley & Sons Inc., 1998.
[Ka98]Kosiur，D.，“IP多播：交互式企业网络完整指南”，约翰·威利父子公司，1998年。
[Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise", Prentice-Hall, 1998.
[Mt98]Maufer，T.，“在企业中部署IP多播”，Prentice Hall，1998年。
Debra Stopp Ixia 26601 W. Agoura Rd. Calabasas, CA 91302 USA
美国加利福尼亚州卡拉巴萨斯市阿古拉大道西26601号，邮编：91302
Phone: + 1 818 871 1800
EMail: debby@ixiacom.com
Phone: + 1 818 871 1800
EMail: debby@ixiacom.com
Brooks Hickman Spirent Communications 26750 Agoura Rd. Calabasas, CA 91302 USA
布鲁克斯·希克曼·斯皮兰特通信公司美国加利福尼亚州卡拉巴斯市阿古拉路26750号，邮编：91302
Phone: + 1 818 676 2412
EMail: brooks.hickman@spirentcom.com
Phone: + 1 818 676 2412
EMail: brooks.hickman@spirentcom.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。