Subject: draft-ietf-bmwg-mcastm-00.txt

From: Kevin Dubray <[email-masked]>
Date: Wed, 03 Mar 1999 08:35:46 -0500

Network Working Group                                        Hardev Soor
INTERNET-DRAFT                                               Debra Stopp
Expiration Date:  August 1999                        Ixia Communications
                                                           Ralph Daniels
                                                          Netcom Systems

                                                           February 1999

               Methodology for IP Multicast Benchmarking
                    <draft-ietf-bmwg-mcastm-00.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.

Abstract

   The purpose of this draft is to describe methodology specific to  the
   benchmarking  of  multicast IP forwarding devices. It builds upon the
   tenets set forth in RFC 1944, 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.

Soor, Stopp, & Daniels                                          [Page 1]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

1. Introduction

   This document defines a specific set of tests that vendors can use to
   measure  and  report  the  performance characteristics and forwarding
   capabilities of network devices that support IP multicast  protocols.
   The results of these tests will provide the user comparable data from
   different vendors with which to evaluate these devices.

   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.

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.

3. Test set up

   Figure 1 shows a typical setup for an IP  multicast  test,  with  one
   source  to  multiple  destinations,  although this MAY be extended to
   multiple source to multiple destinations.

                                                   +----------------+
                           +------------+          |                |
        +--------+         |            |--------->| destination(1) |
        |        |         |            |          |                |
        | source |-------->|            |          +----------------+
        |        |         |            |          +----------------+
        +--------+         |   D U T    |--------->|                |
                           |            |          | destination(2) |
                           |            |          |                |
                           |            |          +----------------+
                           |            |               . . .
                           |            |          +----------------+
                           |            |          |                |
                           |            |--------->| destination(n) |
                           |            |          |                |
                           |            |          +----------------+
                           |            |
                           +------------+
                               Figure 1

Soor, Stopp, & Daniels                                          [Page 2]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

   Generally , the destination ports first join the desired number of
   multicast groups by sending IGMP Join Group messages to the DUT.
   To verify that all destination ports successfully joined the
   appropriate groups, the source port MUST transmit IP multicast
   frames destined for these groups.

   In addition, all transmitted frames MUST contain a recognizable
   pattern that can be filtered on in order to ensure the receipt of
only
   the frames that are involved in the test.

3.1  Test Considerations

3.1.1 IGMP Support

   Each of the receiving ports should support and be able to test both
IGMP
      version 1 and IGMP version 2.

   Each receiving port should be able to respond to IGMP queries during
the test.

   Each receiving port should also send LEAVE (running IGMP version 2)
after each test.

3.1.2  Group Addresses

   The Class D Group address should be changed between tests.  Many
   DUTs have memory or cache that is not cleared properly and can
   bias the results.

3.1.3  Frame Sizes

   Each test should be run with different Multicast Frame Sizes.   The
result to vary greatly.

3.1.4  TTL

   The source frames should have a TTL value large enough to accommodate
the DUT/SUT.

4. Forwarding and Throughput

   This section contains the description of the tests that are related
to the
   characterization of the packet 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

   Definition
      The maximum rate at which none of the offered frames, comprised
from a
      unicast Class and a multicast Class, to be forwarded are dropped
by the

Soor, Stopp, & Daniels                                          [Page 3]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

      device across a fixed number of ports.

   Procedure

      Multicast and unicast traffic are mixed together in the same
aggregated
      traffic stream in order to simulate the non-homogenous networking
      environment. While the multicast traffic is transmitted from one
source to
      multiple destinations, the unicast traffic MAY be evenly
distributed across
      the DUT  architecture.  In addition, the DUT SHOULD 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
address
      table.

      The rates at which traffic is transmitted for both traffic classes
MUST be
      set up in one of two ways:

      a) A percentage of the bandwidth is allocated for each traffic
class and
         frames for each class are transmitted at the rate equal to the
allocated
         bandwidth. For example, 64 byte frames can be transmitted at a
theoretical
         maximum rate of 148810 frames/second. If 80 percent of the
bandwidth is
         allocated for unicast traffic and 20 percent for multicast
traffic, then
         unicast traffic will be sent at a maximum rate of 119048
frames/second and
         the multicast traffic at a rate of 29762 frames/second.

      b) Transmission rate is fixed for both traffic classes and a
percentage of
         number of frames for each traffic class is specified. For
