doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc3918.txt b/doc/rfc/rfc3918.txt
new file mode 100644
index 0000000..ac30af5
--- /dev/null
+++ b/doc/rfc/rfc3918.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                           D. Stopp
+Request for Comments: 3918                                          Ixia
+Category: Informational                                       B. Hickman
+                                                  Spirent Communications
+                                                            October 2004
+
+
+               Methodology for IP Multicast Benchmarking
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The purpose of this document is to describe methodology specific to
+   the benchmarking of multicast IP forwarding devices.  It builds upon
+   the tenets set forth in RFC 2544, RFC 2432 and other IETF
+   Benchmarking Methodology Working Group (BMWG) efforts.  This document
+   seeks to extend these efforts to the multicast paradigm.
+
+   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.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Key Words to Reflect Requirements. . . . . . . . . . . . . . .  3
+   3.  Test Set Up. . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       3.1.  Test Considerations. . . . . . . . . . . . . . . . . . .  4
+             3.1.1. IGMP Support. . . . . . . . . . . . . . . . . . .  5
+             3.1.2. Group Addresses . . . . . . . . . . . . . . . . .  5
+             3.1.3. Frame Sizes . . . . . . . . . . . . . . . . . . .  5
+             3.1.4. TTL . . . . . . . . . . . . . . . . . . . . . . .  6
+             3.1.5. Trial Duration. . . . . . . . . . . . . . . . . .  6
+   4.  Forwarding and Throughput. . . . . . . . . . . . . . . . . . .  6
+       4.1.  Mixed Class Throughput . . . . . . . . . . . . . . . . .  6
+       4.2.  Scaled Group Forwarding Matrix . . . . . . . . . . . . .  8
+       4.3.  Aggregated Multicast Throughput. . . . . . . . . . . . .  9
+
+
+
+Stopp & Hickman              Informational                      [Page 1]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+       4.4.  Encapsulation/Decapsulation (Tunneling) Throughput . . . 10
+             4.4.1. Encapsulation Throughput. . . . . . . . . . . . . 10
+             4.4.2. Decapsulation Throughput. . . . . . . . . . . . . 12
+             4.4.3. Re-encapsulation Throughput . . . . . . . . . . . 14
+   5.  Forwarding Latency . . . . . . . . . . . . . . . . . . . . . . 15
+       5.1.  Multicast Latency. . . . . . . . . . . . . . . . . . . . 16
+       5.2.  Min/Max Multicast Latency. . . . . . . . . . . . . . . . 18
+   6.  Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       6.1.  Group Join Delay . . . . . . . . . . . . . . . . . . . . 20
+       6.2.  Group Leave Delay. . . . . . . . . . . . . . . . . . . . 22
+   7.  Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+       7.1.  Multicast Group Capacity . . . . . . . . . . . . . . . . 24
+   8.  Interaction. . . . . . . . . . . . . . . . . . . . . . . . . . 25
+       8.1.  Forwarding Burdened Multicast Latency. . . . . . . . . . 25
+       8.2.  Forwarding Burdened Group Join Delay . . . . . . . . . . 27
+   9.  Security Considerations. . . . . . . . . . . . . . . . . . . . 28
+   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
+   11. Contributions. . . . . . . . . . . . . . . . . . . . . . . . . 28
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
+       12.1. Normative References . . . . . . . . . . . . . . . . . . 28
+       12.2. Informative References . . . . . . . . . . . . . . . . . 29
+   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
+   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 31
+
+1.  Introduction
+
+   This document defines tests for measuring and reporting the
+   throughput, forwarding, latency and Internet Group Management
+   Protocol (IGMP) group membership characteristics of devices that
+   support IP multicast protocols.  The results of these tests will
+   provide the user with meaningful data on multicast performance.
+
+   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.
+
+   This methodology will focus on one source to many destinations,
+   although many of the tests described may be extended to use multiple
+   source to multiple destination topologies.
+
+   Subsequent documents may address IPv6 multicast and related multicast
+   routing protocol performance.  Additional insight on IP and multicast
+   networking can be found in [Hu95], [Ka98] and [Mt98].
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                      [Page 2]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+2.  Key Words to Reflect Requirements
+
+   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.
+
+3.  Test set up
+
+   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.
+
+   Figure 1 shows a typical setup for an IP multicast test, with one
+   source to multiple destinations.
+
+                     +------------+         +--------------+
+                     |            |         |  destination |
+   +--------+        |     Egress(-)------->|    test      |
+   | source |        |            |         |   port(E1)   |
+   |  test  |------>(|)Ingress    |         +--------------+
+   |  port  |        |            |         +--------------+
+   +--------+        |     Egress(-)------->|  destination |
+                     |            |         |    test      |
+                     |            |         |   port(E2)   |
+                     |    DUT     |         +--------------+
+                     |            |               . . .
+                     |            |         +--------------+
+                     |            |         |  destination |
+                     |     Egress(-)------->|    test      |
+                     |            |         |   port(En)   |
+                     +------------+         +--------------+
+
+                          Figure 1
+
+   If the multicast metrics are to be taken across multiple devices
+   forming a System Under Test (SUT), then test frames are offered to a
+   single ingress interface on a device of the SUT, subsequently
+   forwarded across the SUT topology, and finally forwarded to the test
+   apparatus' frame-receiving components by the test egress interface(s)
+   of devices in the SUT.  Figure 2 offers an example SUT test topology.
+   If a SUT is tested, the test topology and all relevant configuration
+   details MUST be disclosed with the corresponding test results.
+
+
+
+
+Stopp & Hickman              Informational                      [Page 3]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+               *-----------------------------------------*
+               |                                         |
+   +--------+  |                     +----------------+  |  +--------+
+   |        |  |   +------------+    |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
+
+   Generally, the destination test ports first join the desired number
+   of multicast groups by sending IGMP Group Report messages to the
+   DUT/SUT.  To verify that all destination test ports successfully
+   joined the appropriate groups, the source test port MUST transmit IP
+   multicast frames destined for these groups.  After test completion,
+   the destination test ports MAY send IGMP Leave Group messages to
+   clear the IGMP table of the DUT/SUT.
+
+   In addition, test equipment MUST validate the correct and proper
+   forwarding actions of the devices they test in order to ensure the
+   receipt of the frames that are involved in the test.
+
+3.1.  Test Considerations
+
+   The methodology assumes a uniform medium topology.  Issues regarding
+   mixed transmission media, such as speed mismatch, headers
+   differences, etc., are not specifically addressed.  Flow control, QoS
+   and other non-essential traffic or traffic-affecting mechanisms
+   affecting the variable under test MUST be disabled.  Modifications to
+   the collection procedures might need to be made to accommodate the
+   transmission media actually tested.  These accommodations MUST be
+   presented with the test results.
+
+   An actual flow of test traffic MAY be required to prime related
+   mechanisms, (e.g., process RPF events, build device caches, etc.) to
+   optimally forward subsequent traffic.  Therefore, prior to running
+   any tests that require forwarding of multicast or unicast packets,
+   the test apparatus MUST generate test traffic utilizing the same
+   addressing characteristics to the DUT/SUT that will subsequently be
+
+
+
+
+
+Stopp & Hickman              Informational                      [Page 4]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   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
+   characterizations regarding the forwarding of multicast packets by a
+   device or simple system of devices.  These characterizations may be
+   useful in illustrating the impact of device architectural features
+   (e.g., message passing versus shared memory; handling multicast
+   traffic as an exception by the general purpose processor versus the
+   by a primary data path, etc.) in the forwarding of multicast traffic.
+
+   It has been noted that the formation of the multicast distribution
+   tree may be a significant component of multicast performance. While
+   this component may be present in some of the measurements or
+   scenarios presented in this memo, this memo does not seek to
+   explicitly benchmark the formation of the multicast distribution
+   tree.  The benchmarking of the multicast distribution tree formation
+   is left as future, more targeted work specific to a given tree
+   formation vehicle.
+
+3.1.1.  IGMP Support
+
+   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.
+
+   Each of the ingress and egress interfaces SHOULD be able to respond
+   to IGMP queries during the test.
+
+   Each of the ingress and egress interfaces SHOULD also send LEAVE
+   (running IGMP version 2 or later) [Ca02] [Fe97] after each test.
+
+3.1.2.  Group Addresses
+
+   There is no restriction to the use of multicast addresses [De89] to
+   compose the test traffic other than those assignments imposed by
+   IANA.  The IANA assignments for multicast addresses [IANA1] MUST be
+   regarded for operational consistency.  Address selection does not
+   need to be restricted to Administratively Scoped IP Multicast
+   addresses [Me98].
+
+3.1.3.  Frame Sizes
+
+   Each test SHOULD be run with different multicast frame sizes.  For
+   Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280,
+   and 1518 byte frames.
+
+
+
+
+Stopp & Hickman              Informational                      [Page 5]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   Other link layer technologies MAY be used.  The minimum and maximum
+   frame lengths of the link layer technology in use SHOULD be tested.
+
+   When testing with different frame sizes, the DUT/SUT configuration
+   MUST remain the same.
+
+3.1.4.  TTL
+
+   The data plane test traffic should have a TTL value large enough to
+   traverse the DUT/SUT.
+
+   The TTL in IGMP control plane messages MUST be in compliance with the
+   version of IGMP in use.
+
+3.1.5.  Trial Duration
+
+   The duration of the test portion of each trial SHOULD be at least 30
+   seconds.  This parameter MUST be included as part of the results
+   reporting for each methodology.
+
+4.  Forwarding and Throughput
+
+   This section contains the description of the tests that are related
+   to the characterization of the frame forwarding of a DUT/SUT in a
+   multicast environment.  Some metrics extend the concept of throughput
+   presented in RFC 1242.  Forwarding Rate is cited in RFC 2285 [Ma98].
+
+4.1.  Mixed Class Throughput
+
+   Objective:
+
+   To determine the throughput of a DUT/SUT when both unicast class
+   frames and multicast class frames are offered simultaneously to a
+   fixed number of interfaces as defined in RFC 2432.
+
+   Procedure:
+
+   Multicast and unicast traffic are mixed together in the same
+   aggregated traffic stream in order to simulate a heterogeneous
+   networking environment.
+
+   The following events MUST occur before offering test traffic:
+
+      o  All destination test ports configured to receive multicast
+         traffic MUST join all configured multicast groups;
+      o  The DUT/SUT MUST learn the appropriate unicast and
+         multicast addresses; and
+
+
+
+
+Stopp & Hickman              Informational                      [Page 6]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+      o  Group membership and unicast address learning MUST be
+         verified through some externally observable method.
+
+   The intended load [Ma98] SHOULD be configured as alternating
+   multicast class frames and unicast class frames to a single ingress
+   interface.  The unicast class frames MUST be configured to transmit
+   in an unweighted round-robin fashion to all of the destination ports.
+
+   For example, with six multicast groups and 3 destination ports with
+   one unicast addresses per port, the source test port will offer
+   frames in the following order:
+
+      m1  u1  m2  u2  m3  u3  m4  u1  m5  u2  m6  u3  m1 ...
+
+      Where:
+
+      m<Number> = Multicast Frame<Group>
+      u<Number> = Unicast Frame<Target Port>
+
+   Mixed class throughput measurement is defined in RFC 2432 [Du98].  A
+   search algorithm MUST be utilized to determine the Mixed Class
+   Throughput.  The ratio of unicast to multicast frames MUST remain the
+   same when varying the intended load.
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Total number of multicast groups
+      o  Traffic distribution for unicast and multicast traffic
+         classes
+      o  The ratio of multicast to unicast class traffic
+
+   The following results MUST be reflected in the test report:
+
+      o  Mixed Class Throughput as defined in RFC 2432 [Du98],
+         including: Throughput per unicast and multicast traffic
+         classes.
+
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                      [Page 7]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   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.
+
+4.2.  Scaled Group Forwarding Matrix
+
+   Objective:
+
+   To determine Forwarding Rate as a function of tested multicast groups
+   for a fixed number of tested DUT/SUT ports.
+
+   Procedure:
+
+   This is an iterative procedure.  The destination test port(s) MUST
+   join an initial number of multicast groups on the first iteration.
+   All destination test ports configured to receive multicast traffic
+   MUST join all configured multicast groups.  The recommended number of
+   groups to join on the first iteration is 10 groups.  Multicast
+   traffic is subsequently transmitted to all groups joined on this
+   iteration and the forwarding rate is measured.
+
+   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.
+
+   The total number of multicast groups joined MUST not exceed the
+   multicast group capacity of the DUT/SUT.  The Group Capacity (Section
+   7.1) results MUST be known prior to running this test.
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+
+   The following results MUST be reflected in the test report:
+
+      o  The total number of multicast groups joined for that
+         iteration
+
+
+
+Stopp & Hickman              Informational                      [Page 8]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+      o  Forwarding rate determined for that iteration
+
+   The Scaled Group Forwarding results for each test SHOULD be reported
+   in the form of a table with a row representing each iteration of the
+   test.  Each row or iteration SHOULD specify the total number of
+   groups joined for that iteration, offered load, total number of
+   frames transmitted, total number of frames received and the aggregate
+   forwarding rate determined for that iteration.
+
+4.3.  Aggregated Multicast Throughput
+
+   Objective:
+
+   To determine the maximum rate at which none of the offered frames to
+   be forwarded through N destination interfaces of the same multicast
+   groups are dropped.
+
+   Procedure:
+
+   Offer multicast traffic at an initial maximum offered load to a fixed
+   set of interfaces with a fixed number of groups at a fixed frame
+   length for a fixed duration of time.  All destination test ports MUST
+   join all specified multicast groups.
+
+   If any frame loss is detected, the offered load is decreased and the
+   sender will transmit again.  An iterative search algorithm MUST be
+   utilized to determine the maximum offered frame rate with a zero
+   frame loss.
+
+   Each iteration will involve varying the offered load of the multicast
+   traffic, while keeping the set of interfaces, number of multicast
+   groups, frame length and test duration fixed, until the maximum rate
+   at which none of the offered frames are dropped is determined.
+
+   Parameters to be measured MUST include the maximum offered load at
+   which no frame loss occurred.  Other offered loads MAY be measured
+   for diagnostic purposes.
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Total number of multicast groups
+
+
+
+Stopp & Hickman              Informational                      [Page 9]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+
+   The following results MUST be reflected in the test report:
+
+      o  Aggregated Multicast Throughput as defined in RFC 2432
+         [Du98]
+
+   The Aggregated Multicast Throughput results SHOULD be reported in the
+   format of a table with a row for each of the tested frame sizes per
+   the recommendations in section 3.1.3.  Each row or iteration SHOULD
+   specify offered load, total number of offered frames and the measured
+   Aggregated Multicast Throughput.
+
+4.4.  Encapsulation/Decapsulation (Tunneling) Throughput
+
+   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.
+
+   For this specific testing scenario, encapsulation or tunneling refers
+   to a packet that contains an unsupported protocol feature in a format
+   that is supported by the DUT/SUT.
+
+4.4.1.  Encapsulation Throughput
+
+   Objective:
+
+   To determine the maximum rate at which frames offered to one ingress
+   interface of a DUT/SUT are encapsulated and correctly forwarded on
+   one or more egress interfaces of the DUT/SUT without loss.
+
+   Procedure:
+
+     Source              DUT/SUT                Destination
+    Test Port                                   Test Port(s)
+   +---------+        +-----------+             +---------+
+   |         |        |           |             |         |
+   |         |        |     Egress|--(Tunnel)-->|         |
+   |         |        |           |             |         |
+   |         |------->|Ingress    |             |         |
+   |         |        |           |             |         |
+   |         |        |     Egress|--(Tunnel)-->|         |
+   |         |        |           |             |         |
+   +---------+        +-----------+             +---------+
+
+                         Figure 3
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 10]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   Figure 3 shows the setup for testing the encapsulation throughput of
+   the DUT/SUT.  One or more tunnels are created between each egress
+   interface of the DUT/SUT and a destination test port.  Non-
+   Encapsulated multicast traffic will then be offered by the source
+   test port, encapsulated by the DUT/SUT and forwarded to the
+   destination test port(s).
+
+   The DUT/SUT SHOULD be configured such that the traffic across each
+   egress interface will consist of either:
+
+      a) A single tunnel encapsulating one or more multicast address
+         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
+   DUT/SUT is configured in a multiple tunnel configuration.  In
+   addition, it is RECOMMENDED to test with the same number of tunnels
+   on each egress interface.  All destination test ports MUST join all
+   multicast group addresses offered by the source test port.  Each
+   egress interface MUST be configured with the same MTU.
+
+   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.
+
+   A search algorithm MUST be utilized to determine the encapsulation
+   throughput as defined in [Du98].
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Total number of multicast groups
+      o  MTU size of DUT/SUT interfaces
+      o  Originating un-encapsulated frame size
+      o  Number of tunnels per egress interface
+      o  Number of multicast groups per tunnel
+      o  Encapsulation algorithm or format used to tunnel the
+         packets
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 11]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   The following results MUST be reflected in the test report:
+
+      o  Measured Encapsulated Throughput as defined in RFC 2432
+         [Du98]
+      o  Encapsulated frame size
+
+   The Encapsulated Throughput results SHOULD be reported in the form of
+   a table and specific to this test there SHOULD be rows for each
+   originating un-encapsulated frame size.  Each row or iteration SHOULD
+   specify the offered load, encapsulation method, encapsulated frame
+   size, total number of offered frames, and the encapsulation
+   throughput.
+
+4.4.2.  Decapsulation Throughput
+
+   Objective:
+
+   To determine the maximum rate at which frames offered to one ingress
+   interface of a DUT/SUT are decapsulated and correctly forwarded by
+   the DUT/SUT on one or more egress interfaces without loss.
+
+   Procedure:
+
+     Source                  DUT/SUT            Destination
+    Test Port                                   Test Port(s)
+   +---------+             +-----------+        +---------+
+   |         |             |           |        |         |
+   |         |             |     Egress|------->|         |
+   |         |             |           |        |         |
+   |         |--(Tunnel)-->|Ingress    |        |         |
+   |         |             |           |        |         |
+   |         |             |     Egress|------->|         |
+   |         |             |           |        |         |
+   +---------+             +-----------+        +---------+
+
+                             Figure 4
+
+   Figure 4 shows the setup for testing the decapsulation throughput of
+   the DUT/SUT.  One or more tunnels are created between the source test
+   port and the DUT/SUT.  Encapsulated multicast traffic will then be
+   offered by the source test port, decapsulated by the DUT/SUT and
+   forwarded to the destination test port(s).
+
+
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 12]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   The DUT/SUT SHOULD be configured such that the traffic across the
+   ingress interface will consist of either:
+
+      a) A single tunnel encapsulating one or more multicast address
+         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
+   DUT/SUT is configured in a multiple tunnel configuration.  All
+   destination test ports MUST join all multicast group addresses
+   offered by the source test port.  Each egress interface MUST be
+   configured with the same MTU.
+
+   A search algorithm MUST be utilized to determine the decapsulation
+   throughput as defined in [Du98].
+
+   When making performance comparisons between the encapsulation and
+   decapsulation process of the DUT/SUT, the offered frame sizes SHOULD
+   reflect the encapsulated frame sizes reported in the encapsulation
+   test (See section 4.4.1) in place of those noted in section 3.1.3.
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Total number of multicast groups
+      o  Originating encapsulation algorithm or format used to
+         tunnel the packets
+      o  Originating encapsulated frame size
+      o  Number of tunnels
+      o  Number of multicast groups per tunnel
+
+   The following results MUST be reflected in the test report:
+
+      o  Measured Decapsulated Throughput as defined in RFC 2432
+         [Du98]
+      o  Decapsulated frame size
+
+   The Decapsulated Throughput results SHOULD be reported in the format
+   of a table and specific to this test there SHOULD be rows for each
+   originating encapsulated frame size.  Each row or iteration SHOULD
+   specify the offered load, decapsulated frame size, total number of
+   offered frames and the decapsulation throughput.
+
+
+
+Stopp & Hickman              Informational                     [Page 13]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+4.4.3.  Re-encapsulation Throughput
+
+   Objective:
+
+   To determine the maximum rate at which frames of one encapsulated
+   format offered to one ingress interface of a DUT/SUT are converted to
+   another encapsulated format and correctly forwarded by the DUT/SUT on
+   one or more egress interfaces without loss.
+
+   Procedure:
+
+     Source                DUT/SUT             Destination
+    Test Port                                  Test Port(s)
+   +---------+           +---------+           +---------+
+   |         |           |         |           |         |
+   |         |           |   Egress|-(Tunnel)->|         |
+   |         |           |         |           |         |
+   |         |-(Tunnel)->|Ingress  |           |         |
+   |         |           |         |           |         |
+   |         |           |   Egress|-(Tunnel)->|         |
+   |         |           |         |           |         |
+   +---------+           +---------+           +---------+
+
+                          Figure 5
+
+   Figure 5 shows the setup for testing the Re-encapsulation throughput
+   of the DUT/SUT.  The source test port will offer encapsulated traffic
+   of one type to the DUT/SUT, which has been configured to re-
+   encapsulate the offered frames using a different encapsulation
+   format.  The DUT/SUT will then forward the re-encapsulated frames to
+   the destination test port(s).
+
+   The DUT/SUT SHOULD be configured such that the traffic across the
+   ingress and each egress interface will consist of either:
+
+      a) A single tunnel encapsulating one or more multicast address
+         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
+   DUT/SUT is configured in a multiple tunnel configuration.  In
+   addition, the DUT/SUT SHOULD be configured such that the number of
+   tunnels on the ingress and each egress interface are the same.  All
+   destination test ports MUST join all multicast group addresses
+   offered by the source test port.  Each egress interface MUST be
+   configured with the same MTU.
+
+
+
+
+Stopp & Hickman              Informational                     [Page 14]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   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.
+
+   A search algorithm MUST be utilized to determine the re-encapsulation
+   throughput as defined in [Du98].
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Total number of multicast groups
+      o  MTU size of DUT/SUT interfaces
+      o  Originating encapsulation algorithm or format used to
+         tunnel the packets
+      o  Re-encapsulation algorithm or format used to tunnel the
+         packets
+      o  Originating encapsulated frame size
+      o  Number of tunnels per interface
+      o  Number of multicast groups per tunnel
+
+   The following results MUST be reflected in the test report:
+
+      o  Measured Re-encapsulated Throughput as defined in RFC 2432
+         [Du98]
+      o  Re-encapsulated frame size
+
+   The Re-encapsulated Throughput results SHOULD be reported in the
+   format of a table and specific to this test there SHOULD be rows for
+   each originating encapsulated frame size.  Each row or iteration
+   SHOULD specify the offered load, Re-encapsulated frame size, total
+   number of offered frames, and the Re-encapsulated Throughput.
+
+5.  Forwarding Latency
+
+   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.
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 15]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   The offered load accompanying the latency-measured packet can affect
+   the DUT/SUT packet buffering, which may subsequently impact measured
+   packet latency.  This SHOULD be a consideration when selecting the
+   intended load for the described methodologies below.
+
+   RFC 1242 and RFC 2544 draw a distinction between device types: "store
+   and forward" and "bit-forwarding."  Each type impacts how latency is
+   collected and subsequently presented.  See the related RFCs for more
+   information.
+
+5.1.  Multicast Latency
+
+   Objective:
+
+   To produce a set of multicast latency measurements from a single,
+   multicast ingress interface of a DUT/SUT through multiple, egress
+   multicast interfaces of that same DUT/SUT as provided for by the
+   metric "Multicast Latency" in RFC 2432 [Du98].
+
+   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.
+
+   Procedure:
+
+   If the test trial is to characterize latency across a single Device
+   Under Test (DUT), an example test topology might take the form of
+   Figure 1 in section 3.  That is, a single DUT with one ingress
+   interface receiving the multicast test traffic from frame-
+   transmitting component of the test apparatus and n egress interfaces
+   on the same DUT forwarding the multicast test traffic back to the
+   frame-receiving component of the test apparatus.  Note that n
+   reflects the number of TESTED egress interfaces on the DUT actually
+   expected to forward the test traffic (as opposed to configured but
+   untested, non-forwarding interfaces, for example).
+
+   If the multicast latencies are to be taken across multiple devices
+   forming a System Under Test (SUT), an example test topology might
+   take the form of Figure 2 in section 3.
+
+   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.
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 16]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   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.
+
+   The test apparatus will monitor frames from the DUT's tested egress
+   interface(s) for the expected tagged frame(s) and MUST record the
+   time of the successful detection of a tagged frame from a tested
+   egress interface with a timestamp, Timestamp B.  A set of Timestamp B
+   values MUST be collected for all tested egress interfaces of the
+   DUT/SUT.  See RFC 1242 [Br91] for additional discussion regarding
+   store and forward devices and bit forwarding devices.
+
+   A trial MUST be considered INVALID should any of the following
+   conditions occur in the collection of the trial data:
+
+      o  Unexpected differences between Intended Load and Offered
+         Load or unexpected differences between Offered Load and the
+         resulting Forwarding Rate(s) on the DUT/SUT egress ports.
+      o  Forwarded test frames improperly formed or frame header
+         fields improperly manipulated.
+      o  Failure to forward required tagged frame(s) on all expected
+         egress interfaces.
+      o  Reception of tagged frames by the test apparatus more than
+         5 seconds after the cessation of test traffic by the source
+         test port.
+
+   The set of latency measurements, M, composed from each latency
+   measurement taken from every ingress/tested egress interface pairing
+   MUST be determined from a valid test trial:
+
+      M = { (Timestamp B(E0) - Timestamp A),
+            (Timestamp B(E1) - Timestamp A), ...
+            (Timestamp B(En) - Timestamp A) }
+
+   where (E0 ... En) represents the range of all tested egress
+   interfaces and Timestamp B represents a tagged frame detection event
+   for a given DUT/SUT tested egress interface.
+
+   A more continuous profile MAY be built from a series of individual
+   measurements.
+
+
+
+Stopp & Hickman              Informational                     [Page 17]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Offered load
+      o  Total number of multicast groups
+
+   The following results MUST be reflected in the test report:
+
+      o  The set of all latencies with respective time units related
+         to the tested ingress and each tested egress DUT/SUT
+         interface.
+
+   The time units of the presented latency MUST be uniform and with
+   sufficient precision for the medium or media being tested.
+
+   The results MAY be offered in a tabular format and should preserve
+   the relationship of latency to ingress/egress interface for each
+   multicast group to assist in trending across multiple trials.
+
+5.2.  Min/Max Multicast Latency
+
+   Objective:
+
+   To determine the difference between the maximum latency measurement
+   and the minimum latency measurement from a collected set of latencies
+   produced by the Multicast Latency benchmark.
+
+   Procedure:
+
+   Collect a set of multicast latency measurements over a single test
+   duration, as prescribed in section 5.1.  This will produce a set of
+   multicast latencies, M, where M is composed of individual forwarding
+   latencies between DUT frame ingress and DUT frame egress port pairs.
+   E.g.:
+
+      M = {L(I,E1),L(I,E2), ..., L(I,En)}
+
+   where L is the latency between a tested ingress interface, I, of the
+   DUT, and Ex a specific, tested multicast egress interface of the DUT.
+   E1 through En are unique egress interfaces on the DUT.
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 18]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   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.
+
+   Identify MIN(M), when MIN is a function that yields the smallest
+   latency value from set M.
+
+   The Max/Min value is determined from the following formula:
+
+      Result = MAX(M) - MIN(M)
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Offered load
+      o  Total number of multicast groups
+
+   The following results MUST be reflected in the test report:
+
+      o  The Max/Min value
+
+   The following results SHOULD be reflected in the test report:
+
+      o  The set of all latencies with respective time units related
+         to the tested ingress and each tested egress DUT/SUT
+         interface.
+
+   The time units of the presented latency MUST be uniform and with
+   sufficient precision for the medium or media being tested.
+
+   The results MAY be offered in a tabular format and should preserve
+   the relationship of latency to ingress/egress interface for each
+   multicast group.
+
+6.  Overhead
+
+   This section presents methodology relating to the characterization of
+   the overhead delays associated with explicit operations found in
+   multicast environments.
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 19]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+6.1.  Group Join Delay
+
+   Objective:
+
+   To determine the time duration it takes a DUT/SUT to start forwarding
+   multicast frames from the time a successful IGMP group membership
+   report has been issued to the DUT/SUT.
+
+   Procedure:
+
+   The Multicast Group Join Delay measurement may be influenced by the
+   state of the Multicast Forwarding Database <MFDB> of the DUT/SUT. The
+   states of the MFDB may be described as follows:
+
+      o  State 0, where the MFDB does not contain the specified
+         multicast group address.  In this state, the delay measurement
+         includes the time the DUT/SUT requires to add the address to
+         the MFDB and begin forwarding.   Delay measured from State 0
+         provides information about how the DUT/SUT is able to add new
+         addresses into MFDB.
+
+      o  State 1, where the MFDB does contain the specified multicast
+         group address.  In this state, the delay measurement includes
+         the time the DUT/SUT requires to update the MFDB with the
+         newly joined node<s> and begin forwarding to the new node<s>
+         plus packet replication time.  Delay measured from State 1
+         provides information about how well the DUT/SUT is able to
+         update the MFDB for new nodes while transmitting packets to
+         other nodes for the same IP multicast address.  Examples
+         include adding a new user to an event that is being promoted
+         via multicast packets.
+
+   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.
+
+   Users MAY elect to use either method to determine the Multicast Group
+   Join Delay; however the collection method MUST be specified as part
+   of the reporting format.
+
+   In order to minimize the variation in delay calculations as well as
+   minimize burden on the DUT/SUT, the test SHOULD be performed with one
+   multicast group.  In addition, all destination test ports MUST join
+   the specified multicast group offered to the ingress interface of the
+   DUT/SUT.
+
+
+
+
+Stopp & Hickman              Informational                     [Page 20]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   Method A:
+
+   Method A assumes that the Multicast Forwarding Database <MFDB> of the
+   DUT/SUT does not contain or has not learned the specified multicast
+   group address; specifically, the MFDB MUST be in State 0. In this
+   scenario, the metric represents the time the DUT/SUT takes to add the
+   multicast address to the MFDB and begin forwarding the multicast
+   packet.  Only one ingress and one egress MUST be used to determine
+   this metric.
+
+   Prior to sending any IGMP Group Membership Reports used to calculate
+   the Multicast Group Join Delay, it MUST be verified through
+   externally observable means that the destination test port is not
+   currently a member of the specified multicast group.  In addition, it
+   MUST be verified through externally observable means that the MFDB of
+   the DUT/SUT does not contain the specified multicast address.
+
+   Method B:
+
+   Method B assumes that the MFDB of the DUT/SUT does contain the
+   specified multicast group address; specifically, the MFDB MUST be in
+   State 1.  In this scenario, the metric represents the time the
+   DUT/SUT takes to update the MFDB with the additional nodes and their
+   corresponding interfaces and to begin forwarding the multicast
+   packet.  One or more egress ports MAY be used to determine this
+   metric.
+
+   Prior to sending any IGMP Group Membership Reports used to calculate
+   the Group Join Delay, it MUST be verified through externally
+   observable means that the MFDB contains the specified multicast group
+   address.  A single un-instrumented test port MUST be used to join the
+   specified multicast group address prior to sending any test traffic.
+   This port will be used only for insuring that the MFDB has been
+   populated with the specified multicast group address and can
+   successfully forward traffic to the un-instrumented port.
+
+   Join Delay Calculation
+
+   Once verification is complete, multicast traffic for the specified
+   multicast group address MUST be offered to the ingress interface
+   prior to the DUT/SUT receiving any IGMP Group Membership Report
+   messages.  It is RECOMMENDED to offer traffic at the measured
+   aggregated multicast throughput rate (Section 4.3).
+
+   After the multicast traffic has been started, the destination test
+   port (See Figure 1) MUST send one IGMP Group Membership Report for
+   the specified multicast group.
+
+
+
+
+Stopp & Hickman              Informational                     [Page 21]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   The join delay is the difference in time from when the IGMP Group
+   Membership message is sent (timestamp A) and the first frame of the
+   multicast group is forwarded to a receiving egress interface
+   (timestamp B).
+
+      Group Join delay time = timestamp B - timestamp A
+
+   Timestamp A MUST be the time the last bit of the IGMP group
+   membership report is sent from the destination test port; timestamp B
+   MUST be the time the first bit of the first valid multicast frame is
+   forwarded on the egress interface of the DUT/SUT.
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  IGMP version
+      o  Total number of multicast groups
+      o  Offered load to ingress interface
+      o  Method used to measure the join delay metric
+
+   The following results MUST be reflected in the test report:
+
+      o  The group join delay time in microseconds per egress
+         interface(s)
+
+   The Group Join Delay results for each test MAY be reported in the
+   form of a table, with a row for each of the tested frame sizes per
+   the recommendations in section 3.1.3.  Each row or iteration MAY
+   specify the group join delay time per egress interface for that
+   iteration.
+
+6.2.  Group Leave Delay
+
+   Objective:
+
+   To determine the time duration it takes a DUT/SUT to cease forwarding
+   multicast frames after a corresponding IGMP Leave Group message has
+   been successfully offered to the DUT/SUT.
+
+
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 22]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   Procedure:
+
+   In order to minimize the variation in delay calculations as well as
+   minimize burden on the DUT/SUT, the test SHOULD be performed with one
+   multicast group.  In addition, all destination test ports MUST join
+   the specified multicast group offered to the ingress interface of the
+   DUT/SUT.
+
+   Prior to sending any IGMP Leave Group messages used to calculate the
+   group leave delay, it MUST be verified through externally observable
+   means that the destination test ports are currently members of the
+   specified multicast group.  If any of the egress interfaces do not
+   forward validation multicast frames then the test is invalid.
+
+   Once verification is complete, multicast traffic for the specified
+   multicast group address MUST be offered to the ingress interface
+   prior to receipt or processing of any IGMP Leave Group messages. It
+   is RECOMMENDED to offer traffic at the measured aggregated multicast
+   throughput rate (Section 4.3).
+
+   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.
+
+   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).
+
+           Group Leave delay time = timestamp B - timestamp A
+
+   Timestamp A MUST be the time the last bit of the IGMP Leave Group
+   message is sent from the destination test port; timestamp B MUST be
+   the time the last bit of the last valid multicast frame is forwarded
+   on the egress interface of the DUT/SUT.
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  IGMP version
+      o  Total number of multicast groups
+      o  Offered load to ingress interface
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 23]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   The following results MUST be reflected in the test report:
+
+      o  The group leave delay time in microseconds per egress
+         interface(s)
+
+   The Group Leave Delay results for each test MAY be reported in the
+   form of a table, with a row for each of the tested frame sizes per
+   the recommendations in section 3.1.3.  Each row or iteration MAY
+   specify the group leave delay time per egress interface for that
+   iteration.
+
+7.  Capacity
+
+   This section offers a procedure relating to the identification of
+   multicast group limits of a DUT/SUT.
+
+7.1.  Multicast Group Capacity
+
+   Objective:
+
+   To determine the maximum number of multicast groups a DUT/SUT can
+   support while maintaining the ability to forward multicast frames to
+   all multicast groups registered to that DUT/SUT.
+
+   Procedure:
+
+   One or more destination test ports of DUT/SUT will join an initial
+   number of multicast groups.
+
+   After a minimum delay as measured by section 6.1, the source test
+   ports MUST transmit to each group at a specified offered load.
+
+   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.
+
+   For each successful iteration, each destination test port will join
+   an additional user-defined number of multicast groups and the test
+   repeats.  The test stops iterating when one or more of the egress
+   interfaces fails to forward traffic on one or more of the configured
+   multicast groups.
+
+   Once the iteration fails, the last successful iteration is the stated
+   Maximum Group Capacity result.
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 24]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   Reporting Format:
+
+   The following configuration parameters MUST be reflected in the test
+   report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  IGMP version
+      o  Offered load
+
+   The following results MUST be reflected in the test report:
+
+      o  The total number of multicast group addresses that were
+         successfully forwarded through the DUT/SUT
+
+   The Multicast Group Capacity results for each test SHOULD be reported
+   in the form of a table, with a row for each of the tested frame sizes
+   per the recommendations in section 3.1.3.  Each row or iteration
+   SHOULD specify the number of multicast groups joined per destination
+   interface, number of frames transmitted and number of frames received
+   for that iteration.
+
+8.  Interaction
+
+   Network forwarding devices are generally required to provide more
+   functionality than just the forwarding of traffic.  Moreover,
+   network-forwarding devices may be asked to provide those functions in
+   a variety of environments.  This section offers procedures to assist
+   in the characterization of DUT/SUT behavior in consideration of
+   potentially interacting factors.
+
+8.1.  Forwarding Burdened Multicast Latency
+
+   Objective:
+
+   To produce a set of multicast latency measurements from a single
+   multicast ingress interface of a DUT/SUT through multiple egress
+   multicast interfaces of that same DUT/SUT as provided for by the
+   metric "Multicast Latency" in RFC 2432 [Du98] while forwarding meshed
+   unicast traffic.
+
+   Procedure:
+
+   The Multicast Latency metrics can be influenced by forcing the
+   DUT/SUT to perform extra processing of packets while multicast class
+   traffic is being forwarded for latency measurements.
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 25]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   The Burdened Forwarding Multicast Latency test MUST follow the
+   described setup for the Multicast Latency test in Section 5.1.  In
+   addition, another set of test ports MUST be used to burden the
+   DUT/SUT (burdening ports).  The burdening ports will be used to
+   transmit unicast class traffic to the DUT/SUT in a fully meshed
+   traffic distribution as described in RFC 2285 [Ma98].  The DUT/SUT
+   MUST learn the appropriate unicast addresses and verified through
+   some externally observable method.
+
+   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.
+
+   Reporting Format:
+
+   Similar to Section 5.1, the following configuration parameters MUST
+   be reflected in the test report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  Test duration
+      o  IGMP version
+      o  Offered load 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:
+
+      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 time units of the presented latency MUST be uniform and with
+   sufficient precision for the medium or media being tested.
+
+   The latency results for each test SHOULD be reported in the form of a
+   table, with a row for each of the tested frame sizes per the
+   recommended frame sizes in section 3.1.3, and SHOULD preserve the
+   relationship of latency to ingress/egress interface(s) to assist in
+   trending across multiple trials.
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 26]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+8.2.  Forwarding Burdened Group Join Delay
+
+   Objective:
+
+   To determine the time duration it takes a DUT/SUT to start forwarding
+   multicast frames from the time a successful IGMP Group Membership
+   Report has been issued to the DUT/SUT while forwarding meshed unicast
+   traffic.
+
+   Procedure:
+
+   The Forwarding Burdened Group Join Delay test MUST follow the
+   described setup for the Group Join Delay test in Section 6.1.  In
+   addition, another set of test ports MUST be used to burden the
+   DUT/SUT (burdening ports).  The burdening ports will be used to
+   transmit unicast class traffic to the DUT/SUT in a fully meshed
+   traffic pattern as described in RFC 2285 [Ma98].  The DUT/SUT MUST
+   learn the appropriate unicast addresses and verified through some
+   externally observable method.
+
+   Perform a baseline measurement of Group Join Delay as described in
+   Section 6.1.  After the baseline measurement is obtained, start
+   transmitting the unicast class traffic at a user-specified offered
+   load on the set of burdening ports and rerun the Group Join Delay
+   test.  The offered load to the ingress port MUST be the same as was
+   used in the baseline measurement.
+
+   Reporting Format:
+
+   Similar to Section 6.1, the following configuration parameters MUST
+   be reflected in the test report:
+
+      o  Frame size(s)
+      o  Number of tested egress interfaces on the DUT/SUT
+      o  IGMP version
+      o  Offered load 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:
+
+      o  The group join delay time in microseconds per egress
+         interface(s) for both the baseline and burdened response.
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 27]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   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.
+
+9.  Security Considerations
+
+   As this document is solely for the purpose of providing metric
+   methodology and describes neither a protocol nor a protocol's
+   implementation, there are no security considerations associated with
+   this document specifically.  Results from these methodologies may
+   identify a performance capability or limit of a device or system in a
+   particular test context.  However, such results might not be
+   representative of the tested entity in an operational network.
+
+10.  Acknowledgements
+
+   The Benchmarking Methodology Working Group of the IETF and
+   particularly Kevin Dubray, Juniper Networks, are to be thanked for
+   the many suggestions they collectively made to help complete this
+   document.
+
+11.  Contributions
+
+   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.
+
+12.  References
+
+12.1.  Normative References
+
+   [Br91]   Bradner, S., "Benchmarking Terminology for Network
+            Interconnection Devices", RFC 1242, July 1991.
+
+   [Br96]   Bradner, S. and J. McQuaid, "Benchmarking Methodology for
+            Network Interconnect Devices", RFC 2544, March 1999.
+
+   [Br97]   Bradner, S. "Use of Keywords in RFCs to Reflect Requirement
+            Levels, RFC 2119, March 1997.
+
+   [Du98]   Dubray, K., "Terminology for IP Multicast Benchmarking", RFC
+            2432, October 1998.
+
+
+
+Stopp & Hickman              Informational                     [Page 28]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+   [IANA1]  IANA multicast address assignments,
+            http://www.iana.org/assignments/multicast-addresses
+
+   [Ma98]   Mandeville, R., "Benchmarking Terminology for LAN Switching
+            Devices", RFC 2285, February 1998.
+
+   [Me98]   Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
+            RFC 2365, July 1998.
+
+12.2.  Informative References
+
+   [Ca02]   Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+            Thyagarajan, "Internet Group Management Protocol, Version
+            3", RFC 3376, October 2002.
+
+   [De89]   Deering, S., "Host Extensions for IP Multicasting", STD 5,
+            RFC 1112, August 1989.
+
+   [Fe97]   Fenner, W., "Internet Group Management Protocol, Version 2",
+            RFC 2236, November 1997.
+
+   [Hu95]   Huitema, C., "Routing in the Internet", Prentice-Hall, 1995.
+
+   [Ka98]   Kosiur, D., "IP Multicasting: the Complete Guide to
+            Interactive Corporate Networks", John Wiley & Sons Inc.,
+            1998.
+
+   [Mt98]   Maufer, T., "Deploying IP Multicast in the Enterprise",
+            Prentice-Hall, 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 29]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+13.  Authors' Addresses
+
+   Debra Stopp
+   Ixia
+   26601 W. Agoura Rd.
+   Calabasas, CA  91302
+   USA
+
+   Phone: + 1 818 871 1800
+   EMail: debby@ixiacom.com
+
+
+   Brooks Hickman
+   Spirent Communications
+   26750 Agoura Rd.
+   Calabasas, CA  91302
+   USA
+
+   Phone: + 1 818 676 2412
+   EMail: brooks.hickman@spirentcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 30]
+
+RFC 3918       Methodology for IP Multicast Benchmarking   October 2004
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Stopp & Hickman              Informational                     [Page 31]
+