draft-ietf-bmwg-mcastm-06.txt   draft-ietf-bmwg-mcastm-07.txt 
Network Working Group Hardev Soor Network Working Group Debra Stopp
INTERNET-DRAFT Debra Stopp Hardev Soor
Expires in: April 2001 IXIA INTERNET-DRAFT IXIA
Expires in: August 2001
Ralph Daniels
Netcom Systems
October 2000
Methodology for IP Multicast Benchmarking Methodology for IP Multicast Benchmarking
<draft-ietf-bmwg-mcastm-06.txt> <draft-ietf-bmwg-mcastm-07.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance
all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet
Task Force (IETF), its areas, and its working groups. Note that Engineering Task Force (IETF), its areas, and its working
other groups may also distribute working documents as Internet- groups. Note that other groups may also distribute working
Drafts. documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet- Drafts as reference documents at any time. It is inappropriate to use Internet-
material or to cite them other than as "work in progress." Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed
http://www.ietf.org/ietf/1id-abstracts.txt at http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed
http://www.ietf.org/shadow.html. at http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The purpose of this draft is to describe methodology specific to the The purpose of this draft is to describe methodology specific to
benchmarking of multicast IP forwarding devices. It builds upon the the benchmarking of multicast IP forwarding devices. It builds
tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking upon the tenets set forth in RFC 2544, RFC 2432 and other IETF
Methodology Working Group (BMWG) efforts. This document seeks to Benchmarking Methodology Working Group (BMWG) efforts. This
extend these efforts to the multicast paradigm. document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: Benchmarking The BMWG produces two major classes of documents:
Terminology documents and Benchmarking Methodology documents. The Benchmarking Terminology documents and Benchmarking Methodology
Terminology documents present the benchmarks and other related terms. documents. The Terminology documents present the benchmarks and
The Methodology documents define the procedures required to collect other related terms. The Methodology documents define the
the benchmarks cited in the corresponding Terminology documents. procedures required to collect the benchmarks cited in the
corresponding Terminology documents.
1 Introduction Table of Contents
This document defines a specific set of tests that vendors can use to 1. INTRODUCTION...................................................3
measure and report the performance characteristics and forwarding
capabilities of network devices that support IP multicast protocols. 2. KEY WORDS TO REFLECT REQUIREMENTS..............................3
The results of these tests will provide the user comparable data from
different vendors with which to evaluate these devices. 3. TEST SET UP....................................................3
3.1. Test Considerations..........................................4
3.1.1. IGMP Support..............................................4
3.1.2. Group Addresses...........................................5
3.1.3. Frame Sizes...............................................5
3.1.4. TTL.......................................................5
3.2. Layer 2 Support..............................................5
4. FORWARDING AND THROUGHPUT......................................5
4.1. Mixed Class Throughput.......................................6
4.2. Scaled Group Forwarding Matrix...............................7
4.3. Aggregated Multicast Throughput..............................7
4.4. Encapsulation/Decapsulation (Tunneling) Throughput...........8
4.4.1. Encapsulation Throughput..................................9
4.4.2. Decapsulation Throughput..................................9
4.4.3. Re-encapsulation Throughput..............................10
5. FORWARDING LATENCY............................................10
5.1. Multicast Latency...........................................11
5.2. Min/Max Multicast Latency...................................13
6. OVERHEAD......................................................14
6.1. Group Join Delay............................................14
6.2. Group Leave Delay...........................................15
7. CAPACITY......................................................16
7.1. Multicast Group Capacity....................................16
8. INTERACTION...................................................16
8.1. Forwarding Burdened Multicast Latency.......................17
8.2. Forwarding Burdened Group Join Delay........................17
9. SECURITY CONSIDERATIONS.......................................17
10. ACKNOWLEDGEMENTS.............................................17
11. REFERENCES...................................................18
12. AUTHOR'S ADDRESSES...........................................19
13. FULL COPYRIGHT STATEMENT.....................................19
APPENDIX A: DETERMINING AN EVEN DISTRIBUTION.....................20
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" A previous document, " Terminology for IP Multicast Benchmarking"
(RFC 2432), defined many of the terms that are used in this document. (RFC 2432), defined many of the terms that are used in this
The terminology document should be consulted before attempting to document. The terminology document should be consulted before
make use of this document. attempting to make use of this document.
This methodology will focus on one source to many destinations, This methodology will focus on one source to many destinations,
although many of the tests described may be extended to use multiple although many of the tests described may be extended to use
source to multiple destination IP multicast communication. multiple source to multiple destination IP multicast communication.
2 Key Words to Reflect Requirements 2. Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
document are to be interpreted as described in RFC 2119. in this document are to be interpreted as described in RFC 2119.
3 Test set up 3. Test set up
Figure 1 shows a typical setup for an IP multicast test, with one Figure 1 shows a typical setup for an IP multicast test, with one
source to multiple destinations, although this MAY be extended to source to multiple destinations, although this MAY be extended to
multiple source to multiple destinations. multiple source to multiple destinations.
+----------------+ +----------------+
+------------+ | | +------------+ | Egress |
+--------+ | |--------->| destination(1) | +--------+ | (-)-------->| destination(E1)|
| | | | | | | | | | | |
| source |-------->| | +----------------+ | source |------->(|)Ingress | +----------------+
| | | | +----------------+ | | | | +----------------+
+--------+ | D U T |--------->| | +--------+ | D U T (-)-------->| Egress |
| | | destination(2) | | | | destination(E2)|
| | | | | | | |
| | +----------------+ | | +----------------+
| | . . . | | . . .
| | +----------------+ | | +----------------+
| | | Egress |
| (-)-------->| destination(En)|
| | | | | | | |
| |--------->| destination(n) | +------------+ +----------------+
| | | |
| | +----------------+
| |
+------------+
Figure 1 Figure 1
---------
If the multicast metrics are to be taken across multiple devices
forming a System Under Test (SUT), then test packets are offered to
a single ingress interface on a device of the SUT, subsequently
routed across the SUT topology, and finally forwarded to the test
apparatus' packet-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 MUST be disclosed with the corresponding test results.
+--------+ +----------------+ +--------+
| | +------------+ |DUT B Egress E0(-)-->| |
| | |DUT A |--->| | | |
| Test | | | | Egress E1(-)-->| Test |
| App. |--->(-)Ingress, I | +----------------+ | App. |
| Traffic| | | +----------------+ | Traffic|
| Src. | | |--->|DUT C Egress E2(-)-->| Dest. |
| | +------------+ | | | |
| | | Egress En(-)-->| |
+--------+ +----------------+ +--------+
Figure 2
---------
Generally , the destination ports first join the desired number of Generally , the destination ports first join the desired number of
multicast groups by sending IGMP Join Group messages to the DUT/SUT. multicast groups by sending IGMP Join Group messages to the
To verify that all destination ports successfully joined the DUT/SUT. To verify that all destination ports successfully joined
appropriate groups, the source port MUST transmit IP multicast frames the appropriate groups, the source port MUST transmit IP multicast
destined for these groups. The destination ports MAY send IGMP Leave frames destined for these groups. The destination ports MAY send
Group messages after the transmission of IP Multicast frames to clear IGMP Leave Group messages after the transmission of IP Multicast
the IGMP table of the DUT/SUT. frames to clear the IGMP table of the DUT/SUT.
In addition, all transmitted frames MUST contain a recognizable In addition, all transmitted frames MUST contain a recognizable
pattern that can be filtered on in order to ensure the receipt of pattern that can be filtered on in order to ensure the receipt of
only the frames that are involved in the test. only the frames that are involved in the test.
3.1 Test Considerations 3.1. Test Considerations
3.2 IGMP Support 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. Moreover, no provisions are
made for traffic-affecting factors, such as congestion control or
service differentiation mechanisms. 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.
Each of the destination ports should support and be able to test all 3.1.1. IGMP Support
IGMP versions 1, 2 and 3. The minimum requirement, however, is IGMP
version 2. Each of the destination ports should support and be able to test
all IGMP versions 1, 2 and 3. The minimum requirement, however, is
IGMP version 2.
Each destination port should be able to respond to IGMP queries Each destination port should be able to respond to IGMP queries
during the test. during the test.
Each destination port should also send LEAVE (running IGMP version 2) Each destination port should also send LEAVE (running IGMP version
after each test. 2) after each test.
3.3 Group Addresses 3.1.2. Group Addresses
The Class D Group address SHOULD be changed between tests. Many DUTs The Class D Group address SHOULD be changed between tests. Many
have memory or cache that is not cleared properly and can bias the DUTs have memory or cache that is not cleared properly and can bias
results. the results.
The following group addresses are recommended by use in a test: The following group addresses are recommended by use in a test:
224.0.1.27-224.0.1.255 224.0.1.27-224.0.1.255
224.0.5.128-224.0.5.255 224.0.5.128-224.0.5.255
224.0.6.128-224.0.6.255 224.0.6.128-224.0.6.255
If the number of group addresses accommodated by these ranges do not If the number of group addresses accommodated by these ranges do
satisfy the requirements of the test, then these ranges may be not satisfy the requirements of the test, then these ranges may be
overlapped. The total number of configured group addresses must be overlapped. The total number of configured group addresses must be
less than or equal to the IGMP table size of the DUT/SUT. less than or equal to the IGMP table size of the DUT/SUT.
3.4 Frame Sizes 3.1.3. Frame Sizes
Each test SHOULD be run with different Multicast Frame Sizes. The Each test SHOULD be run with different Multicast Frame Sizes. The
recommended frame sizes are 64, 128, 256, 512, 1024, 1280, and 1518 recommended frame sizes are 64, 128, 256, 512, 1024, 1280, and 1518
byte frames. byte frames.
3.5 TTL 3.1.4. TTL
The source frames should have a TTL value large enough to accommodate
the DUT/SUT.
3.6 Layer 2 Support The source frames should have a TTL value large enough to
accommodate the DUT/SUT.
3.2. Layer 2 Support
Each of the destination ports should support GARP/GMRP protocols to Each of the destination ports should support GARP/GMRP protocols to
join groups on Layer 2 DUTs/SUTs. join groups on Layer 2 DUTs/SUTs.
4 Forwarding and Throughput 4. Forwarding and Throughput
This section contains the description of the tests that are related This section contains the description of the tests that are related
to the characterization of the packet forwarding of a DUT/SUT in a to the characterization of the packet forwarding of a DUT/SUT in a
multicast environment. Some metrics extend the concept of throughput multicast environment. Some metrics extend the concept of throughput
presented in RFC 1242. The notion of Forwarding Rate is cited in RFC presented in RFC 1242. The notion of Forwarding Rate is cited in RFC
2285. 2285.
4.1 Mixed Class Throughput 4.1. Mixed Class Throughput
Objective Objective
To determine the maximum throughput rate at which none of the offered To determine the maximum throughput rate at which none of the
frames, comprised from a unicast Class and a multicast Class, to be offered frames, comprised from a unicast Class and a multicast
forwarded are dropped by the device across a fixed number of ports as Class, to be forwarded are dropped by the device across a fixed
defined in RFC 2432. number of ports as defined in RFC 2432.
Procedure Procedure
Multicast and unicast traffic are mixed together in the same Multicast and unicast traffic are mixed together in the same
aggregated traffic stream in order to simulate the non-homogenous aggregated traffic stream in order to simulate the non-homogenous
networking environment. While the multicast traffic is transmitted networking environment. While the multicast traffic is transmitted
from one source to multiple destinations, the unicast traffic MAY be from one source to multiple destinations, the unicast traffic MAY
evenly distributed across the DUT/SUT architecture. In addition, the be evenly distributed across the DUT/SUT architecture. In addition,
DUT/SUT SHOULD learn the appropriate unicast IP addresses, either by the DUT/SUT MUST learn the appropriate unicast IP addresses, either
sending ARP frames from each unicast address, sending a RIP packet or by sending ARP frames from each unicast address, sending a RIP
by assigning static entries into the DUT/SUT address table. packet or by assigning static entries into the DUT/SUT address
table.
The mixture of multicast and unicast traffic MUST be set up in one of The mixture of multicast and unicast traffic MUST be set up in one
two ways: of two ways:
a) As a percentage of the total traffic flow employing maximum a) As a percentage of the total traffic flow employing maximum
bandwidth utilization. Thus, each type of traffic is bandwidth utilization. Thus, each type of traffic is
transmitted at the maximum available bandwidth. This also transmitted at the maximum available bandwidth. This also
implies that the offered load, regardless of the type of implies that the intended load, regardless of the type of
traffic, remains constant. traffic, remains constant.
b) As a percentage of the total traffic flow employing a b) As a percentage of the total traffic flow employing a
proportionate bandwidth utilization. Thus, each type of proportionate bandwidth utilization. Thus, each type of
traffic is transmitted at a fraction of the available traffic is transmitted at a fraction of the available
bandwidth proportional to the specified ratio. This also bandwidth proportional to the specified ratio. This also
implies that the offered load for each traffic type varies in implies that the intended load for each traffic type varies in
proportion to its specified ratio. proportion to its specified ratio.
The transmission of the frames MUST be set up so that they form a The transmission of the frames MUST be set up so that they form a
deterministic distribution while still maintaining the specified deterministic distribution while still maintaining the specified
forwarding rates. See Appendix A for a discussion on non-homogenous forwarding rates. See Appendix A for a discussion on non-homogenous
vs. homogenous packet distribution. vs. homogenous packet distribution.
Similar to the Frame loss rate test in RFC 2544, the first trial Similar to the Frame loss rate test in RFC 2544, the first trial
SHOULD be run for the frame rate that corresponds to 100% of the 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 maximum rate for the frame size on the input media. Repeat the
procedure for the rate that corresponds to 90% of the maximum rate procedure for the rate that corresponds to 90% of the maximum rate
used and then for 80% of this rate. This sequence SHOULD be continued used and then for 80% of this rate. This sequence SHOULD be
(at reducing 10% intervals) until there are two successive trials in continued (at reducing 10% intervals) until there are two
which no frames are lost. The maximum granularity of the trials MUST successive trials in which no frames are lost. The maximum
be 10% of the maximum rate, a finer granularity is encouraged. granularity of the trials MUST be 10% of the maximum rate, a finer
granularity is encouraged.
Result Result
Parameters to be measured SHOULD include the frame loss and percent Parameters to be measured SHOULD include the frame loss and percent
loss for each class of traffic per destination port. The ratio of loss for each class of traffic per destination port. The ratio of
unicast traffic to multicast traffic MUST be reported. unicast traffic to multicast traffic MUST be reported.
In addition, the transmit and receive rates in frames per second for The nature of the traffic stream contributing to the result MUST be
each source and destination port for both unicast and multicast reported. All required reporting parameters of mixed class
traffic, together with the number of frames transmitted and received throughput MUST be reflected in the results report, such as the
per port per class type traffic SHOULD be reported. transmitted packet size(s) and offered load of the packet stream.
4.2 Scaled Group Forwarding Matrix 4.2. Scaled Group Forwarding Matrix
Definition Objective
A table that demonstrates Forwarding Rate as a function of tested A table that demonstrates Forwarding Rate as a function of tested
multicast groups for a fixed number of tested DUT/SUT ports. multicast groups for a fixed number of tested DUT/SUT ports.
Procedure Procedure
Multicast traffic is sent at a fixed percent of maximum offered load Multicast traffic is sent at a fixed percent of maximum offered
with a fixed number of receive ports of the tester at a fixed frame load with a fixed number of receive ports of the tester at a fixed
length. frame length.
The receive ports SHOULD continue joining incrementally by 10 The receive ports SHOULD continue joining incrementally by 10
multicast groups until a user defined maximum is reached. multicast groups until a user defined maximum is reached.
The receive ports will continue joining in the incremental fashion The receive ports will continue joining in the incremental fashion
until a user defined maximum is reached. until a user defined maximum is reached.
Results Results
Parameters to be measured SHOULD include the frame loss and percent Parameters to be measured SHOULD include the frame loss and percent
loss per destination port for each multicast group address. loss per destination port for each multicast group address.
In addition, the transmit and receive rates in frames per second for The nature of the traffic stream contributing to the result MUST be
each source and destination port for all multicast groups, together reported. All required reporting parameters MUST be reflected in
with the number of frames transmitted and received per port per the results report, such as the transmitted packet size(s) and
multicast groups SHOULD be reported. offered load of the packet stream.
4.3 Aggregated Multicast Throughput 4.3. Aggregated Multicast Throughput
Definition Objective
The maximum rate at which none of the offered frames to be forwarded The maximum rate at which none of the offered frames to be
through N destination interfaces of the same multicast group are forwarded through N destination interfaces of the same multicast
dropped. group are dropped.
Procedure Procedure
Multicast traffic is sent at a fixed percent of maximum offered load Multicast traffic is sent at a fixed percent of maximum offered
with a fixed number of groups at a fixed frame length for a fixed load with a fixed number of groups at a fixed frame length for a
duration of time. fixed duration of time.
The initial number of receive ports of the tester will join the The initial number of receive ports of the tester will join the
group(s) and the sender will transmit to the same groups after a group(s) and the sender will transmit to the same groups after a
certain delay (a few seconds). certain delay (a few seconds).
Then the an incremental number of receive ports will join the same Then the an incremental number of receive ports will join the same
groups and then the Multicast traffic is sent as stated. groups and then the Multicast traffic is sent as stated.
The receive ports will continue to be added and multicast traffic The receive ports will continue to be added and multicast traffic
sent until a user defined maximum number of ports is reached. sent until a user defined maximum number of ports is reached.
Results Results
Parameters to be measured SHOULD include the frame loss and percent Parameters to be measured SHOULD include the frame loss and percent
loss per destination port for each multicast group address. loss per destination port for each multicast group address.
In addition, the transmit and receive rates in frames per second for The nature of the traffic stream contributing to the result MUST be
each source and destination port for all multicast groups, together reported. All required reporting parameters of aggregated
with the number of frames transmitted and received per port per throughput MUST be reflected in the results report, such as the
multicast groups SHOULD be reported. transmitted packet size(s) and offered load of the packet stream.
4.4 Encapsulation (Tunneling) Throughput 4.4. Encapsulation/Decapsulation (Tunneling) Throughput
This sub-section provides the description of tests that help in This sub-section provides the description of tests that help in
obtaining throughput measurements when a DUT/SUT or a set of DUTs are obtaining throughput measurements when a DUT/SUT or a set of DUTs
acting as tunnel endpoints. The following Figure 2 presents the are acting as tunnel endpoints. The following Figure 3 presents the
scenario for the tests. a tunneled network.
Client A DUT/SUT A Network DUT/SUT B Client B Client A DUT/SUT A Network DUT/SUT B Client B
---------- ---------- ---------- ----------
| | ------ | | | | ------ | |
-----(a) (b)| |(c) ( ) (d)| |(e) (f)----- -----(a) (b)| |(c) ( ) (d)| |(e) (f)-----
||||| -----> | |---->( )----->| |-----> ||||| ||||| -----> | |---->( )----->| |-----> |||||
----- | | ------ | | ----- ----- | | ------ | | -----
| | | | | | | |
---------- ---------- ---------- ----------
Figure 2 Figure 3
-------- --------
A tunnel is created between DUT/SUT A (the encapsulator) and DUT/SUT A tunnel is created between DUT/SUT A (the encapsulator) and
B (the decapsulator). Client A is acting as a source and Client B is DUT/SUT B (the decapsulator). Client A is acting as a source and
the destination. Client B joins a multicast group (for example, Client B is the destination. Client B joins a multicast group (for
224.0.1.1) and it sends an IGMP Join message to DUT/SUT B to join example, 224.0.1.1) by sending an IGMP Join message to DUT/SUT B to
that group. Client A now wants to transmit some traffic to Client B. join that group. Client A now wants to transmit some traffic to
It will send the multicast traffic to DUT/SUT A which encapsulates Client B. It will send the multicast traffic to DUT/SUT A which
the multicast frames, sends it to DUT/SUT B which will decapsulate encapsulates the multicast frames, sends it to DUT/SUT B which will
the same frames and forward them to Client B. decapsulate the same frames and forward them to Client B.
4.4.1 Encapsulation Throughput 4.4.1. Encapsulation Throughput
Definition Objective
The maximum rate at which frames offered a DUT/SUT are The maximum rate at which frames offered a DUT/SUT are encapsulated
encapsulated and correctly forwarded by the DUT/SUT without loss. and correctly forwarded by the DUT/SUT without loss.
Procedure Procedure
To test the forwarding rate of the DUT/SUT when it has to go Traffic is sent through a DUT/SUT that has been configured to
through the process of encapsulation, a test port B is injected at encapsulate the frames. Traffic is received on a test port prior to
the other end of DUT/SUT A (Figure B) that will receive the decapsulation and throughput is calculated based on RFC2544.
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: Results
Test port A DUT/SUT A Test port B Parameters to be measured SHOULD include the measured throughput
per tunnel.
---------- (c') (d')--------- The nature of the traffic stream contributing to the result MUST be
| |-------------->| | reported. All required reporting parameters of encapsulation
-------(a) (b)| | | | throughput MUST be reflected in the results report, such as the
||||||| -----> | | ------ --------- transmitted packet size(s) and offered load of the packet stream.
------- | |(c) ( N/W )
| |---->( )
---------- ------
Figure 3
--------
In Figure 2, a tunnel is created with the local IP address of 4.4.2. Decapsulation Throughput
DUT/SUT A as the beginning of the tunnel (point c) and the IP
address of DUT/SUT B as the end of the tunnel (point d). DUT/SUT 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/SUT A and DUT/SUT 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 Objective
Parameters to be measured SHOULD include the frame loss and The maximum rate at which frames offered a DUT/SUT are decapsulated
percent loss per destination port for each multicast group and correctly forwarded by the DUT/SUT without loss.
address.
In addition, the transmit and receive rates in frames per second Procedure
for each source and destination port for all multicast groups,
together with the number of frames transmitted and received per
port per multicast groups SHOULD be reported.
4.4.2 Decapsulation Throughput Encapsulated traffic is sent through a DUT/SUT that has been
configured to decapsulate the frames. Traffic is received on a test
port after decapsulation and throughput is calculated based on
RFC2544.
Definition Results
The maximum rate at which frames offered a DUT/SUT are Parameters to be measured SHOULD include the measured throughput
decapsulated and correctly forwarded by the DUT/SUT without loss. per tunnel.
The nature of the traffic stream contributing to the result MUST be
reported. All required reporting parameters of decapsulation
throughput MUST be reflected in the results report, such as the
transmitted packet size(s) and offered load of the packet stream.
4.4.3. Re-encapsulation Throughput
Objective
The maximum rate at which frames of one encapsulated format offered
a DUT/SUT are converted to another encapsulated format and
correctly forwarded by the DUT/SUT without loss.
Procedure Procedure
The decapsulation process returns the tunneled unicast frames back Traffic is sent through a DUT/SUT that has been configured to
to their multicast format. This test measures the throughput of encapsulate frames into one format, then re-encapsulate the frames
the DUT/SUT when it has to perform the process of decapsulation, into another format. Traffic is received on a test port after all
therefore, a test port C is used at the end of the tunnel to decapsulation is complete and throughput is calculated based on
receive the decapsulated frames (Figure 4). RFC2544.
Test port A DUT/SUT A Test port B DUT/SUT B Test port C Results
---------- ---------- Parameters to be measured SHOULD include the measured throughput
| | | | per tunnel.
-----(a) (b)| |(c) ---- (d)| |(e) (f)-----
||||| -----> | |----> |||| ----->| |-----> |||||
----- | | ---- | | -----
| | | |
---------- ----------
Figure 4 The nature of the traffic stream contributing to the result MUST be
-------- reported. All required reporting parameters of re-encapsulation
throughput MUST be reflected in the results report, such as the
transmitted packet size(s) and offered load of the packet stream.
In Figure 4, the encapsulation process takes place in DUT/SUT A. 5. Forwarding Latency
This may effect the throughput of the DUT/SUT 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/SUT A. Another test port B is inserted between DUT/SUT A and
DUT/SUT B that will also receive the encapsulated frames as they
are forwarded by DUT/SUT A to DUT/SUT B. Test port B may be used
to monitor the throughput of the encapsulated frames as they
traverse the tunnel. Test port C will receive the decapsulated
frames and measure the throughput.
Result 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.
Parameters to be measured SHOULD include the frame loss and In order to lessen the effect of packet buffering in the DUT/SUT,
percent loss per destination port for each multicast group the latency tests MUST be run such that the offered load is less
address. than the multicast throughput of the DUT/SUT as determined in the
previous section. The tests should also take into account the
DUT's/SUT's need to cache the traffic in its IP cache, fastpath
cache or shortcut tables since the initial part of the traffic will
be utilized to build these tables.
In addition, the transmit and receive rates in frames per second Lastly, RFC 1242 and RFC 2544 draws distinction between two classes
for each source and destination port for all multicast groups, of devices: "store and forward" and "bit-forwarding." Each class
together with the number of frames transmitted and received per impacts how latency is collected and subsequently presented. See
port per multicast groups SHOULD be reported. the related RFCs for more information. In practice, much of the
test equipment will collect the latency measurement for one class
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, bit times to the timestamp
trigger within the packet, 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.)
4.4.3 Re-encapsulation Throughput 5.1. Multicast Latency
Definition Objective
The maximum rate at which frames of one encapsulated format To produce a set of multicast latency measurements from a single,
offered a DUT/SUT are converted to another encapsulated format and multicast ingress port of a DUT or SUT through multiple, egress
correctly forwarded by the DUT/SUT without loss. multicast ports of that same DUT or SUT as provided for by the
metric "Multicast Latency" in RFC 2432.
The 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
Re-encapsulation takes place in DUT/SUT B after test port C has If the test trial is to characterize latency across a single Device
received the decapsulated frames. These decapsulated frames will Under Test (DUT), an example test topology might take the form of
be re-inserted with a new encapsulation frame and sent to test Figure 1 in section 3. That is, a single DUT with one ingress
port B which will measure the throughput. See Figure 5. interface receiving the multicast test traffic from packet-
transmitting component of the test apparatus and n egress
interfaces on the same DUT forwarding the multicast test traffic
back to the packet-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).
Test port A DUT/SUT A Test port B DUT/SUT B Test port If the multicast latencies are to be taken across multiple devices
C 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 to the
| | | | suggested traffic class guidelines MUST be disclosed with the
-----(a) (b)| |(c) ---- (d)| |(e) (f)---- respective trial results. 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.
|||||
----- | | ---- | | ----
-
| | | |
---------- ----------
Figure 5 End-to-end reachability of the test traffic path SHOULD be verified
-------- prior to the engagement of a test trial. This implies that
Result 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.
Parameters to be measured SHOULD include the frame loss and A test traffic stream is presented to the DUT. At the mid-point of
percent loss per destination port for each multicast group the trial's duration, the test apparatus MUST inject a uniquely
address. identifiable ("tagged") packet into the test traffic packets being
presented. This tagged packet 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 from the
other packets comprising the test traffic set. A packet generation
timestamp, Timestamp A, reflecting the completion of the
transmission of the tagged packet by the test apparatus, MUST be
determined.
In addition, the transmit and receive rates in frames per second The test apparatus then monitors packets from the DUT's tested
for each source and destination port for all multicast groups, egress port(s) for the expected tagged packet(s) until the
together with the number of frames transmitted and received per cessation of traffic generation at the end of the configured trial
port per multicast groups SHOULD be reported. duration.A value of the Offered Load presented the DUT/SUT MUST be
noted.
5 Forwarding Latency The test apparatus MUST record the time of the successful detection
of a tagged packet 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.
This section presents methodologies relating to the characterization A trial MUST be considered INVALID should any of the following
of the forwarding latency of a DUT/SUT in a multicast environment. It conditions occur in the collection of the trial data:
extends the concept of latency characterization presented in RFC
2544.
5.1 Multicast Latency . Forwarded test packets directed to improper destinations.
. 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.
. Forwarded test packets improperly formed or packet header
fields improperly manipulated.
. Failure to forward required tagged packet(s) on all expected
egress interfaces.
. Reception of a tagged packet by the test apparatus outside the
configured test duration interval or 5 seconds, whichever is
greater.
Definition Data from invalid trials SHOULD be considered inconclusive. Data
from invalid trials MUST not form the basis of comparison.
The set of individual latencies from a single input port on the The set of latency measurements, M, composed from each latency
DUT/SUT or SUT to all tested ports belonging to the destination measurement taken from every ingress/tested egress interface
multicast group. 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) }
Procedure where (E0 ... En) represents the range of all tested egress
interfaces and Timestamp B represents a tagged packet detection
event for a given DUT/SUT tested egress interface.
According to RFC 2544, a tagged frame is sent half way through the Results
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 Two types of information MUST be reported: 1) the set of latency
less than the multicast throughput of the DUT/SUT. In addition, the measurements and 2) the significant environmental, methodological,
transmission rate SHOULD be less than the rate at which the buffers or device particulars giving insight into the test or its results.
are depleted in order to avoid measuring buffer depth. The test
should also take into account the DUT's/SUT's need to cache the
traffic in its IP cache, fastpath cache or shortcut tables since the
initial part of the traffic will be utilized to build these tables.
Result Specifically, when reporting the results of a VALID test trial, the
set of 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 be uniform and with
sufficient precision for the medium or media being tested. Results
MAY be offered in tabular format and SHOULD preserve the
relationship of latency to ingress/egress interface to assist in
trending across multiple trials.
The parameter to be measured is the latency value for each multicast The Offered Load of the test traffic presented the DUT/SUT, size of
group address per destination port. An aggregate latency MAY also be the "tagged" packet, trial duration, and nature (i.e., store-and-
reported. In addition, the transmit rate in frames per second for forward or bit-forwarding) of the trial's measurement MUST be
each source port SHOULD be reported. associated with any reported test trial's result.
5.2 Min/Max/Average Multicast Latency 5.2. Min/Max Multicast Latency
Objective
Definition
The difference between the maximum latency measurement and the The difference between the maximum latency measurement and the
minimum latency measurement from the set of latencies produced by the minimum latency measurement from a collected set of latencies
Multicast Latency benchmark. produced by the Multicast Latency benchmark.
Procedure Procedure
First determine the throughput for DUT/SUT at each of the listed Collect a set of multicast latency measurements, as prescribed in
frame sizes determined by the forwarding and throughput tests of section 5.1. This will produce a set of multicase latencies, M,
section 4. Send a stream of frames to a fixed number of multicast where M is composed of individual forwarding altencies between DUT
groups through the DUT at the determined throughput rate. An packet ingress and DUT packet egress port pairs. E.g.:
identifying tag SHOULD be included in all frames to ensure proper
identification of the transmitted frame on the receive side, the type
of tag being implementation dependent.
Latencies for each transmitted frame are calculated based on the M = {L(I,E1),L(I,E2), , L(I,En)}
description of latencies in RFC 2544. The average latency is the
total of all accumulated latency values divided by the total number
of those values. The minimum latency is the smallest latency; the
maximum latency is the largest latency of all accumulated latency
values.
Note that this test MUST be run using the transmission rate that is where L is the latency between a tested ingress port, I, of the
less than the multicast throughput of the DUT/SUT. In addition, the DUT, and Ex a specific, tested multicast egress port of the DUT.
transmission rate SHOULD be less than the rate at which the buffers E1 through En are unique egress ports on the DUT.
are depleted in order to avoid measuring buffer depth. The test
should also take into account the DUT's/SUT's need to cache the From the collected multicast latency measurements in set M,
traffic in its IP cache, fastpath cache or shortcut tables since the identify MAX(M), where MAX is a function that yields the largest
initial part of the traffic will be utilized to build these tables. latency value from set M.
Identify MIN(M), when MIN is a funtion 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 Results
The parameters to be measured are the minium, maximum and average The result MUST be represented as a single numerical value in time
latency values for each multicast group address per destination port. units consistent with the corresponding latency measurements. In
In addition, the transmit rate in frames per second for each source addition the number of tested egress ports on the DUT MUST be
port SHOULD be reported. reported.
6 Overhead The nature of the traffic stream contributing to the result MUST be
reported. All required reporting parameters of multicast latency
MUST be reflected in the min/max results report, such as the
transmitted packet size(s) and offered load of the packet stream in
which the tagged packet was presented to the DUT.
This section presents methodology relating to the characterization of 6. Overhead
the overhead delays associated with explicit operations found in
This section presents methodology relating to the characterization
of the overhead delays associated with explicit operations found in
multicast environments. multicast environments.
6.1 Group Join Delay 6.1. Group Join Delay
Definition Objective
The time duration it takes a DUT/SUT to start forwarding multicast The time duration it takes a DUT/SUT to start forwarding multicast
packets from the time a successful IGMP group membership report has packets from the time a successful IGMP group membership report has
been issued to the DUT/SUT. been issued to the DUT/SUT.
Procedure 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
(timestamp A) and the first frame is forwarded to a receiving member
port (timestamp B).
Group Join delay = timestamp B - timestamp A 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 (timestamp A) and the first frame is forwarded to a receiving
member port (timestamp B).
Group Join delay = timestamp B - timestamp A
One of the keys is to transmit at the fastest rate the DUT/SUT can One of the keys is to transmit at the fastest rate the DUT/SUT can
handle multicast frames. This is to get the best resolution and the handle multicast frames. This is to get the best resolution and
least margin of error in the Join Delay. the least margin of error in the Join Delay.
However, you do not want to transmit the frames so fast that frames However, you do not want to transmit the frames so fast that frames
are dropped by the DUT/SUT. Traffic should be sent at the throughput are dropped by the DUT/SUT. Traffic should be sent at the
rate determined by the forwarding tests of section 4. throughput rate determined by the forwarding tests of section 4.
Results Results
The parameter to be measured is the join delay time for each The parameter to be measured is the join delay time for each
multicast group address per destination port. In addition, the number multicast group address per destination port. In addition, the
of frames transmitted and received and percent loss may be reported. number of frames transmitted and received and percent loss may be
reported.
6.2 Group Leave Delay 6.2. Group Leave Delay
Definition Objective
The time duration it takes a DUT/SUT to cease forwarding multicast The time duration it takes a DUT/SUT to cease forwarding multicast
packets after a corresponding IGMP "Leave Group" message has been packets after a corresponding IGMP "Leave Group" message has been
successfully offered to the DUT/SUT. successfully offered to the DUT/SUT.
Procedure Procedure
Traffic is sent on the source port at the same time as the IGMP Leave Traffic is sent on the source port at the same time as the IGMP
Group messages are transmitted from the destination ports. The leave Leave Group messages are transmitted from the destination ports.
delay is the difference in time from when the IGMP leave is sent The leave delay is the difference in time from when the IGMP leave
(timestamp A) and the last frame is forwarded to a receiving member is sent (timestamp A) and the last frame is forwarded to a
port (timestamp B). receiving member port (timestamp B).
Group Leave delay = timestamp B - timestamp A Group Leave delay = timestamp B - timestamp A
One of the keys is to transmit at the fastest rate the DUT/SUT can One of the keys is to transmit at the fastest rate the DUT/SUT can
handle multicast frames. This is to get the best resolution and handle multicast frames. This is to get the best resolution and
least margin of error in the Leave Delay. However, you do not want least margin of error in the Leave Delay. However, you do not want
to transmit the frames too fast that frames are dropped by the to transmit the frames too fast that frames are dropped by the
DUT/SUT. Traffic should be sent at the throughput rate determined by DUT/SUT. Traffic should be sent at the throughput rate determined
the forwarding tests of section 4. by the forwarding tests of section 4.
Result Results
The parameter to be measured is the leave delay time for each The parameter to be measured is the leave delay time for each
multicast group address per destination port. In addition, the number multicast group address per destination port. In addition, the
of frames transmitted and received and percent loss may be reported. number of frames transmitted and received and percent loss may be
reported.
7 Capacity 7. Capacity
This section offers terms relating to the identification of multicast This section offers terms relating to the identification of
group limits of a DUT/SUT. multicast group limits of a DUT/SUT.
7.1 Multicast Group Capacity 7.1. Multicast Group Capacity
Definition Objective
The maximum number of multicast groups a DUT/SUT can support while The maximum number of multicast groups a DUT/SUT can support while
maintaining the ability to forward multicast frames to all multicast maintaining the ability to forward multicast frames to all
groups registered to that DUT/SUT. multicast groups registered to that DUT/SUT.
Procedure Procedure
One or more destination ports of DUT/SUT will join an initial number One or more destination ports of DUT/SUT will join an initial
of groups. number of groups.
Then after a delay (enough time for all ports to join) the source Then after a delay (enough time for all ports to join) the source
port will transmit to each group at a transmission rate that the port will transmit to each group at a transmission rate that the
DUT/SUT can handle without dropping IP Multicast frames. DUT/SUT can handle without dropping IP Multicast frames.
If all frames sent are forwarded by the DUT/SUT and received the test If all frames sent are forwarded by the DUT/SUT and received the
iteration is said to pass at the current capacity. test iteration is said to pass at the current capacity.
If the iteration passes at the capacity the test will add an user If the iteration passes at the capacity the test will add an user
defined incremental value of groups to each receive port. defined incremental value of groups to each receive port.
The iteration is to run again at the new group level and capacity The iteration is to run again at the new group level and capacity
tested as stated above. tested as stated above.
Once the test fails at a capacity the capacity is stated to be the Once the test fails at a capacity the capacity is stated to be the
last Iteration that pass at a giving capacity. last Iteration that pass at a giving capacity.
Results Results
The parameter to be measured is the total number of group addresses The parameter to be measured is the total number of group addresses
that were successfully forwarded with no loss. that were successfully forwarded with no loss.
8 Interaction In addition, the nature of the traffic stream contributing to the
result MUST be reported. All required reporting parameters MUST be
reflected in the results report, such as the transmitted packet
size(s) and offered load of the packet stream.
8. Interaction
Network forwarding devices are generally required to provide more Network forwarding devices are generally required to provide more
functionality than just the forwarding of traffic. Moreover, network functionality than just the forwarding of traffic. Moreover,
forwarding devices may be asked to provide those functions in a network forwarding devices may be asked to provide those functions
variety of environments. This section offers terms to assist in the in a variety of environments. This section offers terms to assist
characterization of DUT/SUT behavior in consideration of potentially in the characterization of DUT/SUT behavior in consideration of
interacting factors. potentially interacting factors.
8.1. Forwarding Burdened Multicast Latency
8.1 Forwarding Burdened Multicast Latency
The Multicast Latency metrics can be influenced by forcing the The Multicast Latency metrics can be influenced by forcing the
DUT/SUT to perform extra processing of packets while multicast DUT/SUT to perform extra processing of packets while multicast
traffic is being forwarded for latency measurements. In this test, a traffic is being forwarded for latency measurements. In this test,
set of ports on the tester will be designated to be source and a set of ports on the tester will be designated to be source and
destination similar to the generic IP Multicast test setup. In destination similar to the generic IP Multicast test setup. In
addition to this setup, another set of ports will be selected to addition to this setup, another set of ports will be selected to
transmit some multicast traffic that is destined to multicast group transmit some multicast traffic that is destined to multicast group
addresses that have not been joined by these additional set of ports. addresses that have not been joined by these additional set of
ports.
For example, if ports 1,2, 3, and 4 form the burdened response setup For example, if ports 1,2, 3, and 4 form the burdened response
(setup A) which is used to obtain the latency metrics and ports 5, 6, setup (setup A) which is used to obtain the latency metrics and
7, and 8 form the non-burdened response setup (setup B) which will ports 5, 6, 7, and 8 form the non-burdened response setup (setup B)
afflict the burdened response setup, then setup B traffic will join which will afflict the burdened response setup, then setup B
multicast group addresses not joined by the ports in this setup. By traffic will join multicast group addresses not joined by the ports
sending such multicast traffic, the DUT/SUT will perform a lookup on in this setup. By sending such multicast traffic, the DUT/SUT will
the packets that will affect the processing of setup A traffic. perform a lookup on the packets that will affect the processing of
setup A traffic.
8.2 Forwarding Burdened Group Join Delay 8.2. Forwarding Burdened Group Join Delay
The port configuration in this test is similar to the one described The port configuration in this test is similar to the one described
in section 8.1, but in this test, the multicast traffic is not sent in section 8.1, but in this test, the multicast traffic is not sent
by the ports in setup B. In this test, the setup A traffic must be by the ports in setup B. In this test, the setup A traffic must be
influenced in such a way that will affect the DUT's/SUT's ability to influenced in such a way that will affect the DUT's/SUT's ability
process Group Join messages. Therefore, in this test, the ports in to process Group Join messages. Therefore, in this test, the ports
setup B will send a set of IGMP Group Join messages while the ports in setup B will send a set of IGMP Group Join messages while the
in setup A are also joining its own set of group addresses. Since the ports in setup A are also joining its own set of group addresses.
two sets of group addresses are independent of each other, the group Since the two sets of group addresses are independent of each
join delay for setup A may be different than in the case when there other, the group join delay for setup A may be different than in
were no other group addresses being joined. the case when there were no other group addresses being joined.
9 Security Considerations 9. Security Considerations
As this document is solely for the purpose of providing metric As this document is solely for the purpose of providing metric
methodology and describes neither a protocol nor a protocol's methodology and describes neither a protocol nor a protocol's
implementation, there are no security considerations associated with implementation, there are no security considerations associated
this document. with this document.
10 10. Acknowledgements
References
The authors would like to acknowledge the following individuals for
their help and participation of the compilation and editing of this
document Ralph Daniels, Netcom Systems, who made significant
contributions to earlier versions of this draft and Kevin Dubray,
Juniper Networks.
11. References
[Br91] Bradner, S., "Benchmarking Terminology for Network [Br91] Bradner, S., "Benchmarking Terminology for Network
Interconnection Devices", RFC 1242, July 1991. Interconnection Devices", RFC 1242, July 1991.
[Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for [Br96] Bradner, S., and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement [Br97] Bradner, S. "Use of Keywords in RFCs to Reflect Requirement
Levels, RFC 2119, March 1997 Levels, RFC 2119, March 1997
[Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC [Du98] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC
2432, October 1998. 2432, October 1998.
[Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995. [Hu95] Huitema, C. "Routing in the Internet." Prentice-Hall, 1995.
[Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to Interactive [Ka98] Kosiur, D., "IP Multicasting: the Complete Guide to
Corporate Networks", John Wiley & Sons, Inc, 1998. Interactive Corporate Networks", John Wiley & Sons, Inc, 1998.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998. Devices", RFC 2285, February 1998.
[Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise." Prentice- [Mt98] Maufer, T. "Deploying IP Multicast in the Enterprise."
Hall, 1998. Prentice-Hall, 1998.
[Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast [Se98] Semeria, C. and Maufer, T. "Introduction to IP Multicast
Routing." http://www.3com.com/nsc/501303.html 3Com Corp., 1998. Routing." http://www.3com.com/nsc/501303.html 3Com Corp.,
1998.
11 12. Author's Addresses
Author's Addresses
Hardev Soor Debra Stopp
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
USA USA
Phone: 818 871 1800 Phone: 818 871 1800
EMail: hardev@ixiacom.com EMail: debby@ixiacom.com
Debra Stopp Hardev Soor
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
USA USA
Phone: 818 871 1800 Phone: 818 871 1800
EMail: debby@ixiacom.com EMail: hardev@ixiacom.com
Ralph Daniels 13. Full Copyright Statement
Netcom Systems
948 Loop Road
Clayton, NC 27520
USA
Phone: 919 550 9475 "Copyright (C) The Internet Society (date). All Rights Reserved.
EMail: Ralph_Daniels@NetcomSystems.com 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.
Appendix A: Determining an even distribution Appendix A: Determining an even distribution
It is important to understand and fully define the distribution of It is important to understand and fully define the distribution of
frames among all multicast and unicast destinations. If the frames among all multicast and unicast destinations. If the
distribution is not well defined or understood, the throughput and distribution is not well defined or understood, the throughput and
forwarding metrics are not meaningful. forwarding metrics are not meaningful.
In a homogeneous environment, a large single burst of multicast In a homogeneous environment, a large single burst of multicast
frames may be followed by a large burst of unicast frames. This is a frames may be followed by a large burst of unicast frames. This is
very different distribution than that of a non-homogeneous a very different distribution than that of a non-homogeneous
environment, where the multicast and unicast frames are intermingled environment, where the multicast and unicast frames are
throughout the entire transmission. intermingled throughout the entire transmission.
The recommended distribution is that of the non-homogeneous The recommended distribution is that of the non-homogeneous
environment because it more closely represents a real-world scenario. environment because it more closely represents a real-world
The distribution is modeled by calculating the number of multicast scenario. The distribution is modeled by calculating the number of
frames per destination port as a burst, then calculating the number multicast frames per destination port as a burst, then calculating
of unicast frames to transmit as a percentage of the total frames the number of unicast frames to transmit as a percentage of the
transmitted. The overall effect of the distribution is small bursts total frames transmitted. The overall effect of the distribution is
of multicast frames intermingled with small bursts of unicast frames. small bursts of multicast frames intermingled with small bursts of
unicast frames.
12
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/