example, if a
         fixed rate of 100% of theoretical maximum is desired, then 64
byte frames
         will be sent at 148810 frames/second for both unicast and
multicast
         traffic. If 80 percent of the frames are to be unicast and 20
percent
         multicast, then for a duration of 10 seconds, 1190480 frames of
unicast
         and 297620 frames of multicast will be sent. This fixed rate
scenario
         actually over-subscribes the bandwidth, potentially causing
congestion in
         the DUT.

      The transmission of the frames MUST be set up so that they form a
      deterministic distribution while still maintaining the specified
bandwidth
      and transmission rates. See Appendix A for a discussion on
determining an
      even distribution.

      Similar to the Frame loss rate test in RFC 1944, the first trial
SHOULD be
      Run for the frame rate that corresponds to 100% of the maximum
rate for the
      frame size on the input media. Repeat the procedure for the rate
that
      corresponds to 90% of the maximum rate used and then for 80% of
this rate.
      This sequence HOULD be continued (at reducing 10% intervals) until
there are
      two successive trials in which no frames are lost. The maximum
granularity of
      the trials MUST be 10% of the maximum rate, a finer granularity is
      encouraged.

Soor, Stopp, & Daniels                                          [Page 4]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

   Result

      Transmit and Receive rates in frames per second for each source
and
      destination port for both unicast and multicast traffic for each
trial
      percent transmit rate. The result report SHOULD contain the number
of
      frames transmitted and received per port per class type (unicast
and
      multicast traffic), reported in number of frames and percent loss
per port.

   4.2 Scaled Group Forwarding Matrix

   Definition:

       A table that demonstrates Forwarding Rate as a function of tested
       multicast groups for a fixed number of tested DUT/SUT ports.

   Procedure:

      Multicast traffic is sent at a fixed percent of line rate with a
fixed
      number of receive ports at a fixed frame length.

      The receive ports will join an initial number of groups and the
sender
      will transmit to the same groups after a certain delay (a few
seconds).

      Then the receive ports will join an incremental value of groups
and the
      transmit port will send to all groups joined (initial plus
incremental).

      The receive ports will continue joining in the incremental fashion
until a
      user defined maximum is reached.

   Results:

      For each group load the result WILL display frame rate, frames
transmitted,
      total frames received, total frames loss, and percent loss.  The
frame loss
      per receive port per group SHOULD also be available.

   4.3 Aggregated Multicast Throughput

   Definition:

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

   Procedure:

      Multicast traffic is sent at a fixed percent of line rate with a
fixed
      number of groups at a fixed frame length for a fixed duration of
time.

Soor, Stopp, & Daniels                                          [Page 5]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

      The initial number of receive ports will join the group(s) and the
      sender will transmit to the same groups after a certain delay (a
few
      seconds).

      Then the an incremental number of receive ports will join the same
groups
      and then the Multicast traffic is sent as stated.

      The receive ports will continue to be added and the Multicast
traffic sent
      until a user defined maximum number of ports is reached.

   Results:

      For each number of receive ports the result WILL display frame
rate, frames
      transmitted, total frames received, total frames loss, and percent
loss.
      The frame loss per receive port per group SHOULD also be
available.

4.4 Encapsulation (Tunneling) Throughput

   This sub-section provides the description of tests that help in
obtaining
   throughput measurements when a DUT or a set of DUTs are acting as
tunnel
   endpoints. The following Figure 2 presents the scenario for the
tests.

      Client A        DUT A         Network            DUT B       
Client B

                     ----------                   ----------
                     |        |      ------       |        |
      -------(a)  (b)|        |(c)  (      )   (d)|        |(e)
(f)-------
      ||||||| -----> |        |---->(      )----->|        |----->
|||||||
      -------        |        |      ------       |        |      
-------
                     |        |                   |        |
                     ----------                   ----------

                                   Figure 2
                                   --------

   A tunnel is created between DUT A (the encapsulator) and DUT B (the
   decapsulator). Client A is acting as a source and Client B is the
   destination. Client B joins a multicast group (for example,
224.0.1.1) and it
   sends an IGMP Join message to DUT B to join that group. Client A now
wants to
   transmit some traffic to Client B. It will send the multicast traffic
to DUT
   A which encapsulates the multicast frames, sends it to DUT B which
will
   decapsulate the same frames and forward them to Client B.

4.4.1 Encapsulation Throughput

