draft-ietf-bmwg-mcastm-14.txt   rfc3918.txt 
Network Working Group Debra Stopp Network Working Group D. Stopp
INTERNET-DRAFT Ixia Request for Comments: 3918 Ixia
Expires in: February 2004 Brooks Hickman Category: Informational B. Hickman
Spirent Communications Spirent Communications
January 2004 October 2004
Methodology for IP Multicast Benchmarking Methodology for IP Multicast Benchmarking
<draft-ietf-bmwg-mcastm-14.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Copyright (C) The Internet Society (2004).
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at Abstract
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The purpose of this document is to describe methodology specific to
http://www.ietf.org/shadow.html. 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.
Copyright Notice 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.
Copyright (C) The Internet Society (2004). All Rights Reserved. Table of Contents
Abstract 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
The purpose of this document is to describe methodology specific to 1. Introduction
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.
The BMWG produces two major classes of documents: Benchmarking This document defines tests for measuring and reporting the
Terminology documents and Benchmarking Methodology documents. The throughput, forwarding, latency and Internet Group Management
Terminology documents present the benchmarks and other related Protocol (IGMP) group membership characteristics of devices that
terms. The Methodology documents define the procedures required to support IP multicast protocols. The results of these tests will
collect the benchmarks cited in the corresponding Terminology provide the user with meaningful data on multicast performance.
documents.
Table of Contents 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.
1. INTRODUCTION...................................................3 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.
2. KEY WORDS TO REFLECT REQUIREMENTS..............................3 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].
3. TEST SET UP....................................................3 2. Key Words to Reflect Requirements
3.1. Test Considerations..........................................5
3.1.1. IGMP Support..............................................6
3.1.2. Group Addresses...........................................6
3.1.3. Frame Sizes...............................................6
3.1.4. TTL.......................................................6
3.1.5. Trial Duration............................................6
4. FORWARDING AND THROUGHPUT......................................7
4.1. Mixed Class Throughput.......................................7
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............................................16
5.1. Multicast Latency...........................................17
5.2. Min/Max Multicast Latency...................................19
6. OVERHEAD......................................................20
6.1. Group Join Delay............................................20
6.2. Group Leave Delay...........................................23
7. CAPACITY......................................................25
7.1. Multicast Group Capacity....................................25
8. INTERACTION...................................................26
8.1. Forwarding Burdened Multicast Latency.......................26
8.2. Forwarding Burdened Group Join Delay........................27
9. SECURITY CONSIDERATIONS.......................................28
10. ACKNOWLEDGEMENTS.............................................29 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.
11. CONTRIBUTIONS................................................29 3. Test set up
12. REFERENCES...................................................30 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.
13. AUTHOR'S ADDRESSES...........................................31 Figure 1 shows a typical setup for an IP multicast test, with one
source to multiple destinations.
14. FULL COPYRIGHT STATEMENT.....................................31 +------------+ +--------------+
1. Introduction | | | destination |
+--------+ | Egress(-)------->| test |
| source | | | | port(E1) |
| test |------>(|)Ingress | +--------------+
| port | | | +--------------+
+--------+ | Egress(-)------->| destination |
| | | test |
| | | port(E2) |
| DUT | +--------------+
| | . . .
| | +--------------+
| | | destination |
| Egress(-)------->| test |
| | | port(En) |
+------------+ +--------------+
This document defines tests for measuring and reporting the Figure 1
throughput, forwarding, latency and 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.
A previous document, " Terminology for IP Multicast Benchmarking" If the multicast metrics are to be taken across multiple devices
(RFC 2432), defined many of the terms that are used in this forming a System Under Test (SUT), then test frames are offered to a
document. The terminology document should be consulted before single ingress interface on a device of the SUT, subsequently
attempting to make use of this document. 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.
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. +--------+ | +----------------+ | +--------+
| | | +------------+ |DUT B Egress E0(-)-|->| |
| | | |DUT A |--->| | | | |
| source | | | | | Egress E1(-)-|->| dest. |
| test |--|->(-)Ingress, I | +----------------+ | | test |
| port | | | | +----------------+ | | port |
| | | | |--->|DUT C Egress E2(-)-|->| |
| | | +------------+ | | | | |
| | | | Egress En(-)-|->| |
+--------+ | +----------------+ | +--------+
| |
*------------------SUT--------------------*
2. Key Words to Reflect Requirements Figure 2
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL Generally, the destination test ports first join the desired number
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" of multicast groups by sending IGMP Group Report messages to the
in this document are to be interpreted as described in RFC 2119. DUT/SUT. To verify that all destination test ports successfully
RFC 2119 defines the use of these key words to help make the intent joined the appropriate groups, the source test port MUST transmit IP
of standards track documents as clear as possible. While this multicast frames destined for these groups. After test completion,
document uses these keywords, this document is not a standards the destination test ports MAY send IGMP Leave Group messages to
track document. clear the IGMP table of the DUT/SUT.
3. Test set up 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 set of methodologies presented in this document are for single 3.1. Test Considerations
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.
Figure 1 shows a typical setup for an IP multicast test, with one The methodology assumes a uniform medium topology. Issues regarding
source to multiple destinations. 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.
+------------+ +--------------+ An actual flow of test traffic MAY be required to prime related
| | | destination | mechanisms, (e.g., process RPF events, build device caches, etc.) to
+--------+ | Egress(-)------->| test | optimally forward subsequent traffic. Therefore, prior to running
| source | | | | port(E1) | any tests that require forwarding of multicast or unicast packets,
| test |------>(|)Ingress | +--------------+ the test apparatus MUST generate test traffic utilizing the same
| port | | | +--------------+ addressing characteristics to the DUT/SUT that will subsequently be
+--------+ | Egress(-)------->| destination | used to measure the DUT/SUT response. The test monitor should ensure
| | | test | the correct forwarding of traffic by the DUT/SUT. The priming action
| | | port(E2) | need only be repeated to keep the associated information current.
| DUT | +--------------+
| | . . .
| | +--------------+
| | | destination |
| Egress(-)------->| test |
| | | port(En) |
+------------+ +--------------+
Figure 1 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.
If the multicast metrics are to be taken across multiple devices It has been noted that the formation of the multicast distribution
forming a System Under Test (SUT), then test frames are offered to tree may be a significant component of multicast performance. While
a single ingress interface on a device of the SUT, subsequently this component may be present in some of the measurements or
forwarded across the SUT topology, and finally forwarded to the scenarios presented in this memo, this memo does not seek to
test apparatus' frame-receiving components by the test egress explicitly benchmark the formation of the multicast distribution
interface(s) of devices in the SUT. Figure 2 offers an example SUT tree. The benchmarking of the multicast distribution tree formation
test topology. If a SUT is tested, the test topology and all is left as future, more targeted work specific to a given tree
relevant configuration details MUST be disclosed with the formation vehicle.
corresponding test results.
*-----------------------------------------* 3.1.1. IGMP Support
| |
+--------+ | +----------------+ | +--------+
| | | +------------+ |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 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.
Generally, the destination test ports first join the desired number Each of the ingress and egress interfaces SHOULD be able to respond
of multicast groups by sending IGMP Group Report messages to the to IGMP queries during the test.
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.
In addition, test equipment MUST validate the correct and proper Each of the ingress and egress interfaces SHOULD also send LEAVE
forwarding actions of the devices they test in order to ensure the (running IGMP version 2 or later) [Ca02] [Fe97] after each test.
receipt of the frames that are involved in the test.
3.1. Test Considerations 3.1.2. Group Addresses
The methodology assumes a uniform medium topology. Issues regarding There is no restriction to the use of multicast addresses [De89] to
mixed transmission media, such as speed mismatch, headers compose the test traffic other than those assignments imposed by
differences, etc., are not specifically addressed. Flow control, IANA. The IANA assignments for multicast addresses [IANA1] MUST be
QoS and other non-essential traffic or traffic-affecting mechanisms regarded for operational consistency. Address selection does not
affecting the variable under test MUST be disabled. Modifications need to be restricted to Administratively Scoped IP Multicast
to the collection procedures might need to be made to accommodate addresses [Me98].
the transmission media actually tested. These accommodations MUST
be presented with the test results.
An actual flow of test traffic MAY be required to prime related 3.1.3. Frame Sizes
mechanisms, (e.g., process RPF events, build device caches, etc.)
to optimally forward subsequent traffic. Therefore, prior to
running any tests that require forwarding of multicast or unicast
packets, the test apparatus MUST generate test traffic utilizing
the same addressing characteristics to the DUT/SUT that will
subsequently be used to measure the DUT/SUT response. The test
monitor should ensure the correct forwarding of traffic by the
DUT/SUT. The priming action need only be repeated to keep the
associated information current.
It is the intent of this memo to provide the methodology for basic Each test SHOULD be run with different multicast frame sizes. For
characterizations regarding the forwarding of multicast packets by Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280,
a device or simple system of devices. These characterizations may and 1518 byte frames.
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 Other link layer technologies MAY be used. The minimum and maximum
tree may be a significant component of multicast performance. frame lengths of the link layer technology in use SHOULD be tested.
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 When testing with different frame sizes, the DUT/SUT configuration
MUST remain the same.
All of the ingress and egress interfaces MUST support a version of 3.1.4. TTL
IGMP. The IGMP version on the ingress interface MUST be the same
version of IGMP that is being tested on the egress interfaces.
Each of the ingress and egress interfaces SHOULD be able to respond The data plane test traffic should have a TTL value large enough to
to IGMP queries during the test. traverse the DUT/SUT.
Each of the ingress and egress interfaces SHOULD also send LEAVE The TTL in IGMP control plane messages MUST be in compliance with the
(running IGMP version 2 or later) after each test. version of IGMP in use.
3.1.2. Group Addresses 3.1.5. Trial Duration
There is no restriction to the use of multicast addresses to The duration of the test portion of each trial SHOULD be at least 30
compose the test traffic other than those assignments imposed by seconds. This parameter MUST be included as part of the results
IANA. The IANA assignments for multicast addresses[IANA1] MUST be reporting for each methodology.
regarded for operational consistency. Address selection does not
need to be restricted to Administratively Scoped IP Multicast
addresses[Me89].
3.1.3. Frame Sizes 4. Forwarding and Throughput
Each test SHOULD be run with different multicast frame sizes. For This section contains the description of the tests that are related
Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280, to the characterization of the frame forwarding of a DUT/SUT in a
and 1518 byte frames. multicast environment. Some metrics extend the concept of throughput
presented in RFC 1242. Forwarding Rate is cited in RFC 2285 [Ma98].
Other link layer technologies MAY be used. The minimum and maximum 4.1. Mixed Class Throughput
frame lengths of the link layer technology in use SHOULD be tested.
When testing with different frame sizes, the DUT/SUT configuration Objective:
MUST remain the same.
3.1.4. TTL 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.
The data plane test traffic should have a TTL value large enough to Procedure:
traverse the DUT/SUT.
The TTL in IGMP control plane messages MUST be in compliance with Multicast and unicast traffic are mixed together in the same
the version of IGMP in use. aggregated traffic stream in order to simulate a heterogeneous
networking environment.
3.1.5. Trial Duration The following events MUST occur before offering test traffic:
The duration of the test portion of each trial SHOULD be at least o All destination test ports configured to receive multicast
30 seconds. This parameter MUST be included as part of the results traffic MUST join all configured multicast groups;
reporting for each methodology. o The DUT/SUT MUST learn the appropriate unicast and
multicast addresses; and
4. Forwarding and Throughput o Group membership and unicast address learning MUST be
verified through some externally observable method.
This section contains the description of the tests that are related The intended load [Ma98] SHOULD be configured as alternating
to the characterization of the frame forwarding of a DUT/SUT in a multicast class frames and unicast class frames to a single ingress
multicast environment. Some metrics extend the concept of throughput interface. The unicast class frames MUST be configured to transmit
presented in RFC 1242. Forwarding Rate is cited in RFC 2285 [Ma98]. in an unweighted round-robin fashion to all of the destination ports.
4.1. Mixed Class Throughput 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:
Objective: m1 u1 m2 u2 m3 u3 m4 u1 m5 u2 m6 u3 m1 ...
To determine the throughput of a DUT/SUT when both unicast class Where:
frames and multicast class frames are offered simultaneously to a
fixed number of interfaces as defined in RFC 2432.
Procedure: m<Number> = Multicast Frame<Group>
u<Number> = Unicast Frame<Target Port>
Multicast and unicast traffic are mixed together in the same Mixed class throughput measurement is defined in RFC 2432 [Du98]. A
aggregated traffic stream in order to simulate a heterogeneous search algorithm MUST be utilized to determine the Mixed Class
networking environment. Throughput. The ratio of unicast to multicast frames MUST remain the
same when varying the intended load.
The following events MUST occur before offering test traffic: Reporting Format:
o All destination test ports configured to receive multicast The following configuration parameters MUST be reflected in the test
traffic MUST join all configured multicast groups; report:
o The DUT/SUT MUST learn the appropriate unicast and
multicast addresses; and
o Group membership and unicast address learning MUST be
verified through some externally observable method.
The intended load [Ma98] SHOULD be configured as alternating o Frame size(s)
multicast class frames and unicast class frames to a single ingress o Number of tested egress interfaces on the DUT/SUT
interface. The unicast class frames MUST be configured to transmit o Test duration
in an unweighted round-robin fashion to all of the destination o IGMP version
ports. o Total number of multicast groups
o Traffic distribution for unicast and multicast traffic
classes
o The ratio of multicast to unicast class traffic
For example, with six multicast groups and 3 destination ports with The following results MUST be reflected in the test report:
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 ... o Mixed Class Throughput as defined in RFC 2432 [Du98],
including: Throughput per unicast and multicast traffic
classes.
Where: 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.
m<Number> = Multicast Frame<Group> 4.2. Scaled Group Forwarding Matrix
u<Number> = Unicast Frame<Target Port>
Mixed class throughput measurement is defined in RFC2432 [Du98]. A Objective:
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.
Reporting Format: To determine Forwarding Rate as a function of tested multicast groups
for a fixed number of tested DUT/SUT ports.
The following configuration parameters MUST be reflected in the Procedure:
test report:
o Frame size(s) This is an iterative procedure. The destination test port(s) MUST
o Number of tested egress interfaces on the DUT/SUT join an initial number of multicast groups on the first iteration.
o Test duration All destination test ports configured to receive multicast traffic
o IGMP version MUST join all configured multicast groups. The recommended number of
o Total number of multicast groups groups to join on the first iteration is 10 groups. Multicast
o Traffic distribution for unicast and multicast traffic traffic is subsequently transmitted to all groups joined on this
classes iteration and the forwarding rate is measured.
o The ratio of multicast to unicast class traffic
The following results MUST be reflected in the test report: 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.
o Mixed Class Throughput as defined in RFC2432 [Du98], The total number of multicast groups joined MUST not exceed the
including: Throughput per unicast and multicast traffic multicast group capacity of the DUT/SUT. The Group Capacity (Section
classes. 7.1) results MUST be known prior to running this test.
The Mixed Class Throughput results for each test SHOULD be reported Reporting Format:
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.
4.2. Scaled Group Forwarding Matrix The following configuration parameters MUST be reflected in the test
report:
Objective: o Frame size(s)
o Number of tested egress interfaces on the DUT/SUT
o Test duration
o IGMP version
To determine Forwarding Rate as a function of tested multicast The following results MUST be reflected in the test report:
groups for a fixed number of tested DUT/SUT ports.
Procedure: o The total number of multicast groups joined for that
iteration
This is an iterative procedure. The destination test port(s) MUST o Forwarding rate determined for that iteration
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.
The number of multicast groups joined by each destination test port The Scaled Group Forwarding results for each test SHOULD be reported
is then incremented, or scaled, by an additional number of in the form of a table with a row representing each iteration of the
multicast groups. The recommended granularity of additional groups test. Each row or iteration SHOULD specify the total number of
to join per iteration is 10, although the tester MAY choose a finer groups joined for that iteration, offered load, total number of
granularity. Multicast traffic is subsequently transmitted to all frames transmitted, total number of frames received and the aggregate
groups joined during this iteration and the forwarding rate is forwarding rate determined for that iteration.
measured.
The total number of multicast groups joined MUST not exceed the 4.3. Aggregated Multicast Throughput
multicast group capacity of the DUT/SUT. The Group Capacity
(Section 7.1) results MUST be known prior to running this test.
Reporting Format: Objective:
The following configuration parameters MUST be reflected in the To determine the maximum rate at which none of the offered frames to
test report: be forwarded through N destination interfaces of the same multicast
groups are dropped.
o Frame size(s) Procedure:
o Number of tested egress interfaces on the DUT/SUT
o Test duration
o IGMP version
The following results MUST be reflected in the test report: 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.
o The total number of multicast groups joined for that If any frame loss is detected, the offered load is decreased and the
iteration sender will transmit again. An iterative search algorithm MUST be
o Forwarding rate determined for that iteration utilized to determine the maximum offered frame rate with a zero
frame loss.
The Scaled Group Forwarding results for each test SHOULD be Each iteration will involve varying the offered load of the multicast
reported in the form of a table with a row representing each traffic, while keeping the set of interfaces, number of multicast
iteration of the test. Each row or iteration SHOULD specify the groups, frame length and test duration fixed, until the maximum rate
total number of groups joined for that iteration, offered load, at which none of the offered frames are dropped is determined.
total number of frames transmitted, total number of frames received
and the aggregate forwarding rate determined for that iteration.
4.3. Aggregated Multicast Throughput 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.
Objective: Reporting Format:
To determine the maximum rate at which none of the offered frames The following configuration parameters MUST be reflected in the test
to be forwarded through N destination interfaces of the same report:
multicast groups are dropped.
Procedure: 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
Offer multicast traffic at an initial maximum offered load to a The following results MUST be reflected in the test report:
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 o Aggregated Multicast Throughput as defined in RFC 2432
the sender will transmit again. An iterative search algorithm MUST [Du98]
be utilized to determine the maximum offered frame rate with a zero
frame loss.
Each iteration will involve varying the offered load of the The Aggregated Multicast Throughput results SHOULD be reported in the
multicast traffic, while keeping the set of interfaces, number of format of a table with a row for each of the tested frame sizes per
multicast groups, frame length and test duration fixed, until the the recommendations in section 3.1.3. Each row or iteration SHOULD
maximum rate at which none of the offered frames are dropped is specify offered load, total number of offered frames and the measured
determined. Aggregated Multicast Throughput.
Parameters to be measured MUST include the maximum offered load at 4.4. Encapsulation/Decapsulation (Tunneling) Throughput
which no frame loss occurred. Other offered loads MAY be measured
for diagnostic purposes.
Reporting Format: 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.
The following configuration parameters MUST be reflected in the For this specific testing scenario, encapsulation or tunneling refers
test report: to a packet that contains an unsupported protocol feature in a format
that is supported by the DUT/SUT.
o Frame size(s) 4.4.1. Encapsulation Throughput
o Number of tested egress interfaces on the DUT/SUT
o Test duration
o IGMP version
o Total number of multicast groups
The following results MUST be reflected in the test report: Objective:
o Aggregated Multicast Throughput as defined in RFC2432 To determine the maximum rate at which frames offered to one ingress
[Du98] interface of a DUT/SUT are encapsulated and correctly forwarded on
one or more egress interfaces of the DUT/SUT without loss.
The Aggregated Multicast Throughput results SHOULD be reported in Procedure:
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.
4.4. Encapsulation/Decapsulation (Tunneling) Throughput Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
| |------->|Ingress | | |
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
+---------+ +-----------+ +---------+
This sub-section provides the description of tests related to the Figure 3
determination of throughput measurements when a DUT/SUT or a set of
DUTs are acting as tunnel endpoints.
For this specific testing scenario, encapsulation or tunneling Figure 3 shows the setup for testing the encapsulation throughput of
refers to a packet that contains an unsupported protocol feature in the DUT/SUT. One or more tunnels are created between each egress
a format that is supported by the DUT/SUT. 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).
4.4.1. Encapsulation Throughput The DUT/SUT SHOULD be configured such that the traffic across each
egress interface will consist of either:
Objective: a) A single tunnel encapsulating one or more multicast address
groups OR
b) Multiple tunnels, each encapsulating one or more multicast
address groups.
To determine the maximum rate at which frames offered to one The number of multicast groups per tunnel MUST be the same when the
ingress interface of a DUT/SUT are encapsulated and correctly DUT/SUT is configured in a multiple tunnel configuration. In
forwarded on one or more egress interfaces of the DUT/SUT without addition, it is RECOMMENDED to test with the same number of tunnels
loss. 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.
Procedure: 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.
Source DUT/SUT Destination A search algorithm MUST be utilized to determine the encapsulation
Test Port Test Port(s) throughput as defined in [Du98].
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
| |------->|Ingress | | |
| | | | | |
| | | Egress|--(Tunnel)-->| |
| | | | | |
+---------+ +-----------+ +---------+
Figure 3 Reporting Format:
---------
Figure 3 shows the setup for testing the encapsulation throughput The following configuration parameters MUST be reflected in the test
of the DUT/SUT. One or more tunnels are created between each report:
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).
The DUT/SUT SHOULD be configured such that the traffic across each o Number of tested egress interfaces on the DUT/SUT
egress interface will consist of either: 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
a) A single tunnel encapsulating one or more multicast address The following results MUST be reflected in the test report:
groups OR
b) Multiple tunnels, each encapsulating one or more multicast
address groups.
The number of multicast groups per tunnel MUST be the same when the o Measured Encapsulated Throughput as defined in RFC 2432
DUT/SUT is configured in a multiple tunnel configuration. In [Du98]
addition, it is RECOMMENDED to test with the same number of tunnels o Encapsulated frame size
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.
Note: when offering large frames sizes, the encapsulation process The Encapsulated Throughput results SHOULD be reported in the form of
may require the DUT/SUT to fragment the IP datagrams prior to being a table and specific to this test there SHOULD be rows for each
forwarded on the egress interface. It is RECOMMENDED to limit the originating un-encapsulated frame size. Each row or iteration SHOULD
offered frame size such that no fragmentation is required by the specify the offered load, encapsulation method, encapsulated frame
DUT/SUT. size, total number of offered frames, and the encapsulation
throughput.
A search algorithm MUST be utilized to determine the encapsulation 4.4.2. Decapsulation Throughput
throughput as defined in [Du98].
Reporting Format: Objective:
The following configuration parameters MUST be reflected in the To determine the maximum rate at which frames offered to one ingress
test report: interface of a DUT/SUT are decapsulated and correctly forwarded by
the DUT/SUT on one or more egress interfaces without loss.
o Number of tested egress interfaces on the DUT/SUT Procedure:
o Test duration
o IGMP version
o Total number of multicast groups
o MTU size of DUT/SUT interfaces
o Originating un-encapsulated frame size
o Number of tunnels per egress interface
o Number of multicast groups per tunnel
o Encapsulation algorithm or format used to tunnel the
packets
The following results MUST be reflected in the test report: Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +-----------+ +---------+
| | | | | |
| | | Egress|------->| |
| | | | | |
| |--(Tunnel)-->|Ingress | | |
| | | | | |
| | | Egress|------->| |
| | | | | |
+---------+ +-----------+ +---------+
o Measured Encapsulated Throughput as defined in RFC2432 Figure 4
[Du98]
o Encapsulated frame size
The Encapsulated Throughput results SHOULD be reported in the form Figure 4 shows the setup for testing the decapsulation throughput of
of a table and specific to this test there SHOULD be rows for each the DUT/SUT. One or more tunnels are created between the source test
originating un-encapsulated frame size. Each row or iteration port and the DUT/SUT. Encapsulated multicast traffic will then be
SHOULD specify the offered load, encapsulation method, encapsulated offered by the source test port, decapsulated by the DUT/SUT and
frame size, total number of offered frames, and the encapsulation forwarded to the destination test port(s).
throughput.
4.4.2. Decapsulation Throughput The DUT/SUT SHOULD be configured such that the traffic across the
ingress interface will consist of either:
Objective: a) A single tunnel encapsulating one or more multicast address
groups OR
b) Multiple tunnels, each encapsulating one or more multicast
address groups.
To determine the maximum rate at which frames offered to one The number of multicast groups per tunnel MUST be the same when the
ingress interface of a DUT/SUT are decapsulated and correctly DUT/SUT is configured in a multiple tunnel configuration. All
forwarded by the DUT/SUT on one or more egress interfaces without destination test ports MUST join all multicast group addresses
loss. offered by the source test port. Each egress interface MUST be
configured with the same MTU.
Procedure: A search algorithm MUST be utilized to determine the decapsulation
throughput as defined in [Du98].
Source DUT/SUT Destination When making performance comparisons between the encapsulation and
Test Port Test Port(s) 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.
| | | Egress|------->| |
| | | | | |
| |--(Tunnel)-->|Ingress | | |
| | | | | |
| | | Egress|------->| |
| | | | | |
+---------+ +-----------+ +---------+
Figure 4 Reporting Format:
---------
Figure 4 shows the setup for testing the decapsulation throughput The following configuration parameters MUST be reflected in the test
of the DUT/SUT. One or more tunnels are created between the source report:
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).
The DUT/SUT SHOULD be configured such that the traffic across the o Number of tested egress interfaces on the DUT/SUT
ingress interface will consist of either: 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
a) A single tunnel encapsulating one or more multicast address The following results MUST be reflected in the test report:
groups OR
b) Multiple tunnels, each encapsulating one or more multicast
address groups.
The number of multicast groups per tunnel MUST be the same when the o Measured Decapsulated Throughput as defined in RFC 2432
DUT/SUT is configured in a multiple tunnel configuration. All [Du98]
destination test ports MUST join all multicast group addresses o Decapsulated frame size
offered by the source test port. Each egress interface MUST
be configured with the same MTU.
A search algorithm MUST be utilized to determine the decapsulation The Decapsulated Throughput results SHOULD be reported in the format
throughput as defined in [Du98]. 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.
When making performance comparisons between the encapsulation and 4.4.3. Re-encapsulation Throughput
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.
Reporting Format: Objective:
The following configuration parameters MUST be reflected in the To determine the maximum rate at which frames of one encapsulated
test report: 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.
o Number of tested egress interfaces on the DUT/SUT Procedure:
o Test duration
o IGMP version
o Total number of multicast groups
o Originating encapsulation algorithm or format used to
tunnel the packets
o Originating encapsulated frame size
o Number of tunnels
o Number of multicast groups per tunnel
The following results MUST be reflected in the test report: Source DUT/SUT Destination
Test Port Test Port(s)
+---------+ +---------+ +---------+
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
| |-(Tunnel)->|Ingress | | |
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
+---------+ +---------+ +---------+
o Measured Decapsulated Throughput as defined in RFC2432 Figure 5
[Du98]
o Decapsulated frame size
The Decapsulated Throughput results SHOULD be reported in the Figure 5 shows the setup for testing the Re-encapsulation throughput
format of a table and specific to this test there SHOULD be rows of the DUT/SUT. The source test port will offer encapsulated traffic
for each originating encapsulated frame size. Each row or of one type to the DUT/SUT, which has been configured to re-
iteration SHOULD specify the offered load, decapsulated frame size, encapsulate the offered frames using a different encapsulation
total number of offered frames and the decapsulation throughput. format. The DUT/SUT will then forward the re-encapsulated frames to
the destination test port(s).
4.4.3. Re-encapsulation Throughput The DUT/SUT SHOULD be configured such that the traffic across the
ingress and each egress interface will consist of either:
Objective: a) A single tunnel encapsulating one or more multicast address
groups OR
b) Multiple tunnels, each encapsulating one or more multicast
address groups.
To determine the maximum rate at which frames of one encapsulated The number of multicast groups per tunnel MUST be the same when the
format offered to one ingress interface of a DUT/SUT are converted DUT/SUT is configured in a multiple tunnel configuration. In
to another encapsulated format and correctly forwarded by the addition, the DUT/SUT SHOULD be configured such that the number of
DUT/SUT on one or more egress interfaces without loss. 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.
Procedure: 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.
Source DUT/SUT Destination A search algorithm MUST be utilized to determine the re-encapsulation
Test Port Test Port(s) throughput as defined in [Du98].
+---------+ +---------+ +---------+
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
| |-(Tunnel)->|Ingress | | |
| | | | | |
| | | Egress|-(Tunnel)->| |
| | | | | |
+---------+ +---------+ +---------+
Figure 5 Reporting Format:
---------
Figure 5 shows the setup for testing the Re-encapsulation The following configuration parameters MUST be reflected in the test
throughput of the DUT/SUT. The source test port will offer report:
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).
The DUT/SUT SHOULD be configured such that the traffic across the o Number of tested egress interfaces on the DUT/SUT
ingress and each egress interface will consist of either: 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
a) A single tunnel encapsulating one or more multicast address The following results MUST be reflected in the test report:
groups OR
b) Multiple tunnels, each encapsulating one or more multicast
address groups.
The number of multicast groups per tunnel MUST be the same when the o Measured Re-encapsulated Throughput as defined in RFC 2432
DUT/SUT is configured in a multiple tunnel configuration. In [Du98]
addition, the DUT/SUT SHOULD be configured such that the number of o Re-encapsulated frame size
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.
Note that when offering large frames sizes, the encapsulation The Re-encapsulated Throughput results SHOULD be reported in the
process may require the DUT/SUT to fragment the IP datagrams prior format of a table and specific to this test there SHOULD be rows for
to being forwarded on the egress interface. It is RECOMMENDED to each originating encapsulated frame size. Each row or iteration
limit the offered frame sizes, such that no fragmentation is SHOULD specify the offered load, Re-encapsulated frame size, total
required by the DUT/SUT. number of offered frames, and the Re-encapsulated Throughput.
A search algorithm MUST be utilized to determine the re- 5. Forwarding Latency
encapsulation throughput as defined in [Du98].
Reporting Format: 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.
The following configuration parameters MUST be reflected in the The offered load accompanying the latency-measured packet can affect
test report: 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.
o Number of tested egress interfaces on the DUT/SUT RFC 1242 and RFC 2544 draw a distinction between device types: "store
o Test duration and forward" and "bit-forwarding." Each type impacts how latency is
o IGMP version collected and subsequently presented. See the related RFCs for more
o Total number of multicast groups information.
o MTU size of DUT/SUT interfaces
o Originating encapsulation algorithm or format used to
tunnel the packets
o Re-encapsulation algorithm or format used to tunnel the
packets
o Originating encapsulated frame size
o Number of tunnels per interface
o Number of multicast groups per tunnel
The following results MUST be reflected in the test report: 5.1. Multicast Latency
o Measured Re-encapsulated Throughput as defined in RFC2432 Objective:
[Du98]
o Re-encapsulated frame size
The Re-encapsulated Throughput results SHOULD be reported in the To produce a set of multicast latency measurements from a single,
format of a table and specific to this test there SHOULD be rows multicast ingress interface of a DUT/SUT through multiple, egress
for each originating encapsulated frame size. Each row or multicast interfaces of that same DUT/SUT as provided for by the
iteration SHOULD specify the offered load, decapsulated frame size, metric "Multicast Latency" in RFC 2432 [Du98].
total number of offered frames and the Re-encapsulated Throughput.
5. Forwarding Latency 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.
This section presents methodologies relating to the Procedure:
characterization of the forwarding latency of a DUT/SUT in a
multicast environment. It extends the concept of latency
characterization presented in RFC 2544.
The offered load accompanying the latency-measured packet can If the test trial is to characterize latency across a single Device
affect the DUT/SUT packet buffering, which may subsequently impact Under Test (DUT), an example test topology might take the form of
measured packet latency. This SHOULD be a consideration when Figure 1 in section 3. That is, a single DUT with one ingress
selecting the intended load for the described methodologies below. 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).
RFC 1242 and RFC 2544 draw a distinction between device types: If the multicast latencies are to be taken across multiple devices
"store and forward" and "bit-forwarding." Each type impacts how forming a System Under Test (SUT), an example test topology might
latency is collected and subsequently presented. See the related take the form of Figure 2 in section 3.
RFCs for more information.
5.1. Multicast Latency 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.
Objective: 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.
To produce a set of multicast latency measurements from a single, The test apparatus will monitor frames from the DUT's tested egress
multicast ingress interface of a DUT/SUT through multiple, egress interface(s) for the expected tagged frame(s) and MUST record the
multicast interfaces of that same DUT/SUT as provided for by the time of the successful detection of a tagged frame from a tested
metric "Multicast Latency" in RFC 2432 [Du98]. 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.
The procedures below draw from the collection methodology for A trial MUST be considered INVALID should any of the following
latency in RFC 2544 [Br96]. The methodology addresses two conditions occur in the collection of the trial data:
topological scenarios: one for a single device (DUT)
characterization; a second scenario is presented or multiple device
(SUT) characterization.
Procedure: 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.
If the test trial is to characterize latency across a single Device The set of latency measurements, M, composed from each latency
Under Test (DUT), an example test topology might take the form of measurement taken from every ingress/tested egress interface pairing
Figure 1 in section 3. That is, a single DUT with one ingress MUST be determined from a valid test trial:
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).
If the multicast latencies are to be taken across multiple devices M = { (Timestamp B(E0) - Timestamp A),
forming a System Under Test (SUT), an example test topology might (Timestamp B(E1) - Timestamp A), ...
take the form of Figure 2 in section 3. (Timestamp B(En) - Timestamp A) }
The trial duration SHOULD be 120 seconds to be consistent with RFC where (E0 ... En) represents the range of all tested egress
2544 [Br96]. The nature of the latency measurement, "store and interfaces and Timestamp B represents a tagged frame detection event
forward" or "bit forwarding," MUST be associated with the related for a given DUT/SUT tested egress interface.
test trial(s) and disclosed in the results report.
A test traffic stream is presented to the DUT. It is RECOMMENDED to A more continuous profile MAY be built from a series of individual
offer traffic at the measured aggregated multicast throughput rate measurements.
(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.
The test apparatus will monitor frames from the DUT's tested egress Reporting Format:
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.
A trial MUST be considered INVALID should any of the following The following configuration parameters MUST be reflected in the test
conditions occur in the collection of the trial data: report:
o Unexpected differences between Intended Load and Offered o Frame size(s)
Load or unexpected differences between Offered Load and the o Number of tested egress interfaces on the DUT/SUT
resulting Forwarding Rate(s) on the DUT/SUT egress ports. o Test duration
o Forwarded test frames improperly formed or frame header o IGMP version
fields improperly manipulated. o Offered load
o Failure to forward required tagged frame(s) on all expected o Total number of multicast groups
egress interfaces.
o Reception of tagged frames by the test apparatus more than
5 seconds after the cessation of test traffic by the source
test port.
The set of latency measurements, M, composed from each latency The following results MUST be reflected in the test report:
measurement taken from every ingress/tested egress interface
pairing MUST be determined from a valid test trial:
M = { (Timestamp B(E0) - Timestamp A), o The set of all latencies with respective time units related
(Timestamp B(E1) - Timestamp A), ... to the tested ingress and each tested egress DUT/SUT
(Timestamp B(En) - Timestamp A) } interface.
where (E0 ... En) represents the range of all tested egress The time units of the presented latency MUST be uniform and with
interfaces and Timestamp B represents a tagged frame detection sufficient precision for the medium or media being tested.
event for a given DUT/SUT tested egress interface.
A more continuous profile MAY be built from a series of individual The results MAY be offered in a tabular format and should preserve
measurements. the relationship of latency to ingress/egress interface for each
multicast group to assist in trending across multiple trials.
Reporting Format: 5.2. Min/Max Multicast Latency
The following configuration parameters MUST be reflected in the Objective:
test report:
o Frame size(s) To determine the difference between the maximum latency measurement
o Number of tested egress interfaces on the DUT/SUT and the minimum latency measurement from a collected set of latencies
o Test duration produced by the Multicast Latency benchmark.
o IGMP version
o Offered load
o Total number of multicast groups
The following results MUST be reflected in the test report: Procedure:
o The set of all latencies with respective time units related Collect a set of multicast latency measurements over a single test
to the tested ingress and each tested egress DUT/SUT duration, as prescribed in section 5.1. This will produce a set of
interface. multicast latencies, M, where M is composed of individual forwarding
latencies between DUT frame ingress and DUT frame egress port pairs.
E.g.:
The time units of the presented latency MUST be uniform and with M = {L(I,E1),L(I,E2), ..., L(I,En)}
sufficient precision for the medium or media being tested.
The results MAY be offered in a tabular format and should preserve where L is the latency between a tested ingress interface, I, of the
the relationship of latency to ingress/egress interface for each DUT, and Ex a specific, tested multicast egress interface of the DUT.
multicast group to assist in trending across multiple trials. E1 through En are unique egress interfaces on the DUT.
5.2. Min/Max Multicast Latency 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.
Objective: Identify MIN(M), when MIN is a function that yields the smallest
latency value from set M.
To determine the difference between the maximum latency measurement The Max/Min value is determined from the following formula:
and the minimum latency measurement from a collected set of
latencies produced by the Multicast Latency benchmark.
Procedure: Result = MAX(M) - MIN(M)
Collect a set of multicast latency measurements over a single test Reporting Format:
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.:
M = {L(I,E1),L(I,E2), ..., L(I,En)} The following configuration parameters MUST be reflected in the test
report:
where L is the latency between a tested ingress interface, I, of o Frame size(s)
the DUT, and Ex a specific, tested multicast egress interface of o Number of tested egress interfaces on the DUT/SUT
the DUT. E1 through En are unique egress interfaces on the DUT. o Test duration
o IGMP version
o Offered load
o Total number of multicast groups
From the collected multicast latency measurements in set M, The following results MUST be reflected in the test report:
identify MAX(M), where MAX is a function that yields the largest
latency value from set M.
Identify MIN(M), when MIN is a function that yields the smallest o The Max/Min value
latency value from set M.
The Max/Min value is determined from the following formula: The following results SHOULD be reflected in the test report:
Result = MAX(M) - MIN(M) o The set of all latencies with respective time units related
to the tested ingress and each tested egress DUT/SUT
interface.
Reporting Format: The time units of the presented latency MUST be uniform and with
sufficient precision for the medium or media being tested.
The following configuration parameters MUST be reflected in the The results MAY be offered in a tabular format and should preserve
test report: the relationship of latency to ingress/egress interface for each
multicast group.
o Frame size(s) 6. Overhead
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
The following results MUST be reflected in the test report: This section presents methodology relating to the characterization of
the overhead delays associated with explicit operations found in
multicast environments.
o The Max/Min value 6.1. Group Join Delay
The following results SHOULD be reflected in the test report: Objective:
o The set of all latencies with respective time units related To determine the time duration it takes a DUT/SUT to start forwarding
to the tested ingress and each tested egress DUT/SUT multicast frames from the time a successful IGMP group membership
interface. report has been issued to the DUT/SUT.
The time units of the presented latency MUST be uniform and with Procedure:
sufficient precision for the medium or media being tested.
The results MAY be offered in a tabular format and should preserve The Multicast Group Join Delay measurement may be influenced by the
the relationship of latency to ingress/egress interface for each state of the Multicast Forwarding Database <MFDB> of the DUT/SUT. The
multicast group. states of the MFDB may be described as follows:
6. Overhead 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.
This section presents methodology relating to the characterization o State 1, where the MFDB does contain the specified multicast
of the overhead delays associated with explicit operations found in group address. In this state, the delay measurement includes
multicast environments. 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.
6.1. Group Join Delay 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.
Objective: 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.
To determine the time duration it takes a DUT/SUT to start In order to minimize the variation in delay calculations as well as
forwarding multicast frames from the time a successful IGMP group minimize burden on the DUT/SUT, the test SHOULD be performed with one
membership report has been issued to the DUT/SUT. multicast group. In addition, all destination test ports MUST join
the specified multicast group offered to the ingress interface of the
DUT/SUT.
Procedure: Method A:
The Multicast Group Join Delay measurement may be influenced by the Method A assumes that the Multicast Forwarding Database <MFDB> of the
state of the Multicast Forwarding Database <MFDB> of the DUT/SUT. DUT/SUT does not contain or has not learned the specified multicast
The states of the MFDB may be described as follows: 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.
. State 0, where the MFDB does not contain the specified Prior to sending any IGMP Group Membership Reports used to calculate
multicast group address. In this state, the delay measurement the Multicast Group Join Delay, it MUST be verified through
includes the time the DUT/SUT requires to add the address to externally observable means that the destination test port is not
the MFDB and begin forwarding. Delay measured from State 0 currently a member of the specified multicast group. In addition, it
provides information about how the DUT/SUT is able to add new MUST be verified through externally observable means that the MFDB of
addresses into MFDB. the DUT/SUT does not contain the specified multicast address.
. State 1, where the MFDB does contain the specified multicast Method B:
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.
The methodology for the Multicast Group Join Delay measurement Method B assumes that the MFDB of the DUT/SUT does contain the
provides two alternate methods, based on the state of the MFDB, to specified multicast group address; specifically, the MFDB MUST be in
measure the delay metric. The methods MAY be used independently or State 1. In this scenario, the metric represents the time the
in conjunction to provide meaningful insight into the DUT/SUT DUT/SUT takes to update the MFDB with the additional nodes and their
ability to manage the MFDB. corresponding interfaces and to begin forwarding the multicast
packet. One or more egress ports MAY be used to determine this
metric.
Users MAY elect to use either method to determine the Multicast Prior to sending any IGMP Group Membership Reports used to calculate
Group Join Delay; however the collection method MUST be specified the Group Join Delay, it MUST be verified through externally
as part of the reporting format. 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.
In order to minimize the variation in delay calculations as well as Join Delay Calculation
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.
Method A: 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).
Method A assumes that the Multicast Forwarding Database <MFDB> of After the multicast traffic has been started, the destination test
the DUT/SUT does not contain or has not learned the specified port (See Figure 1) MUST send one IGMP Group Membership Report for
multicast group address; specifically, the MFDB MUST be in State 0. the specified multicast group.
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.
Prior to sending any IGMP Group Membership Reports used to The join delay is the difference in time from when the IGMP Group
calculate the Multicast Group Join Delay, it MUST be verified Membership message is sent (timestamp A) and the first frame of the
through externally observable means that the destination test port multicast group is forwarded to a receiving egress interface
is not currently a member of the specified multicast group. In (timestamp B).
addition, it MUST be verified through externally observable means
that the MFDB of the DUT/SUT does not contain the specified
multicast address.
Method B: Group Join delay time = timestamp B - timestamp A
Method B assumes that the MFDB of the DUT/SUT does contain the Timestamp A MUST be the time the last bit of the IGMP group
specified multicast group address; specifically, the MFDB MUST be membership report is sent from the destination test port; timestamp B
in State 1. In this scenario, the metric represents the time the MUST be the time the first bit of the first valid multicast frame is
DUT/SUT takes to update the MFDB with the additional nodes and forwarded on the egress interface of the DUT/SUT.
their corresponding interfaces and to begin forwarding the
multicast packet. One or more egress ports MAY be used to
determine this metric.
Prior to sending any IGMP Group Membership Reports used to Reporting Format:
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.
Join Delay Calculation The following configuration parameters MUST be reflected in the test
report:
Once verification is complete, multicast traffic for the specified o Frame size(s)
multicast group address MUST be offered to the ingress interface o Number of tested egress interfaces on the DUT/SUT
prior to the DUT/SUT receiving any IGMP Group Membership Report o IGMP version
messages. It is RECOMMENDED to offer traffic at the measured o Total number of multicast groups
aggregated multicast throughput rate (Section 4.3). o Offered load to ingress interface
o Method used to measure the join delay metric
After the multicast traffic has been started, the destination test The following results MUST be reflected in the test report:
port (See Figure 1) MUST send one IGMP Group Membership Report for
the specified multicast group.
The join delay is the difference in time from when the IGMP Group o The group join delay time in microseconds per egress
Membership message is sent (timestamp A) and the first frame of the interface(s)
multicast group is forwarded to a receiving egress interface
(timestamp B).
Group Join delay time = timestamp B - timestamp A 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.
Timestamp A MUST be the time the last bit of the IGMP group 6.2. Group Leave Delay
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.
Reporting Format: Objective:
The following configuration parameters MUST be reflected in the To determine the time duration it takes a DUT/SUT to cease forwarding
test report: multicast frames after a corresponding IGMP Leave Group message has
been successfully offered to the DUT/SUT.
o Frame size(s) Procedure:
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
The following results MUST be reflected in the test report: 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.
o The group join delay time in microseconds per egress Prior to sending any IGMP Leave Group messages used to calculate the
interface(s) 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.
The Group Join Delay results for each test MAY be reported in the Once verification is complete, multicast traffic for the specified
form of a table, with a row for each of the tested frame sizes per multicast group address MUST be offered to the ingress interface
the recommendations in section 3.1.3. Each row or iteration MAY prior to receipt or processing of any IGMP Leave Group messages. It
specify the group join delay time per egress interface for that is RECOMMENDED to offer traffic at the measured aggregated multicast
iteration. throughput rate (Section 4.3).
6.2. Group Leave Delay 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.
Objective: 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).
To determine the time duration it takes a DUT/SUT to cease Group Leave delay time = timestamp B - timestamp A
forwarding multicast frames after a corresponding IGMP Leave Group
message has been successfully offered to the DUT/SUT.
Procedure: 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.
In order to minimize the variation in delay calculations as well as Reporting Format:
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.
Prior to sending any IGMP Leave Group messages used to calculate The following configuration parameters MUST be reflected in the test
the group leave delay, it MUST be verified through externally report:
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.
Once verification is complete, multicast traffic for the specified o Frame size(s)
multicast group address MUST be offered to the ingress interface o Number of tested egress interfaces on the DUT/SUT
prior to receipt or processing of any IGMP Leave Group messages. o IGMP version
o Total number of multicast groups
o Offered load to ingress interface
It is RECOMMENDED to offer traffic at the measured aggregated The following results MUST be reflected in the test report:
multicast throughput rate (Section 4.3).
After the multicast traffic has been started, each destination test o The group leave delay time in microseconds per egress
port (See Figure 1) MUST send one IGMP Leave Group message for the interface(s)
specified multicast group.
The leave delay is the difference in time from when the IGMP Leave The Group Leave Delay results for each test MAY be reported in the
Group message is sent (timestamp A) and the last frame of the form of a table, with a row for each of the tested frame sizes per
multicast group is forwarded to a receiving egress interface the recommendations in section 3.1.3. Each row or iteration MAY
(timestamp B). specify the group leave delay time per egress interface for that
iteration.
Group Leave delay time = timestamp B - timestamp A 7. Capacity
Timestamp A MUST be the time the last bit of the IGMP Leave Group This section offers a procedure relating to the identification of
message is sent from the destination test port; timestamp B MUST be multicast group limits of a DUT/SUT.
the time the last bit of the last valid multicast frame is
forwarded on the egress interface of the DUT/SUT.
Reporting Format: 7.1. Multicast Group Capacity
The following configuration parameters MUST be reflected in the Objective:
test report:
o Frame size(s) To determine the maximum number of multicast groups a DUT/SUT can
o Number of tested egress interfaces on the DUT/SUT support while maintaining the ability to forward multicast frames to
o IGMP version all multicast groups registered to that DUT/SUT.
o Total number of multicast groups
o Offered load to ingress interface
The following results MUST be reflected in the test report: Procedure:
o The group leave delay time in microseconds per egress One or more destination test ports of DUT/SUT will join an initial
interface(s) number of multicast groups.
The Group Leave Delay results for each test MAY be reported in the After a minimum delay as measured by section 6.1, the source test
form of a table, with a row for each of the tested frame sizes per ports MUST transmit to each group at a specified offered load.
the recommendations in section 3.1.3. Each row or iteration MAY
specify the group leave delay time per egress interface for that
iteration.
7. Capacity 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.
This section offers a procedure relating to the identification of For each successful iteration, each destination test port will join
multicast group limits of a DUT/SUT. 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.
7.1. Multicast Group Capacity Once the iteration fails, the last successful iteration is the stated
Maximum Group Capacity result.
Objective: Reporting Format:
To determine the maximum number of multicast groups a DUT/SUT can The following configuration parameters MUST be reflected in the test
support while maintaining the ability to forward multicast frames report:
to all multicast groups registered to that DUT/SUT.
Procedure: o Frame size(s)
o Number of tested egress interfaces on the DUT/SUT
o IGMP version
o Offered load
One or more destination test ports of DUT/SUT will join an initial The following results MUST be reflected in the test report:
number of multicast groups.
After a minimum delay as measured by section 6.1, the source test o The total number of multicast group addresses that were
ports MUST transmit to each group at a specified offered load. successfully forwarded through the DUT/SUT
If at least one frame for each multicast group is forwarded The Multicast Group Capacity results for each test SHOULD be reported
properly by the DUT/SUT on each participating egress interface, the in the form of a table, with a row for each of the tested frame sizes
iteration is said to pass at the current capacity. 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.
For each successful iteration, each destination test port will join 8. Interaction
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 Network forwarding devices are generally required to provide more
stated Maximum Group Capacity result. 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.
Reporting Format: 8.1. Forwarding Burdened Multicast Latency
The following configuration parameters MUST be reflected in the Objective:
test report:
o Frame size(s) To produce a set of multicast latency measurements from a single
o Number of tested egress interfaces on the DUT/SUT multicast ingress interface of a DUT/SUT through multiple egress
o IGMP version multicast interfaces of that same DUT/SUT as provided for by the
o Offered load metric "Multicast Latency" in RFC 2432 [Du98] while forwarding meshed
unicast traffic.
The following results MUST be reflected in the test report: Procedure:
o The total number of multicast group addresses that were The Multicast Latency metrics can be influenced by forcing the
successfully forwarded through the DUT/SUT DUT/SUT to perform extra processing of packets while multicast class
traffic is being forwarded for latency measurements.
The Multicast Group Capacity results for each test SHOULD be The Burdened Forwarding Multicast Latency test MUST follow the
reported in the form of a table, with a row for each of the tested described setup for the Multicast Latency test in Section 5.1. In
frame sizes per the recommendations in section 3.1.3. Each row or addition, another set of test ports MUST be used to burden the
iteration SHOULD specify the number of multicast groups joined per DUT/SUT (burdening ports). The burdening ports will be used to
destination interface, number of frames transmitted and number of transmit unicast class traffic to the DUT/SUT in a fully meshed
frames received for that iteration. traffic distribution as described in RFC 2285 [Ma98]. The DUT/SUT
MUST learn the appropriate unicast addresses and verified through
some externally observable method.
8. Interaction 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.
Network forwarding devices are generally required to provide more Reporting Format:
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.
8.1. Forwarding Burdened Multicast Latency Similar to Section 5.1, the following configuration parameters MUST
be reflected in the test report:
Objective: 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
To produce a set of multicast latency measurements from a single The following results MUST be reflected in the test report:
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 [Du96] while forwarding
meshed unicast traffic.
Procedure: 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.
The Multicast Latency metrics can be influenced by forcing the The time units of the presented latency MUST be uniform and with
DUT/SUT to perform extra processing of packets while multicast sufficient precision for the medium or media being tested.
class traffic is being forwarded for latency measurements.
The Burdened Forwarding Multicast Latency test MUST follow the The latency results for each test SHOULD be reported in the form of a
described setup for the Multicast Latency test in Section 5.1. In table, with a row for each of the tested frame sizes per the
addition, another set of test ports MUST be used to burden the recommended frame sizes in section 3.1.3, and SHOULD preserve the
DUT/SUT (burdening ports). The burdening ports will be used to relationship of latency to ingress/egress interface(s) to assist in
transmit unicast class traffic to the DUT/SUT in a fully meshed trending across multiple trials.
traffic distribution as described in RFC 2285 [Ma98]. The DUT/SUT
MUST learn the appropriate unicast addresses and verified through
some externally observable method.
Perform a baseline measurement of Multicast Latency as described in 8.2. Forwarding Burdened Group Join Delay
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.
Reporting Format: Objective:
Similar to Section 5.1, the following configuration parameters MUST To determine the time duration it takes a DUT/SUT to start forwarding
be reflected in the test report: multicast frames from the time a successful IGMP Group Membership
Report has been issued to the DUT/SUT while forwarding meshed unicast
traffic.
o Frame size(s) Procedure:
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
The following results MUST be reflected in the test report: 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.
o The set of all latencies related to the tested ingress and Perform a baseline measurement of Group Join Delay as described in
each tested egress DUT/SUT interface for both the baseline Section 6.1. After the baseline measurement is obtained, start
and burdened response. 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.
The time units of the presented latency MUST be uniform and with Reporting Format:
sufficient precision for the medium or media being tested.
The latency results for each test SHOULD be reported in the form of Similar to Section 6.1, the following configuration parameters MUST
a table, with a row for each of the tested frame sizes per the be reflected in the test report:
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.
8.2. Forwarding Burdened Group Join Delay 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
Objective: The following results MUST be reflected in the test report:
To determine the time duration it takes a DUT/SUT to start o The group join delay time in microseconds per egress
forwarding multicast frames from the time a successful IGMP Group interface(s) for both the baseline and burdened response.
Membership Report has been issued to the DUT/SUT while forwarding
meshed unicast traffic.
Procedure: 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.
The Forwarding Burdened Group Join Delay test MUST follow the 9. Security Considerations
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.
Perform a baseline measurement of Group Join Delay as described in As this document is solely for the purpose of providing metric
Section 6.1. After the baseline measurement is obtained, start methodology and describes neither a protocol nor a protocol's
transmitting the unicast class traffic at a user-specified offered implementation, there are no security considerations associated with
load on the set of burdening ports and rerun the Group Join Delay this document specifically. Results from these methodologies may
test. The offered load to the ingress port MUST be the same as was identify a performance capability or limit of a device or system in a
used in the baseline measurement. particular test context. However, such results might not be
representative of the tested entity in an operational network.
Reporting Format: 10. Acknowledgements
Similar to Section 6.1, the following configuration parameters MUST The Benchmarking Methodology Working Group of the IETF and
be reflected in the test report: particularly Kevin Dubray, Juniper Networks, are to be thanked for
the many suggestions they collectively made to help complete this
document.
o Frame size(s) 11. Contributions
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
The following results MUST be reflected in the test report: 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.
o The group join delay time in microseconds per egress 12. References
interface(s) for both the baseline and burdened response.
The Group Join Delay results for each test MAY be reported in the 12.1. Normative References
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.
9. Security Considerations [Br91] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991.
As this document is solely for the purpose of providing metric [Br96] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
methodology and describes neither a protocol nor a protocol's Network Interconnect Devices", RFC 2544, March 1999.
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 [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement
Levels, RFC 2119, March 1997.
The Benchmarking Methodology Working Group of the IETF and [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC
particularly Kevin Dubray, Juniper Networks, are to be thanked for 2432, October 1998.
the many suggestions they collectively made to help complete this
document.
11. Contributions [IANA1] IANA multicast address assignments,
http://www.iana.org/assignments/multicast-addresses
The authors would like to acknowledge the following individuals for [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
their help and participation of the compilation of this document: Devices", RFC 2285, February 1998.
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.
12. References [Me98] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998.
Normative References 12.2. Informative References
[Br91] Bradner, S., "Benchmarking Terminology for Network [Ca02] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Interconnection Devices", RFC 1242, July 1991. Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for [De89] Deering, S., "Host Extensions for IP Multicasting", STD 5,
Network Interconnect Devices", RFC 2544, March 1999. RFC 1112, August 1989.
[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement [Fe97] Fenner, W., "Internet Group Management Protocol, Version 2",
Levels, RFC 2119, March 1997 RFC 2236, November 1997.
[Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC [Hu95] Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
2432, October 1998.
[IANA1] IANA multicast address assignments, [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to
http://www.iana.org/assignments/multicast-addresses Interactive Corporate Networks", John Wiley & Sons Inc.,
1998.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching [Mt98] Maufer, T., "Deploying IP Multicast in the Enterprise",
Devices", RFC 2285, February 1998. Prentice-Hall, 1998.
Informative References 13. Authors' Addresses
[Ca02] Cain, B., et al., "Internet Group Management Protocol, Version Debra Stopp
3", RFC 3376, October 2002. Ixia
26601 W. Agoura Rd.
Calabasas, CA 91302
USA
[De89] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC Phone: + 1 818 871 1800
1112, August 1989. EMail: debby@ixiacom.com
[Fe97] Fenner, W., "Internet Group Management Protocol, Version 2", Brooks Hickman
RFC 2236, November 1997. Spirent Communications
26750 Agoura Rd.
Calabasas, CA 91302
USA
[Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. Phone: + 1 818 676 2412
EMail: brooks.hickman@spirentcom.com
[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to 14. Full Copyright Statement
Interactive Corporate Networks", John Wiley & Sons, Inc, 1998.
[Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." Copyright (C) The Internet Society (2004).
Prentice-Hall, 1998.
13. Author's Addresses 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.
Debra Stopp This document and the information contained herein are provided on an
Ixia "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
26601 W. Agoura Rd. REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
Calabasas, CA 91302 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
USA 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.
Phone: + 1 818 871 1800 Intellectual Property
EMail: debby@ixiacom.com
Brooks Hickman The IETF takes no position regarding the validity or scope of any
Spirent Communications Intellectual Property Rights or other rights that might be claimed to
26750 Agoura Rd. pertain to the implementation or use of the technology described in
Calabasas, CA 91302 this document or the extent to which any license under such rights
USA 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.
Phone: + 1 818 676 2412 Copies of IPR disclosures made to the IETF Secretariat and any
EMail: brooks.hickman@spirentcom.com 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.
14. Full Copyright Statement 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.
"Copyright (C) The Internet Society (2004). All Rights Reserved. Acknowledgement
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain Funding for the RFC Editor function is currently provided by the
it or assist in its implementation may be prepared, copied, Internet Society.
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into.
 End of changes. 330 change blocks. 
1064 lines changed or deleted 1069 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/