Network Working Group                                     Debra Stopp
                                                            Hardev Soor
  INTERNET-DRAFT                                                   IXIA                                                   Ixia
  Expires in:  March  August 2003                               Brooks Hickman
                                                 Spirent Communications
                                                          February 2003

                Methodology for IP Multicast Benchmarking
                     <draft-ietf-bmwg-mcastm-10.txt>
                     <draft-ietf-bmwg-mcastm-11.txt>

  Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC2026.

     Internet-Drafts are working documents of the Internet Engineering
     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
     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
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

  Copyright Notice

     Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.

  Abstract

     The purpose of this draft 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...................................................3

  2. KEY WORDS TO REFLECT REQUIREMENTS..............................3

  3. TEST SET UP....................................................3
  3.1. Test Considerations..........................................5
  3.1.1.  IGMP Support..............................................5
  3.1.2.  Group Addresses...........................................5
  3.1.3.  Frame Sizes...............................................6
  3.1.4.  TTL.......................................................6
  3.1.5.  Trial Duration............................................6
  3.2. Layer 2 Support..............................................6
  4. FORWARDING AND THROUGHPUT......................................6
  4.1. Mixed Class Throughput.......................................6 Throughput.......................................7
  4.2. Scaled Group Forwarding Matrix...............................8
  4.3. Aggregated Multicast Throughput..............................8 Throughput..............................9
  4.4. Encapsulation/Decapsulation (Tunneling) Throughput...........9 Throughput..........10
  4.4.1.  Encapsulation Throughput..................................9 Throughput.................................10
  4.4.2.  Decapsulation Throughput.................................10 Throughput.................................12
  4.4.3.  Re-encapsulation Throughput..............................11 Throughput..............................13
  5. FORWARDING LATENCY............................................12 LATENCY............................................15
  5.1. Multicast Latency...........................................12 Latency...........................................16
  5.2. Min/Max Multicast Latency...................................15 Latency...................................18
  6. OVERHEAD......................................................16 OVERHEAD......................................................20
  6.1. Group Join Delay............................................16 Delay............................................20
  6.2. Group Leave Delay...........................................16 Delay...........................................21
  7. CAPACITY......................................................17 CAPACITY......................................................23
  7.1. Multicast Group Capacity....................................17 Capacity....................................23
  8. INTERACTION...................................................18 INTERACTION...................................................24
  8.1. Forwarding Burdened Multicast Latency.......................18 Latency.......................24
  8.2. Forwarding Burdened Group Join Delay........................19 Delay........................25
  9. SECURITY CONSIDERATIONS.......................................20 CONSIDERATIONS.......................................26

  10. ACKNOWLEDGEMENTS.............................................20 ACKNOWLEDGEMENTS.............................................27

  11. REFERENCES...................................................21 CONTRIBUTIONS................................................27

  12. AUTHOR'S ADDRESSES...........................................22 REFERENCES...................................................28

  13. AUTHOR'S ADDRESSES...........................................29

  14. FULL COPYRIGHT STATEMENT.....................................22 STATEMENT.....................................29
  1. Introduction

     This document defines a specific set of tests that vendors can use
     to measure for measuring and report reporting the performance characteristics
     forwarding, latency and
     forwarding capabilities IGMP group membership characteristics of network
     devices that support IP multicast routing protocols.  The results
     of these tests will provide the user comparable data from different vendors with which to evaluate
     these devices. meaningful data on
     multicast performance.

     A previous document, " Terminology for IP Multicast Benchmarking"
     (RFC 2432), 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 IP multicast communication. topologies.

  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 RFC 2119.
     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 draft document are for single
     ingress, multiple egress scenarios as exemplified by Figures 1 and
     2.  Methodologies for multiple ingress, ingress and multiple egress
     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.
                                                     +----------------+

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

                                 Figure 1
                                ---------

     If the multicast metrics are to be taken across multiple devices
     forming a System Under Test (SUT), then test packets frames are offered to
     a single ingress interface on a device of the SUT, subsequently
     routed
     forwarded across the SUT topology, and finally forwarded to the
     test apparatus' packet-receiving 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 details of the test topology and all
     relevant configuration details MUST be disclosed with the
     corresponding test results.

                 *-----------------------------------------*
                 |                                         |
     +--------+  |                     +----------------+  |  +--------+
     |        |  |   +------------+    |DUT B Egress E0(-)-->| E0(-)-|->|        |
     |        |  |   |DUT A       |--->|                |  |  |        |
     | Test   |  |   |            |    |      Egress E1(-)-->| E1(-)-|->| Test   |
     | App.   |--->(-)Ingress,   |--|->(-)Ingress, I |    +----------------+  |  | App.   |
     | Traffic|  |   |            |    +----------------+  |  | Traffic|
     | Src.   |  |   |            |--->|DUT C Egress E2(-)-->| E2(-)-|->| Dest.  |
     |        |  |   +------------+    |                |  |  |        |
     |        |  |                    |      Egress En(-)-->| En(-)--|->|        |
     +--------+  |                     +----------------+  |  +--------+
                 |                                         |
                 *------------------SUT--------------------*

                                  Figure 2
                                  ---------

     Generally, the destination test ports first join the desired number
     of multicast groups by sending IGMP Join Group Report messages to the
     DUT/SUT. To verify that all destination test ports successfully
     joined the appropriate groups, the source port MUST transmit IP
     multicast frames destined for these groups. The destination test
     ports MAY send IGMP Leave Group messages after the transmission of
     IP Multicast frames 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 only the frames that are involved in the test.

  3.1. Test Considerations

     The procedures outlined below are written without regard for
     specific physical layer or link layer protocols. The methodology
     further 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 specified 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, before an
     initial, measured forwarding test trial, 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.

  3.1.1. IGMP Support

     Each

     All of the destination ports should support and be able to test
     all IGMP versions 1, 2 ingress and 3. egress interfaces MAY support any version of
     IGMP.  The minimum requirement, however, is IGMP version 2. on the ingress interface MUST be the same
     version of IGMP that is being tested on the egress interfaces.

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

     Each destination port should of the ingress and egress interfaces SHOULD also send LEAVE
     (running IGMP version
     2) 2 or later) after each test.

  3.1.2. Group Addresses

     It is intended that the collection of benchmarks prescribed in this
     document be executed in an isolated lab environment.  That is to
     say, the test traffic offered the tested devices MUST NOT traverse
     a live internet, intranet, or other user-oriented production network.

     Assuming the above, there is no restriction to the use of multicast
     addresses to compose the test traffic other than those assignments
     imposed by IANA.  The IANA assignments MUST be regarded for
     operational consistency.  For multicast address assignments see:

           http://www.iana.org/assignments/multicast-addresses

     It should be noted that address

     Address selection need does not need to be restricted to
     Administratively Scoped IP Multicast addresses.

  3.1.3. Frame Sizes

     Each test SHOULD be run with different Multicast Frame Sizes. The
     recommended multicast frame sizes. For
     Ethernet, the recommended sizes are 64, 128, 256, 512, 1024, 1280,
     and 1518 byte frames.

     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 source frames data plane test traffic should have a TTL value large enough to
     accommodate
     traverse the DUT/SUT.

     The TTL in IGMP control plane messages is 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.

  3.2.  Layer 2 Support

     Each of the destination ports should support GARP/GMRP protocols to
     join groups on Layer 2 DUTs/SUTs.

  4. Forwarding and Throughput

  This section contains the description of the tests that are related
  to the characterization of the packet frame forwarding of a DUT/SUT in a
  multicast environment.  Some metrics extend the concept of throughput
  presented in RFC 1242. The notion of  Forwarding Rate is cited in RFC 2285.

  4.1. Mixed Class Throughput

     Objective

     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 ports interfaces as defined in RFC 2432.

     Procedure

     Procedure:

     Multicast and unicast traffic are mixed together in the same
     aggregated traffic stream in order to simulate the non-homogenous
     networking environment.

     The DUT/SUT MUST learn the appropriate
     unicast IP addresses, either by sending ARP frames from each
     unicast address, sending a RIP packet or by assigning static
     entries into the DUT/SUT address table.

     The relationship between the intended load [Ma91] of multicast
     class frames vs. unicast class frames MUST be specified:

          a) As an independent rate for unicast class and multicast
             class of traffic OR
          b) As an aggregate rate comprised of a ratio of multicast
             class to unicast class of traffic.

     The offered load per each DUT/SUT port following events MUST not exceed the maximum
     bandwidth capacity of any configured receive DUT/SUT ports. occur before offering test traffic:

          o All DUT/SUT ports egress interfaces configured to receive
            multicast traffic MUST join all configured multicast groups prior to transmitting test frames.
     Joining a group is accomplished by sending an IGMP Join Group
     messages.  All
            groups;
          o The DUT/SUT ports configured to receive unicast traffic MUST send learn the appropriate unicast addresses;
            and
          o Group membership and unicast address learning frames prior to transmitting test frames (see
     section 3 for more information).

     Unicast traffic distribution can either MUST be non-meshed or meshed
            verified through some externally observable method.

     The intended load [Ma98] as specified in RFC2544 or RFC2289.  A minimum of one
     unicast transmit port MUST SHOULD be configured to transmit as alternating
     multicast frames and unicast
     traffic frames to a DUT/SUT port that is configured to receive single ingress interface
     in a 50-50 ratio.  The unicast and
     multicast traffic.

     Multicast traffic distribution frames MUST be configured to
     transmit
     traffic in a one-to-many mesh [Ma98] configuration.  A minimum round-robin fashion to all of
     one the egress interfaces.
     The multicast transmit port frames MUST be configured to transmit
     multicast traffic to a DUT/SUT port that is configured to receive
     multicast traffic.

     Throughput all of the
     egress interfaces.

     Mixed class throughput measurement is defined in RFC1242 [Br91]. RFC2432 [Du98]. A
     search algorithm MUST be utilized to determine the maximum offered frame
     rate with throughput for
     both unicast class and multicast class traffic in a zero frame loss rate.

     Result

     Parameters to be measured mixed class
     environment.

     Reporting Format:

     The following configuration parameters MUST include be reflected in the aggregate offered load,
     results specific to this methodology:

          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 frames offered, number groups
          o Traffic distribution for unicast and multicast traffic
            classes
          o The ratio of multicast and unicast frames
     offered, traffic must be declared
     The following results MUST be reflected in the results specific to
     this methodology:

          o Mixed Class Throughput as defined in RFC2432 [Du98],
            including: Throughput per unicast and multicast traffic
            classes.

     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 received, offered,
     number of unicast frames received and transmit duration of offered frames. and measured throughput per class.

  4.2.  Scaled Group Forwarding Matrix

     Objective

     Objective:

     To determine Forwarding Rate as a function of tested multicast
     groups for a fixed number of tested DUT/SUT ports.

     Procedure

     Multicast traffic

     Procedure:

     This is sent at a fixed percent of maximum offered
     load with a fixed an iterative procedure. The destination test port(s) MUST
     join an initial number of receive ports of the tester at a fixed
     frame length.

     On each iteration, multicast groups on the first iteration.
     All DUT/SUT destination test port(s) configured to receive ports SHOULD incrementally
     multicast traffic MUST join 10 all configured multicast groups until a user defined maximum groups.  The
     recommended number of groups is
     reached.

     Results

     Parameters to be measured MUST include the offered load and
     forwarding rate as a function of join on the total first iteration is 10
     groups.  Multicast traffic is subsequently transmitted to all
     groups joined on this iteration.

     The number of multicast
     groups, for groups joined by each destination test iteration. port
     is then incremented, or scaled, by an additional number of
     multicast groups.  The nature recommended granularity of the traffic stream contributing additional groups
     to join per iteration is 10, although the result MUST be
     reported, specifically tester MAY choose a finer
     granularity.  Multicast traffic is subsequently transmitted to all
     groups joined during this iteration.

     The total number of source and destination ports
     within the multicast group.  In addition, all other reporting
     parameters groups joined MUST not exceed the
     capacity of the scaled group forwarding matrix methodology DUT/SUT. Both Group Join Delay and Group Capacity
     results MUST be known prior to running this test.

     Reporting Format:

     The following configuration parameters MUST be reflected in the
     results report, such as the transmitted packet specific to this methodology:

          o Frame size(s) and offered load
          o Number of tested egress interfaces on the packet stream for each source port.

     Result reports DUT/SUT
          o Test duration
          o IGMP version

     The following results MUST include be reflected in the following parameters results specific to
     this methodology:

          o The total number of multicast groups joined for each
     iteration: the that
            iteration
          o Total number of frames offered, transmitted
          o Total number of frames received
     per
          o Offered load
          o Forwarding rate determined for that iteration

     The Scaled Group Forwarding results for each group, number of multicast groups and forwarding rate, test SHOULD be
     reported in
     frames per second, and transmit duration the form of offered frames.
     Constructing a table that contains with a row representing each
     iteration of the forwarding rate vs. test.  Each row or iteration SHOULD specify the
     total number of groups is desirable. joined for that iteration, 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

     Objective:

     To determine the maximum rate at which none of the offered frames
     to be forwarded through N destination interfaces of the same
     multicast group is groups are dropped.

     Procedure

     Multicast

     Procedure:

     Offer multicast traffic is sent at a an initial fixed percent of 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.

     The initial number of receive  All destination test ports of the tester will
     MUST join the
     group(s) and the sender will transmit to the same groups after a
     certain delay (a few seconds). all specified multicast groups.

     If any frame loss is detected, one receive port MUST leave the
     group(s) offered load is decreased and
     the sender will transmit again.  Continue in this  An iterative fashion until either there are no ports left joined 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 group(s) OR 0% traffic, while keeping the set of interfaces, number of
     multicast groups, frame loss length and test duration fixed, until the
     maximum rate at which none of the offered frames are dropped is achieved.

     Results
     determined.

     Parameters to be measured MUST include the maximum offered load at which no
     frame loss occurred (as defined by RFC 2544) occurred.

     Reporting Format:

     The nature of the traffic stream contributing to the result MUST be
     reported.  All required reporting following configuration parameters of aggregated
     throughput MUST be reflected in the
     results report, such as the
     initial number specific to this methodology:

          o Frame size(s)
          o Number of receive ports, tested egress interfaces on the final number of receive ports,
     total DUT/SUT
          o Test duration
          o IGMP version
          o Total number of multicast group addresses, groups

     The following results MUST be reflected in the transmitted packet
     size(s), offered load of results specific to
     this methodology:

          o Aggregated Multicast Throughput as defined in RFC2432
            [Du98]

     The Aggregated Multicast Throughput results SHOULD be reported in
     the packet stream and transmit duration format of
     offered frames.

     Constructing a table from the measurements might be useful in
     illustrating the effect with a row for each of modifying the tested frame sizes
     per the recommendations in section 3.1.3.  Each row or iteration
     SHOULD specify offered load, total number of active egress
     ports on offered frames and the tested system.
     measured Aggregated Multicast Throughput.

  4.4. Encapsulation/Decapsulation (Tunneling) Throughput

     This sub-section provides the description of tests that help in
     obtaining throughput measurements when a DUT/SUT or a set of DUTs
     are acting as tunnel endpoints.

  4.4.1. Encapsulation Throughput

     Objective

     Objective:

     To determine the maximum rate at which frames offered to one
     ingress interface of a DUT/SUT are encapsulated and correctly
     forwarded by on one or more egress interfaces of the DUT/SUT without
     loss.

     Procedure

     Traffic is offered to

     Procedure:

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

                                 Figure 3
                                 ---------

     Figure 3 shows the ingress interface setup for testing the encapsulation throughput
     of a DUT/SUT <Figure 1>
     that has been configured to encapsulate the frames DUT/SUT.  One or more tunnels are created between each
     egress interface of the DUT/SUT and received on a destination test port prior port.  Non-
     Encapsulated multicast traffic will then be offered by the source
     test port, encapsulated by the DUT/SUT and forwarded to decapsulation at the egress interface.
     destination test port(s).

     The DUT/SUT SHOULD be configured such that the constitution of 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.

     Each tunnel created by the ingress DUT/SUT SHOULD contain the same

     The number of multicast address groups per tunnel interface.

     The offered load on the ingress port MUST not oversubscribe be the
     outbound link of same when the
     DUT/SUT with respect to the benchmarked
     throughput at the encapsulated frame size.

     Results

     Based on the resulting encapsulated frame size, parameters is configured in a multiple tunnel configuration.  In
     addition, it is RECOMMENDED to be
     measured MUST include the maximum offered load at which no frame
     loss occurred, test with the same number of encapsulated tunnels
     on each egress interface.  All destination test ports MUST join all
     multicast frames group addresses offered
     per tunnel interface, and the number of encapsulated multicast
     frames received per tunnel interface.

     The nature of by the traffic stream contributing to source test port.  Each
     egress interface MUST be configured with the result same MTU.

     A search algorithm MUST be
     reported.  All required reporting parameters of multicast utilized to determine the encapsulation
     throughput as defined in [Du98].

     Reporting Format:

     The following configuration parameters MUST be reflected in the
     results report,
     such as specific to this methodology:

          o Number of tested egress interfaces on the encapsulation format, transmitted packet size(s),
     encapsulated frame size, and transmit DUT/SUT
          o Test duration
          o IGMP version
          o Total number of multicast groups
          o MTU size of offered frames.

  4.4.2. Decapsulation Throughput

     Objective

     To determine the maximum rate at which frames offered a DUT/SUT are
     decapsulated and correctly forwarded by interfaces
     The following results MUST be reflected in the DUT/SUT without loss.

     Procedure results specific to
     this methodology:

          o Measured Encapsulated traffic is offered Throughput as defined in RFC2432
            [Du98]
          o Encapsulated frame size
          o Originating un-encapsulated frame size
          o Number of tunnels
          o Number of multicast groups per tunnel

     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 egress 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 <Figure 1> that has been configured to decapsulate are decapsulated and correctly
     forwarded by the
     frames.

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

     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.

     Due to the nature

     The number of decapsulation, 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 load on by the
     encapsulated source test port.  Each egress port will interface MUST
     be less than the offered load on configured with the
     decapsulated egress interface.

     Results

     Based on same MTU.

     A search algorithm MUST be utilized to determine the resulting decapsulated frame size, decapsulation
     throughput as defined in [Du98].

     Reporting Format:

     The following configuration parameters to be
     measured MUST include the maximum offered load at which no frame
     loss occurred, be reflected in the number
     results specific to this methodology:

          o Number of encapsulated multicast frames offered
     per tunnel interface, and tested egress interfaces on the DUT/SUT
          o Test duration
          o IGMP version
          o Total number of multicast frames received
     after decapsulation.

     The nature of the traffic stream contributing to the result MUST be
     reported.  All required reporting parameters groups
          o MTU size of multicast
     decapsulation throughput DUT/SUT interfaces

     The following results MUST be reflected in the results report,
     such specific to
     this methodology:

          o Measured Decapsulated Throughput as defined in RFC2432
            [Du98]
          o Originating encapsulation format
          o Decapsulated frame size
          o Originating encapsulated frame size
          o Number of tunnels
          o Number of multicast groups per tunnel

     The Decapsulated Throughput results SHOULD be reported in the transmitted packet size(s),
     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,
     and transmit duration
     total number of offered frames. frames and the decapsulation throughput.

  4.4.3. Re-encapsulation Throughput

     Objective

     Objective:

     To determine the maximum rate at which frames 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 to 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 one encapsulated
     format offered a DUT/SUT are converted to another encapsulated
     format and correctly forwarded by the DUT/SUT without loss.

     Procedure

     Encapsulated DUT/SUT.  The source test port will offer
     encapsulated traffic of one type is offered to the egress interface
     of a DUT/SUT <Figure 1> that 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 constitution of traffic across each
     egress interface will consist of either:

          c)

          a) A single tunnel encapsulating one or more multicast address
            groups OR
          d)
          b) Multiple tunnels, each encapsulating one or more multicast
            address groups.

     Each tunnel created by the ingress DUT/SUT SHOULD contain the same

     The number of multicast address groups per tunnel interface.

     The offered load on the ingress port MUST not oversubscribe be the
     outbound link with respect to same when the offered load at
     DUT/SUT is configured in a multiple tunnel configuration.

     In addition, the higher end of DUT/SUT SHOULD be configured such that the DUT/SUTs capacity based number
     of tunnels on the encapsulated frame size.

     Results

     Based on ingress and each egress interface are the resulting encapsulated frame size, parameters to same.
     All destination test ports MUST join all multicast group addresses
     offered by the source test port. Each egress interface MUST be
     measured
     configured with the same MTU.

     A search algorithm MUST include be utilized to determine the maximum offered load at which no frame
     loss occurred, re-
     encapsulation throughput as defined in [Du98].

     Reporting Format:

     The following configuration parameters MUST be reflected in the number
     results specific to this methodology:

          o Number of encapsulated multicast frames offered
     per tunnel interface, and tested egress interfaces on the DUT/SUT
          o Test duration
          o IGMP version
          o Total number of encapsulated multicast
     frames received per tunnel interface.

     The nature groups
          o MTU size of the traffic stream contributing to the result DUT/SUT interfaces

     The following results MUST be
     reported.  All required reporting parameters reflected in the results specific to
     this methodology:

          o Measured Re-encapsulated Throughput as defined in RFC2432
            [Du98]
          o Originating encapsulation format
          o Decapsulated frame size
          o Originating encapsulated frame size
          o Number of tunnels
          o Number of multicast
     encapsulation throughput MUST groups per tunnel

     The Decapsulated Throughput results SHOULD be reflected reported in the results report,
     such as the encapsulation
     format on the egress interface,
     transmitted packet size(s), 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, and transmit
     duration
     total number of offered frames. frames and the decapsulation 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.

     In order to

     To lessen the effect of packet frame buffering in the DUT/SUT, the latency
     tests MUST be run at the measured multicast throughput level of the
     DUT; multicast latency at other offered loads is optional.

     Lastly, RFC 1242 and RFC 2544 draw a distinction between two classes
     of devices: device
     types: "store and forward" and "bit-forwarding." Each class type impacts
     how latency is collected and subsequently presented. See the
     related RFCs for more information.  In practice, much of the test
     equipment will collect the latency measurement for one class type or the
     other, and, if needed, mathematically derive the reported value by
     the addition or subtraction of values accounting for medium
     propagation delay of the packet, frame, bit times to the timestamp trigger
     within the packet, frame, etc. Test equipment vendors SHOULD
     provide documentation regarding the composition and calculation
     latency values being reported.  The user of this data SHOULD
     understand the nature of the latency values being reported,
     especially when comparing results collected from multiple test
     vendors. (E.g., If test vendor A presents a "store and forward"
     latency result and test vendor B presents a "bit-forwarding"
     latency result, the user may erroneously conclude the DUT has two
     differing sets of latency values.)

  5.1. Multicast Latency

     Objective

     Objective:

     To produce a set of multicast latency measurements from a single,
     multicast ingress port interface of a DUT/SUT through multiple, egress
     multicast ports interfaces of that same DUT/SUT as provided for by the
     metric "Multicast Latency" in RFC 2432.

     The procedures Procedures highlighted below attempt to draw from the
     collection methodology for latency in RFC 2544 to the degree
     possible.  The methodology addresses two topological scenarios: one
     for a single device (DUT) characterization; a second scenario is
     presented or multiple device (SUT) characterization.

     Procedure

     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 packet- frame-
     transmitting component of the test apparatus and n egress
     interfaces on the same DUT forwarding the multicast test traffic
     back to the packet-receiving 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.  Departures seconds to the
     suggested traffic class guidelines MUST be disclosed consistent with the
     respective trial results. RFC
     2544.  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.

     End-to-end reach ability reachability of the test traffic path MUST be verified
     prior to the engagement of a test trial.  This implies that
     subsequent measurements are intended to characterize the latency
     across the tested device's or devices' normal traffic forwarding
     path (e.g., faster hardware-based engines) of the device(s) as
     opposed a non-standard traffic processing path (e.g. slower,
     software-based exception handlers).  If the test trial is to be
     executed with the intent of characterizing a non-optimal,
     forwarding condition, then a description of the exception
     processing conditions being characterized MUST be included with the
     trial's results.

     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") packet frame into
     the test traffic packets frames being presented.  This tagged packet 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" packet frame from the other packets frames comprising the test traffic
     set.  A packet frame generation timestamp, Timestamp A, reflecting the
     completion of the transmission of the tagged packet frame by the test
     apparatus, MUST be determined.

     The test apparatus then monitors packets frames from the DUT's tested
     egress port(s) interface(s) for the expected tagged packet(s) frame(s) until the
     cessation of traffic generation at the end of the configured trial
     duration.A value of the Offered Load presented the DUT/SUT MUST be
     noted.
     duration.

     The test apparatus MUST record the time of the successful detection
     of a tagged packet 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 Forwarded test packets frames directed to improper destinations.
       .
          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 packets frames improperly formed or packet frame header
            fields improperly manipulated.
       .
          o Failure to forward required tagged packet(s) frame(s) on all expected
            egress interfaces.
       .
          o Reception of a tagged packet frame by the test apparatus outside
            the configured test duration interval or 5 seconds,
            whichever is greater.

     Data from invalid trials SHOULD be considered inconclusive.  Data
     from invalid trials MUST not form the basis of comparison.

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

     Reporting Format:

     The following configuration parameters MUST be reflected in the
     results specific to this methodology:

          o Frame size(s)
          o Number of tested egress interfaces and Timestamp B represents a tagged packet detection
     event for a given on the DUT/SUT tested egress interface.

     Results

     Two types
          o Test duration
          o IGMP version
          o Offered load
          o Total number of information multicast groups

     The following results MUST be reported: 1) reflected in the set results specific to
     this methodology:

          o The time units of the presented latency
     measurements MUST be uniform and 2) the significant environmental, methodological,
     or device particulars giving insight into
            with sufficient precision for the test medium or its results. media being
            tested.
          o Specifically, when reporting the results of a VALID valid test
            trial, the set of ALL all latencies related to the tested
            ingress interface and each tested egress DUT/SUT interface of MUST be
            presented.

     The
     time units of the presented latency MUST results for each test SHOULD be uniform and reported in the form of
     a table, with
     sufficient precision a row for each of the medium or media being tested.  Results
     MAY be offered tested frame sizes per the
     recommended frame sizes in tabular format section 3.1.3, and SHOULD preserve the
     relationship of latency to ingress/egress interface interface(s) to assist in
     trending across multiple trials.

     The Offered Load of the test traffic presented the DUT/SUT, size of
     the "tagged" packet, transmit duration of offered frames and nature
     (i.e., store-and-forward or bit-forwarding) of the trial's
     measurement MUST be associated with any reported test trial's
     result.

  5.2. Min/Max Multicast Latency

     Objective

     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

     Procedure:

     Collect a set of multicast latency measurements, 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
     packet frame ingress and DUT packet 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 port, interface, I, of
     the DUT, and Ex a specific, tested multicast egress port interface of
     the DUT.  E1 through En are unique egress ports interfaces on the DUT.

     From the collected multicast latency measurements in set M,
     identify MAX(M), where MAX is a function that yields the largest
     latency value from set M.

     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)

     Results

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

     Reporting Format:

     The result following configuration parameters MUST be reflected in the
     results specific to this methodology:

          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 results specific to
     this methodology:

          o The result of the min/max value represented as a single
            numerical value in time units consistent with the
            corresponding latency measurements.  In
     addition,
          o Specifically, when reporting the number results of tested egress ports on a valid test
            trial, the DUT MUST be
     reported.

     The nature set of the traffic stream contributing all latencies related to the result MUST be
     reported.  All required reporting parameters tested
            ingress interface MUST be reported.

     The time units of multicast the presented latency MUST be reflected in uniform and with
     sufficient precision for the min/max medium or media being tested.  The
     latency results report, such as for each test SHOULD be reported in the
     transmitted packet size(s), offered load form of a
     table, with a row for each of the packet stream in
     which the tagged packet was presented to tested frame sizes per the DUT
     recommendations in section 3.1.3, and transmit
     duration SHOULD preserve the
     relationship of offered frames. latency to ingress/egress interface(s) to assist in
     trending across multiple trials.

  6. Overhead

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

  6.1. Group Join Delay

     Objective

     Objective:

     To determine the time duration it takes a DUT/SUT to start
     forwarding multicast packets frames from the time a successful IGMP group
     membership report has been issued to the DUT/SUT.

     Procedure

     Traffic is sent on

     Procedure:

     Prior to sending any IGMP Group Membership Reports used to
     calculate the source port at group join delay, it MUST be verified through
     externally observable means that the same time as destination test ports are not
     currently a member of any of the specified multicast groups.  If
     any of the egress interfaces forward multicast frames, the test is
     not valid.

     Once verification is complete, multicast traffic for all relevant
     multicast group addresses MUST be offered to the ingress interface
     prior to receipt or processing of any IGMP
     JOIN Group message Membership Report
     messages.  It is transmitted from RECOMMENDED to offer traffic at the measured
     aggregated multicast throughput rate (Section 4.3).

     After the multicast traffic has been started, each destination ports. test
     port (See Figure 1) SHOULD send one IGMP Group Membership Report
     with one or more (IGMP V3) multicast group(s) specified.  All
     destination test ports MUST join all multicast groups offered on
     the ingress interface of the DUT/SUT.  The test MUST be performed
     with one multicast group and SHOULD be performed with multiple
     groups.

     The join delay is the difference in time from when the IGMP Join Group
     Membership message is sent (timestamp A) and the first frame of the
     multicast group is forwarded to a receiving
     member port egress interface
     (timestamp B).

              Group Join delay time = timestamp B - timestamp A

     One

     Timestamp A MUST be the time the last bit of the keys is to transmit at IGMP group
     membership report is sent from the destination test port; timestamp
     B MUST be the time the fastest rate first bit of the DUT/SUT can
     handle first valid multicast frames.  This frame
     is to get the best resolution and forwarded on the least margin egress interface of error in the Join Delay.

     However, you do not want to transmit the frames so fast that frames
     are dropped by the DUT/SUT. Traffic should

     Reporting Format:

     The following configuration parameters MUST be sent at reflected in the
     throughput rate determined by
     results specific to this methodology:

          o Frame size(s)
          o Number of tested egress interfaces on the forwarding tests DUT/SUT
          o Test duration
          o IGMP version
          o Total number of section 4.

     Results multicast groups

     The parameter following results MUST be reflected in the results specific to
     this methodology:

          o The group join delay time per multicast group address
          o The group join delay time per egress interface(s)

     The Group Join Delay results for each test SHOULD be measured is 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 group join delay time for each multicast group address
     per destination port. In addition, the interface, number of frames transmitted and number
     of frames received and percent loss may be
     reported. for that iteration.

  6.2. Group Leave Delay

     Objective

     Objective:

     To determine the time duration it takes a DUT/SUT to cease
     forwarding multicast packets frames after a corresponding IGMP "Leave
     Group" Leave Group
     message has been successfully offered to the DUT/SUT.

     Procedure

     Traffic

     Procedure:

     Prior to sending any IGMP Group 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 a member of all the specified multicast groups.  If any
     of the destination test ports do not receive multicast frames, the
     test is sent on not valid.

     Once verification is complete, multicast traffic for all relevant
     multicast group addresses MUST be offered to the source port ingress interface
     prior to receipt or processing of any IGMP Leave Group messages.
     It is RECOMMENDED to offer traffic at the same time as 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 messages are transmitted from the message for each
     multicast group specified.  All destination ports. test ports MUST leave
     all relevant multicast groups offered on the ingress interface of
     the DUT/SUT.  The test MUST be performed with one multicast group
     and SHOULD be performed with multiple groups.

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

             Group Leave delay time = timestamp B - timestamp A

     One

     Timestamp A MUST be the time the last bit of the keys IGMP Leave Group
     message is to transmit at sent from the fastest rate destination test port; timestamp B MUST be
     the DUT/SUT can
     handle multicast frames.  This is to get time the best resolution and
     least margin last bit of error in the Leave Delay.  However, you do not want
     to transmit last valid multicast frame is
     forwarded on the frames too fast that frames are dropped by egress interface of the DUT/SUT.  Traffic should

     Reporting Format:

     The following configuration parameters MUST be sent at reflected in the throughput rate determined
     by
     results specific to this methodology:

          o Frame size(s)
          o Number of tested egress interfaces on the forwarding tests DUT/SUT
          o Test duration
          o IGMP version
          o Total number of section 4.

     Results multicast groups

     The parameter following results MUST be reflected in the results specific to
     this methodology:

          o The group leave delay time per multicast group address
          o The group leave delay time per egress interface(s)

     The Group Leave Delay results for each test SHOULD be measured is 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 group leave delay time for each multicast group address
     per destination port. In addition, the interface, number of frames transmitted and number
     of frames received and percent loss may be
     reported. for that iteration.

  7. Capacity

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

  7.1. Multicast Group Capacity

     Objective

     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

     Procedure:

     One or more destination ports egress interfaces of DUT/SUT will join an initial
     number of multicast groups.

     Then after

     After a delay (enough time for all ports to join) as determined by section 6.1, the source
     port will ingress interface
     MUST transmit to each group at a transmission rate that the
     DUT/SUT can handle without dropping IP Multicast frames. specified offered load.

     If all frames sent are at least one frame for each multicast group is forwarded
     properly by the DUT/SUT and received to each participating egress interface, the
     test
     iteration is said to pass at the current capacity.

     If the iteration passes at the capacity passes, the test will add an a user defined
     incremental value of groups to each receive port.

     The iteration is to run again at egress interface. At the new
     group level and resultant capacity
     tested as stated above. above, run the
     iteration again.

     Once the test fails at a capacity fails, the last/previous iteration capacity that
     passed is the stated to Maximum Group Capacity result.

     Reporting Format:

     The following configuration parameters MUST be reflected in the
     last Iteration that pass at a giving capacity.

     Results

     The parameter
     results specific to this methodology:

          o Frame size(s)
          o Number of tested egress interfaces on the DUT/SUT
          o Test duration
          o IGMP version
          o Offered load

     The following results MUST be measured is reflected in the results specific to
     this methodology:

          o The total number of multicast group addresses that were
            successfully forwarded with no loss.

     In addition, through the nature 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 traffic stream contributing to tested
     frame sizes per the
     result MUST be reported.  All required reporting parameters MUST be
     reflected recommendations in section 3.1.3.  Each row or
     iteration SHOULD specify the results report, such as the number of multicast groups joined per
     destination interface, number of frames transmitted packet
     size(s) and offered load number of the packet stream.
     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 terms procedures to
     assist in the characterization of DUT/SUT behavior in consideration
     of potentially interacting factors.

  8.1. Forwarding Burdened Multicast Latency

     Objective

     Objective:

     To produce a set of multicast latency measurements from a single, single
     multicast ingress port interface of a DUT/SUT through multiple, multiple egress
     multicast ports interfaces of that same DUT/SUT as provided for by the
     metric "Multicast Latency" in RFC 2432, 2432 while burdening the DUT/SUT by
     injecting addresses into under the DUT/SUT address table.

     Procedure influence of
     a traffic forwarding requirement.

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

     The Burdened Forwarding Latency test MUST follow the described
     setup in Section 5.1, 5.1.

     Perform a set baseline measurement of ports on latency as described in Section
     5.1.  After the tester will be
     designated to be baseline measurement is obtained, the test is
     repeated with the source and destination in this test. In
     addition to this setup, another ingress interface offering an additional set of ports will be selected to
     transmit some multicast class traffic that is destined to
     user specified multicast group addresses that which have not been joined
     by these additional set
     of ports.

     For example, ports 1,2, 3, and 4 form the burdened response setup
     (setup A) which is used to obtain the latency metrics and ports 5,
     6, 7, and 8 form the non-burdened response setup (setup B) which
     will afflict the burdened response setup.  Setup B traffic will
     then join multicast group addresses not joined by destination test port(s).  The offered load MUST be the ports same
     as was used in this
     setup. the baseline measurement.

     By sending such multicast class traffic, the DUT/SUT will may perform a
     lookup on the packets frames that will may affect the processing of
     setup A traffic.

     Results

     Result reports MUST include traffic
     destined for the egress interface(s).

     Reporting Format:

     Similar to Section 5.1, the following configuration parameters for each
     iteration: transmitted packet size, MUST
     be reflected in the number of frames offered,
     number results specific to this methodology:

          o Frame size(s)
          o Number of frames received per each group, tested egress interfaces on the DUT/SUT
          o Test duration
          o IGMP version
          o Total number of multicast groups and forwarding rate in frames per second, number of
     addresses injected into address table for that iteration, and
     transmit duration of offered frames.  The result report must also
     specify the baseline setup
          o Total number of source and destination ports within the additional multicast group, as well as the ports designated groups used to inject
     addresses throughout burden
            the test. setup

     The following metrics results MUST be reported:
       1) The set of latency measurements
       2) reflected in the results specific to
     this methodology:

          o The nature time units of the presented latency measured (i.e., store-and-forward or
          bit-forwarding)
       3) The significant environmental, methodological, MUST be uniform and
            with sufficient precision for the medium or device
          particulars giving insight into media being
            tested
          o Specifically, when reporting the results of a valid test
            trial, the set of all latencies related to the tested
            ingress and each tested egress DUT/SUT interface of MUST be
            presented
          o Reported results from baseline measurement; section 5.1

     The latency results for each test or its results.

     Constructing SHOULD be reported in the form of
     a table that contains table, with a row for each of the latency vs. number tested frame sizes per the
     recommended frame sizes in section 3.1.3, and SHOULD preserve the
     relationship of
     injected addresses is desirable. latency to ingress/egress interface(s) to assist in
     trending across multiple trials.

  8.2. Forwarding Burdened Group Join Delay

     Objective

     Objective:

     To determine the time duration it takes a DUT/SUT to start
     forwarding multicast packets frames from the time a successful IGMP group
     membership report Group
     Membership Report has been issued to the DUT/SUT while burdening under the DUT/SUT
     influence of a traffic forwarding requirement.

     Procedure:

     The Group Join Delay metrics can be influenced by injecting addresses into forcing the
     DUT/SUT address table
     on a unrelated set to perform extra process of ports.

     Procedure packets while attempting to
     update and maintain the IP multicast address forwarding table.

     The port configuration in this Forwarding Burdened Group Join Delay test is similar to MUST follow the one
     described setup in Sections 6.1 and 8.1, however, Section 6.1.

     Perform a baseline measurement of group join delay as described in
     Section 6.1.  After the baseline measurement is obtained, the test
     is repeated with the ingress interface offering an additional set
     of transmit
     ports, user specified multicast group address which comprise setup B, do have not send multicast class
     traffic. Setup A traffic must been
     joined by the destination test port(s).  The offered load MUST be influenced
     the same as was used in the baseline measurement.

     By sending such multicast class traffic, the DUT/SUT may perform a way
     lookup on the frames that will may affect the DUT's/SUT's ability to process processing of the IGMP
     Group Join Report messages.
     Therefore,

     Reporting Format:

     Similar to Section 6.1, the following configuration parameters MUST
     be reflected in the results specific to this test, methodology:

          o Frame size(s)
          o Number of tested egress interfaces on the ports DUT/SUT
          o Test duration
          o IGMP version
          o Total number of multicast groups in the baseline setup B will send a set
          o Total number of
     IGMP Group Join messages while additional multicast groups used to burden
            the ports in setup A are also
     simultaneously joining its own set of group addresses. Since

     The following results MUST be reflected in the
     two sets of results specific to
     this methodology:

          o The group addresses are independent of each other, the join delay time per multicast group address
          o The group join delay time per egress interface(s)
          o Reported results from baseline measurement; section 6.1

     The Group Join Delay results for setup A may each test SHOULD be different than reported in
     the case when
     there were no other group addresses being joined.

     Results

     Similar to Section 6.1, form of a table, with a row for each of the parameter to be measured is tested frame sizes
     per the leave recommendations in section 3.1.3.  Each row or iteration
     SHOULD specify the group join delay time for each multicast group address
     per destination port.
     Result reports MUST specify the number of multicast groups joined
     in the join delay port group, the number of groups joined by the
     unrelated ports, the interface, number of source and destination ports within
     the join delay port group, frames transmitted and the number
     of unrelated ports
     designated to inject addresses throughout the test.

     Constructing a table frames received for that contains the join delay time vs. number
     of injected addresses is desirable. 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.

  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 and editing of this
     document  document:
     Hardev Soor, Ixia, and Ralph Daniels, Netcom Systems, Spirent Communications, both
     who made significant contributions to the earlier versions of this draft,
     document.  In addition, the authors would like to acknowledge the
     members of the task team who helped bring this document to
     fruition: Michele Bustos,
     IXIA, Tony De La Rosa, David Newman and Kevin Dubray, Juniper Networks.

  11. Jerry
     Perser.

  12. References

  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.

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

  Informative References

  [Ca02] Cain, B., et al., "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.

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

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

  [Se98] Semeria, C. and Maufer, T.  "Introduction to IP Multicast
         Routing."  http://www.3com.com/nsc/501303.html  3Com Corp.,
         1998.

  12.

  13. Author's Addresses

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

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

     Hardev Soor
     IXIA
     26601 W.

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

     Phone: + 1 818 871 1800 676 2412
     EMail: hardev@ixiacom.com

  13. brooks.hickman@spirentcom.com

  14. Full Copyright Statement

     "Copyright (C) The Internet Society (date). (2003). All Rights Reserved.
     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain
     it or assist in its implementation may be prepared, copied,
     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. into.