Soor, Stopp, & Daniels                                          [Page 6]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

Definition

   The maximum rate at which frames offered a DUT are encapsulated and
correctly
   forwarded by the DUT without loss.

Procedure

   To test the forwarding rate of the DUT when it has to go through the
process
   of encapsulation, a test port B is injected at the other end of DUT A
   (Figure B) that will receive the encapsulated frames and measure the
   throughput. Also, a test port A is used to generate multicast frames
that
   will be passed through the tunnel.

   The following is the test setup:

      Test port A      DUT A                  Test port B

                     ---------- (c')      (d')---------
                     |        |-------------->|       |
      -------(a)  (b)|        |               |       |
      ||||||| -----> |        |      ------   ---------
      -------        |        |(c)  ( N/W  )
                     |        |---->(      )
                     ----------      ------

                                   Figure 3
                                   --------

   In Figure 2, a tunnel is created with the local IP address of DUT A
as the
   beginning of the tunnel (point c) and the IP address of DUT B as the
end
   of the tunnel (point d). DUT B is assumed to have the tunneling
protocol
   enabled so that the frames can be decapsulated. When the test port B
is
   inserted in between the DUT A and DUT B (Figure 3), the endpoint of
tunnel
   has to be re-configured to be directed to the test port B's IP
address. For
   example, in Figure 3, point c' would be  assigned as the beginning of
the
   tunnel and point d' as the end of the tunnel. The test port B is
acting as
   the end of the tunnel, and it does not have to support any tunneling
protocol
   since the frames do not have to be decapsulated. Instead, the
received
   encapsulated frames are used to calculate the throughput and other
necessary
   measurements.

Result

   Throughput in frames per second for each destination port. The
results
   should also contain the number of frames transmitted and received per
port.

   4.4.2 Decapsulation Throughput

Soor, Stopp, & Daniels                                          [Page 7]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

   Definition
      The maximum rate at which frames offered a DUT are decapsulated
and correctly
      forwarded by the DUT without loss.

   Procedure

      The decapsulation process returns the tunneled unicast frames back
to their
      multicast format. This test measures the throughput of the DUT
when it has to
      perform the process of decapsulation, therefore, a test port C is
used at the
      end of the tunnel to receive the decapsulated frames (Figure 4).

      Test port A       DUT A       Test port B     DUT B        Test
port C

                     ----------                   ----------
                     |        |                   |        |
      -------(a)  (b)|        |(c)   ------    (d)|        |(e)
(f)-------
      ||||||| -----> |        |----> |||||| ----->|        |----->
|||||||
      -------        |        |      ------       |        |      
-------
                     |        |                   |        |
                     ----------                   ----------

                                   Figure 4
                                   --------

      In Figure 4, the encapsulation process takes place in DUT A. This
may
      effect the throughput of the DUT B. Therefore, two test ports
should be
      used to separate the encapsulation and decapsulation processes.
Client A
      is replaced with the test port A which will generate a multicast
frame that
      will be encapsulated by DUT A. Another test port B is inserted
between DUT
      A and DUT B that will receive the encapsulated frames and forward
it to DUT
      B. Test port C will receive the decapsulated frames and measure
the
      throughput.

   Result

      Throughput in frames per second for each destination port . The
results
      should also contain the number of frames transmitted and received
per port.

   4.4.3 Re-encapsulation Throughput

   Definition

      The maximum rate at which frames of one encapsulated format
offered a DUT are
      converted to another encapsulated format and correctly forwarded
by the DUT
      without loss.

   Procedure

Soor, Stopp, & Daniels                                          [Page 8]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

      Re-encapsulation takes place in DUT B after test port C has
received the
      decapsulated frames. These decapsulated frames will be re-inserted
with
      a new encapsulation frame and sent to test port B which will
measure the
      throughput. See Figure 5.

     Test port A       DUT A       Test port B     DUT B        Test
port C

                     ----------                   ----------
                     |        |                   |        |
      -------(a)  (b)|        |(c)   ------    (d)|        |(e)
(f)-------
      ||||||| -----> |        |----> |||||| <---->|        |<---->
|||||||
      -------        |        |      ------       |        |      
-------
                     |        |                   |        |
                     ----------                   ----------

                                   Figure 5
                                   --------

   Result

      Throughput in frames per second for each destination port. The
results
      should also contain the number of frames transmitted and received
per port.

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

   5.1 Multicast Latency

   Definition

      The set of individual latencies from a single input port on the
DUT or SUT to
      all tested ports belonging to the destination multicast group.

   Procedure

      According to RFC 1944, a tagged frame is sent half way through the
      transmission that contains a timestamp used for calculation of
latency. In
      the multicast situation, a tagged frame is sent to all
destinations for each
      multicast group and latency calculated on a per multicast group
basis. Note
      that this test MUST be run using the transmission rate that is
less than the
      multicast throughput of the DUT.

   Result
      The latency value for each multicast group address.

Soor, Stopp, & Daniels                                          [Page 9]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

   5.2 Min/Max/Average Multicast Latency

   Definition:

      The difference between the maximum latency measurement and the
      minimum latency measurement from the set of latencies produced by
      the Multicast Latency benchmark.

   Procedure:

      For the entire duration of the Latency test the smallest latency,
the
      largest latency, the sum of latencies, and the number should be
tracked
      per receive port.

      The test can also increment bucket counters that represent a range
latency
      range.  This can be used to create a histogram.  From the
histogram, minimum,
      maximum, and average the test results can show the jitter.

   Results:

      For each port the results WILL display the number of frames,
minimum latency,
      maximum latency, and the average latency.  The results SHOULD also
display
      the histogram of latencies.

   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

   Definition:

      The time duration it takes a DUT to start forwarding multicast
      packets from the time a successful IGMP group membership report
      has been issued to the DUT.

   Procedure:

      Traffic is sent on the source port at the same time as the IGMP
JOIN Group
      message is transmitted from the destination ports.  The join delay
is the
      difference in time from when the IGMP Join is sent and the first
frame is
      received.

      One of the keys is to transmit at the fastest rate the DUT can
handle multicast
      frames.  This is to get the best resultion in the Join Delay. 
However, you

Soor, Stopp, & Daniels                                         [Page 10]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

      do not want to transmit the frames to fast that frames are dropped
by the DUT.

      The test should be ran using both IGMPv1 JOIN and IGMPv2 JOIN.

   Results:

      The JOIN delay for each port.

   6.2 Group Leave Delay

   Definition
      The time duration it takes a DUT to cease forwarding multicast
packets after
      a corresponding IGMP "Leave Group" message has been successfully
offered to
      the DUT.

   Procedure

      Traffic is sent on the source port at the same time as the IGMP
Leave Group
      messages are transmitted from the destination ports. The frames on
both the
      source and destination ports are sent with the timestamps
inserted. The Group
      Leave Delay is the difference in the value of the timestamp A of
the first
      IGMP Leave Group frame sent and the timestamp B of the last frame
that is
      received on that destination port.

                      Group Leave delay = timestamp B - timestamp A

   Result

      Group Leave Delay values for each multicast group address on each
destination
      port. Also, the number of frames transmitted and received, and
percent loss
      may be displayed.

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

8.1 Multicast Group Capacity

Definition:

   The maximum number of multicast groups a SUT/DUT can support while
   maintaining the ability to forward multicast frames to all
   multicast groups registered to that SUT/DUT.

Procedure:

      One or more receiving ports will join an initial number of
groups.  Then

Soor, Stopp, & Daniels                                         [Page 11]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

      after a delay the source port will transmit to each group at a
transmission
      rate that the DUT can handle.   If all frames sent are forwarded
and received
      the receiving ports will join an incremental value of groups. 
Then after a
      a delay the source port will transmit to all groups at a
transmission rate
      that the DUT can handle.  If all frames sent are forwarded and
received the
      receiving ports will continuing joining and testing until a frame
is not forwarded
      nor received.

      The group capacity resolution will be the incremental value.  So
the capacity
      could be greater then last capacity passed but less then the one
that failed.

      Once a capacity is determined the test should be re run with
greater delays after
      the JOIN and a slower transmission rate.  And the initial group
level should be
      raised to about five less then the previous capacity and
incremental value should
      be set to one.

   Results:

      The number of groups passed vs the number of groups failed.  The
results SHOULD
      give details when the frame fails to be forwarded about how many
frames did and
      did not get forwarded.  Which groups DID and DID NOT get
forwarded.

   9. Burdened Response

   9.1 Burdened Response

   Definition:

      A measured response collected from a DUT/SUT in light of
      interacting, or potentially interacting, distinct stimuli.

   Procedure:

      TBD

   Results:

      TBD

   9.2 Forwarding Burdened Multicast Latency

   Definition
      A multicast latency taken from a DUT/SUT in the presence of a
traffic
      forwarding requirement.

   Procedure

Soor, Stopp, & Daniels                                         [Page 12]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

     This test build upon the Multicast Latency as described in 1.5.1.
This test
     measures latencies for a set of offered load values and reports the
forwarding
     rates.

   Result
      A table of offered load (percent of maximum rate), forwarding
rates and
      latencies for each multicast group involved.

   9.3 Forwarding Burdened Join Delay

   Definition:

      A multicast Group Join Delay taken from a DUT in the presence of a
      traffic forwarding requirement.

   Procedure:

      TBD

   Results:

      TBD

   Appendix A: Determining an even distribution

   A.1 Scope Of This Appendix

      This appendix discusses the suggested approach to configuring
the   deterministic distribution methodology for tests that involve both
multicast and unicast traffic classes in an aggregated traffic stream.
As such, this appendix MUST not be read as an amendment to the
methodology described in the body of this document but as a guide to
testing practice.

      It is important to understand and fully define the distribution of
frames among all multicast and unicast destinations.  If the
distribution is not well defined or understood, the throughput and
forwarding metrics are not meaningful.

   In a homogeneous environment, a large, single burst of multicast
frames may be followed by a large burst of unicast frames. This is a
very different distribution than that of a non-homogeneous environment,
where the multicast and unicast frames are intermingled throughout the
entire transmission.

   The recommended distribution is that of the non-homogeneous
environment because it more closely represents a real-world scenario.
The distribution is modeled by calculating the number of multicast
frames per destination port as a burst, then calculating the number of
unicast frames to transmit as a percentage of the total frames
transmitted. The overall effect of the distribution is small bursts of
multicast frames intermingled with small bursts of unicast frames.

   Example

      Frame size = 64
      Duration of test = 10 seconds
      Transmission rate = 100% of maximum rate
      Mapping for unicast traffic:    Port 1 to Port 2
                                      Port 3 to port 4
      Mapping for multicast traffic:  Port 1 to Ports 2,3,4
      Number of Multicast group addresses per destination port = 3
      Multicast groups joined by Port 2: 224.0.1.1
                                         224.0.1.2

Soor, Stopp, & Daniels                                         [Page 13]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

                                         224,0.1.3
      Multicast groups joined by Port 3: 224.0.1.4
                                         224.0.1.5
                                         224,0.1.6
      Multicast groups joined by Port 4: 224.0.1.7
                                         224.0.1.8
                                         224,0.1.9

      Percentage of Unicast frames = 20
      Percentage of Multicast frames = 80
      Total number of frames to be transmitted = 148810 fps * 10 sec
                                               = 1488100 frames
      Number of unicast frames = 20/100 * 1488100 = 297620 frames
      Number of multicast frames = 80/100 * 1488100 = 1190480 frames

      Unicast burst size = 20 * 9 = 180
      Multicast burst size = 80 * 9 = 720
      Loop counter = 1488100 / 900 = 1653.4444 (round it off to 1653)

      Therefore, the actual number of frames that will be transmitted:
        Unicast frames = 1653 * 180 = 297540 frames
        Multicast frames = 1653 * 720 = 1190160 frames

      The following pattern will be established:

      UUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMM

      where     U represents 60 Unicast frames (UUU = 180 frames)
                M represents 60 Multicast frames (MMMMMMMMMMMM = 720
frames)

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

5. 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 1944, May 1996.

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

Soor, Stopp, & Daniels                                         [Page 14]

INTERNET-DRAFT   IP Multicast Benchmarking Methodology     February 1999

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

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

6. Author's Address

   Hardev Soor
   Ixia Communications
   4505 Las Virgenes Road, Suite 209
   Calabasas, CA  91302
   USA

   Phone: 818 871 1800
   EMail: [email-masked]

   Debra Stopp
   Ixia Communications
   4505 Las Virgenes Road, Suite 209
   Calabasas, CA  91302
   USA

   Phone: 818 871 1800
   EMail: [email-masked]

   Ralph Daniels
   Netcom Systems
   948 Loop Road
   Clayton, NC 27520
   USA

   Phone: 919 550 9475
   EMail: [email-masked]

Soor, Stopp, & Daniels                                         [Page 15]