draft-ietf-bmwg-mcastm-01.txt   draft-ietf-bmwg-mcastm-02.txt 
Network Working Group Hardev Soor Network Working Group Hardev Soor
INTERNET-DRAFT Debra Stopp INTERNET-DRAFT Debra Stopp
Expires in: December 1999 Ixia Communications Expires in: March 2000 Ixia Communications
Ralph Daniels Ralph Daniels
Netcom Systems Netcom Systems
June 1999 October 1999
Methodology for IP Multicast Benchmarking Methodology for IP Multicast Benchmarking
<draft-ietf-bmwg-mcastm-01.txt> <draft-ietf-bmwg-mcastm-02.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 with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 3, line 20 skipping to change at page 3, line 20
frames to clear 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 only pattern that can be filtered on in order to ensure the receipt of only
the frames that are involved in the test. the frames that are involved in the test.
3.1 Test Considerations 3.1 Test Considerations
3.1.1 IGMP Support 3.1.1 IGMP Support
Each of the receiving ports should support and be able to test both IGMP Each of the receiving ports of the tester should support and be
version 1 and IGMP version 2. able to test all IGMP versions 1, 2 and 3. The minimum requirement,
however, is IGMP version 2.
Each receiving port should be able to respond to IGMP queries during the Each receiving port should be able to respond to IGMP queries during the
test. test.
Each receiving port should also send LEAVE (running IGMP version 2) Each receiving port should also send LEAVE (running IGMP version 2)
after each test. after each test.
3.1.2 Group Addresses 3.1.2 Group Addresses
The Class D Group address should be changed between tests. Many The Class D Group address should be changed between tests. Many
skipping to change at page 4, line 7 skipping to change at page 4, line 7
3.1.3 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.1.4 TTL 3.1.4 TTL
The source frames should have a TTL value large enough to accommodate The source frames should have a TTL value large enough to accommodate
the DUT/SUT. the DUT/SUT.
3.1.5 Layer 2 Support
Each of the receiving ports of the tester should support GARP/GMRP
protocols to 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 to This section contains the description of the tests that are related to
the characterization of the packet forwarding of a DUT/SUT in a 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
skipping to change at page 4, line 50 skipping to change at page 5, line 7
If 80 percent of the bandwidth is allocated for unicast traffic If 80 percent of the bandwidth is allocated for unicast traffic
and 20 percent for multicast traffic, then unicast traffic will and 20 percent for multicast traffic, then unicast traffic will
be sent at a maximum rate of 119048 frames/second and the be sent at a maximum rate of 119048 frames/second and the
multicast traffic at a rate of 29762 frames/second. multicast traffic at a rate of 29762 frames/second.
b) Transmission rate is fixed for both traffic classes and a percentage of 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 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 fixed rate of 100% of theoretical maximum is desired, then 64 byte
frames will be sent at 148810 frames/second for both unicast and 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 multicast traffic. If 80 percent of the frames are to be unicast and
20 percent multicast, then for a duration of 10 seconds, 1190480 20 percent multicast, then for a duration of 30 seconds, 3571440
frames of unicast and 297620 frames of multicast will be sent. This frames of unicast and 892860 frames of multicast will be sent. This
fixed rate scenario actually over-subscribes the bandwidth, fixed rate scenario actually over-subscribes the bandwidth,
potentially causing congestion in the DUT/SUT. potentially causing congestion in the DUT/SUT.
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 bandwidth deterministic distribution while still maintaining the specified bandwidth
and transmission rates. See Appendix A for a discussion on determining an and transmission rates. See Appendix A for a discussion on determining an
even distribution. even distribution.
Similar to the Frame loss rate test in RFC 2544, the first trial SHOULD be 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 maximum rate for run for the frame rate that corresponds to 100% of the maximum rate for
skipping to change at page 5, line 41 skipping to change at page 5, line 46
4.2 Scaled Group Forwarding Matrix 4.2 Scaled Group Forwarding Matrix
Definition: Definition:
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 line rate with a fixed Multicast traffic is sent at a fixed percent of line rate with a fixed
number of receive ports at a fixed frame length. number of receive ports of the tester at a fixed frame length.
The receive ports will join an initial number of groups and the sender 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). 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 Then the receive ports will join an incremental value of groups and the
transmit port will send to all groups joined (initial plus incremental). transmit port will send to all groups joined (initial plus incremental).
The receive ports will continue joining in the incremental fashion until a The receive ports will continue joining in the incremental fashion until a
user defined maximum is reached. user defined maximum is reached.
Results: Results:
For each group load the result WILL display frame rate, frames For each group load the result WILL display frame rate, frames
transmitted, total frames received, total frames loss, and percent transmitted, total frames received, total frames loss, and percent
loss. The frame loss per receive port per group SHOULD also be available. loss. The frame loss per receive port of the tester per group SHOULD also
be available.
4.3 Aggregated Multicast Throughput 4.3 Aggregated Multicast Throughput
Definition: Definition:
The maximum rate at which none of the offered frames to be The maximum rate at which none of the offered frames to be
forwarded through N destination interfaces of the same multicast forwarded through N destination interfaces of the same multicast
group are dropped. group are dropped.
Procedure: Procedure:
Multicast traffic is sent at a fixed percent of line rate with a fixed 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. number of groups at a fixed frame length for a fixed duration of time.
The initial number of receive ports will join the group(s) and the The initial number of receive ports of the tester will join the group(s)
sender will transmit to the same groups after a certain delay (a few and the sender will transmit to the same groups after a certain delay
seconds). (a few seconds).
Then the an incremental or decremental number of receive ports will Then the an incremental or decremental number of receive ports will
join the same groups and then the Multicast traffic is sent as stated. join the same groups and then the Multicast traffic is sent as stated.
The receive ports will continue to be added or deleted and the Multicast The receive ports will continue to be added or deleted and the Multicast
traffic sent until a user defined maximum number of ports is reached. traffic sent until a user defined maximum number of ports is reached.
Results: Results:
For each number of receive ports the result WILL display frame rate, frames For each number of receive ports the result WILL display frame rate,
transmitted, total frames received, total frames loss, and percent loss. frames transmitted, total frames received, total frames loss, and percent
The frame loss per receive port per group SHOULD also be available. loss. The frame loss per receive port per group SHOULD also be available.
4.4 Encapsulation (Tunneling) Throughput 4.4 Encapsulation (Tunneling) Throughput
This sub-section provides the description of tests that help in obtaining This sub-section provides the description of tests that help in obtaining
throughput measurements when a DUT/SUT or a set of DUTs are acting as tunnel throughput measurements when a DUT/SUT or a set of DUTs are acting as tunnel
endpoints. The following Figure 2 presents the scenario for the tests. endpoints. The following Figure 2 presents the scenario for the tests.
Client A DUT/SUT A Network DUT/SUT B Client B Client A DUT/SUT A Network DUT/SUT B Client B
---------- ---------- ---------- ----------
skipping to change at page 7, line 21 skipping to change at page 7, line 21
------- | | ------ | | ------- ------- | | ------ | | -------
| | | | | | | |
---------- ---------- ---------- ----------
Figure 2 Figure 2
-------- --------
A tunnel is created between DUT/SUT A (the encapsulator) and DUT/SUT B (the A tunnel is created between DUT/SUT A (the encapsulator) and DUT/SUT B (the
decapsulator). Client A is acting as a source and Client B is 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 destination. Client B joins a multicast group (for example, 224.0.1.1) and it
sends an IGMP Join message to DUT/SUT B to join that group. Client A now wants sends an IGMP Join message to DUT/SUT B to join that group. Client A now
to transmit some traffic to Client B. It will send the multicast traffic to wants to transmit some traffic to Client B. It will send the multicast
DUT/SUT A which encapsulates the multicast frames, sends it to DUT/SUT B which traffic to DUT/SUT A which encapsulates the multicast frames, sends it to
will decapsulate the same frames and forward them to Client B. DUT/SUT B which will decapsulate the same frames and forward them to Client
B.
4.4.1 Encapsulation Throughput 4.4.1 Encapsulation Throughput
Definition Definition
The maximum rate at which frames offered a DUT/SUT are encapsulated and The maximum rate at which frames offered a DUT/SUT are encapsulated and
correctly forwarded by the DUT/SUT without loss. correctly forwarded by the DUT/SUT without loss.
Procedure Procedure
skipping to change at page 8, line 6 skipping to change at page 8, line 4
---------- (c') (d')--------- ---------- (c') (d')---------
| |-------------->| | | |-------------->| |
-------(a) (b)| | | | -------(a) (b)| | | |
||||||| -----> | | ------ --------- ||||||| -----> | | ------ ---------
------- | |(c) ( N/W ) ------- | |(c) ( N/W )
| |---->( ) | |---->( )
---------- ------ ---------- ------
Figure 3 Figure 3
-------- --------
In Figure 2, a tunnel is created with the local IP address of DUT/SUT A as
In Figure 2, a tunnel is created with the local IP address of DUT/SUT A as the the beginning of the tunnel (point c) and the IP address of DUT/SUT B as the
beginning of the tunnel (point c) and the IP address of DUT/SUT B as the end end of the tunnel (point d). DUT/SUT B is assumed to have the tunneling
of the tunnel (point d). DUT/SUT B is assumed to have the tunneling protocol protocol enabled so that the frames can be decapsulated. When the test port B
enabled so that the frames can be decapsulated. When the test port B is is inserted in between the DUT/SUT A and DUT/SUT B (Figure 3), the endpoint
inserted in between the DUT/SUT A and DUT/SUT B (Figure 3), the endpoint of of tunnel has to be re-configured to be directed to the test port B's IP
tunnel has to be re-configured to be directed to the test port B's IP address. address. For example, in Figure 3, point c' would be assigned as the
For example, in Figure 3, point c' would be assigned as the beginning of the beginning of the tunnel and point d' as the end of the tunnel. The test port
tunnel and point d' as the end of the tunnel. The test port B is acting as B is acting as the end of the tunnel, and it does not have to support any
the end of the tunnel, and it does not have to support any tunneling protocol tunneling protocol since the frames do not have to be decapsulated. Instead,
since the frames do not have to be decapsulated. Instead, the received the received encapsulated frames are used to calculate the throughput and
encapsulated frames are used to calculate the throughput and other necessary other necessary measurements.
measurements.
Result Result
Throughput in frames per second for each destination port. The results Throughput in frames per second for each destination port. The results
should also contain the number of frames transmitted and received per port. should also contain the number of frames transmitted and received per port.
4.4.2 Decapsulation Throughput 4.4.2 Decapsulation Throughput
Definition Definition
The maximum rate at which frames offered a DUT/SUT are decapsulated and The maximum rate at which frames offered a DUT/SUT are decapsulated and
skipping to change at page 9, line 29 skipping to change at page 9, line 29
4.4.3 Re-encapsulation Throughput 4.4.3 Re-encapsulation Throughput
Definition Definition
The maximum rate at which frames of one encapsulated format offered The maximum rate at which frames of one encapsulated format offered
a DUT/SUT are converted to another encapsulated format and correctly a DUT/SUT are converted to another encapsulated format and correctly
forwarded by the DUT/SUT without loss. forwarded by the DUT/SUT without loss.
Procedure Procedure
Re-encapsulation takes place in DUT/SUT B after test port C has received the Re-encapsulation takes place in DUT/SUT B after test port C has received
decapsulated frames. These decapsulated frames will be re-inserted with the decapsulated frames. These decapsulated frames will be re-inserted
a new encapsulation frame and sent to test port B which will measure the with a new encapsulation frame and sent to test port B which will measure
throughput. See Figure 5. the throughput. See Figure 5.
Test port A DUT/SUT A Test port B DUT/SUT B Test port C Test port A DUT/SUT A Test port B DUT/SUT B Test port C
---------- ---------- ---------- ----------
| | | | | | | |
-------(a) (b)| |(c) ------ (d)| |(e) (f)------- -------(a) (b)| |(c) ------ (d)| |(e) (f)-------
||||||| -----> | |----> |||||| <---->| |<----> ||||||| ||||||| -----> | |----> |||||| <---->| |<----> |||||||
------- | | ------ | | ------- ------- | | ------ | | -------
| | | | | | | |
---------- ---------- ---------- ----------
skipping to change at page 10, line 25 skipping to change at page 10, line 25
The set of individual latencies from a single input port on the DUT/SUT or The set of individual latencies from a single input port on the DUT/SUT or
SUT to all tested ports belonging to the destination multicast group. SUT to all tested ports belonging to the destination multicast group.
Procedure Procedure
According to RFC 2544, a tagged frame is sent half way through the According to RFC 2544, a tagged frame is sent half way through the
transmission that contains a timestamp used for calculation of latency. transmission that contains a timestamp used for calculation of latency.
In the multicast situation, a tagged frame is sent to all destinations In the multicast situation, a tagged frame is sent to all destinations
for each multicast group and latency calculated on a per multicast for each multicast group and latency calculated on a per multicast
group basis. Note that this test MUST be run using the transmission group basis. Note that this test MUST be run using the transmission
rate that is less than the multicast throughput of the DUT/SUT. rate that is less than the multicast throughput of the DUT/SUT. Also,
the test should 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 Result
The latency value for each multicast group address per port. An aggregate The latency value for each multicast group address per port. An aggregate
latency MAY also be reported. latency MAY also be reported.
5.2 Min/Max/Average Multicast Latency 5.2 Min/Max/Average Multicast Latency
Definition: 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 minimum latency measurement from the set of latencies produced by
the Multicast Latency benchmark. the Multicast Latency benchmark.
Procedure: Procedure:
For the entire duration of the Latency test the smallest latency, the For the entire duration of the Latency test the smallest latency, the
largest latency, the sum of latencies, and the number should be tracked largest latency, the sum of latencies, and the number should be tracked
per receive port. per receive port of the tester.
The test can also increment bucket counters that represent a range latency The test can also increment bucket counters that represent a range latency
range. This can be used to create a histogram. From the histogram, range. This can be used to create a histogram. From the histogram,
minimum, maximum, and average the test results can show the jitter. minimum, maximum, and average the test results can show the jitter.
Results: Results:
For each port the results WILL display the number of frames, minimum For each port the results WILL display the number of frames, minimum
latency, maximum latency, and the average latency. The results SHOULD latency, maximum latency, and the average latency. The results SHOULD
also display the histogram of latencies. also display the histogram of latencies.
skipping to change at page 11, line 37 skipping to change at page 11, line 42
One of the keys is to transmit at the fastest rate the DUT/SUT can handle One of the keys is to transmit at the fastest rate the DUT/SUT can handle
multicast frames. This is to get the best resultion in the Join Delay. multicast frames. This is to get the best resultion in the Join Delay.
However, you do not want to transmit the frames to fast that frames However, you do not want to transmit the frames to fast that frames
are dropped by the DUT/SUT. Traffic should be sent at the throughput rate are dropped by the DUT/SUT. Traffic should be sent at the throughput rate
determined by the forwarding tests of section 4. determined by the forwarding tests of section 4.
Results: Results:
The JOIN delay for each port. An error or granularity of the The JOIN delay for each port. An error or granularity of the
timestamp should be reported. This granularity may be within 20 timestamp should be reported. This granularity may be within 20
nanoseconds of the result. nanoseconds of the result. The granularity depends on the hardware
limitation of the tester.
6.2 Group Leave Delay 6.2 Group Leave Delay
Definition Definition
The time duration it takes a DUT/SUT to cease forwarding multicast packets The time duration it takes a DUT/SUT to cease forwarding multicast packets
after a corresponding IGMP "Leave Group" message has been successfully after a corresponding IGMP "Leave Group" message has been successfully
offered to the DUT/SUT. offered to the DUT/SUT.
Procedure Procedure
skipping to change at page 12, line 27 skipping to change at page 12, line 33
and percent loss may be displayed. and percent loss may be displayed.
7. Capacity 7. Capacity
This section offers terms relating to the identification of multicast This section offers terms relating to the identification of multicast
group limits of a DUT/SUT. group limits of a DUT/SUT.
7.1 Multicast Group Capacity 7.1 Multicast Group Capacity
Definition: Definition:
The maximum number of multicast groups a SUT/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 maintaining the ability to forward multicast frames to all
multicast groups registered to that SUT/DUT/SUT. multicast groups registered to that DUT/SUT.
Procedure: Procedure:
One or more receiving ports will join an initial number of groups. One or more receiving ports of DUT/SUT will join an initial number of
Then after a delay the source port will transmit to each group at a groups. Then after a delay the source port will transmit to each group
transmission rate that the DUT/SUT can handle. If all frames sent are at a transmission rate that the DUT/SUT can handle. If all frames
forwarded and received the receiving ports will join an incremental sent are forwarded and received the receiving ports will join an
value of groups. Then after a delay the source port will transmit incremental value of groups. Then after a delay the source port will
to all groups at a transmission rate that the DUT/SUT can handle. If transmit to all groups at a transmission rate that the DUT/SUT can
all frames sent are forwarded and received the receiving ports will handle. If all frames sent are forwarded and received the receiving
continuing joining and testing until a frame is not forwarded nor ports will continuing joining and testing until a frame is not forwarded
received. nor received.
The group capacity resolution will be the incremental value. So the The group capacity resolution will be the incremental value. So the
capacity could be greater then last capacity passed but less then the capacity could be greater then last capacity passed but less then the
one that failed. one that failed.
Once a capacity is determined the test should be re run with greater 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 delays after the JOIN and a slower transmission rate. And the initial
group level should be raised to about five less then the previous group level should be raised to about five less then the previous
capacity and incremental value should be set to one. capacity and incremental value should be set to one.
Results: Results:
The number of groups passed vs the number of groups failed. The The number of groups passed vs the number of groups failed. The
results SHOULD give details when the frame fails to be forwarded results SHOULD give details when the frame fails to be forwarded
about how many frames did and did not get forwarded. Which groups about how many frames did and did not get forwarded. Which groups
DID and DID NOT get forwarded. Also, the frame rate MAY be reported. DID and DID NOT get forwarded. Also, the frame rate MAY be reported.
8. Interaction
Network forwarding devices are generally required to provide more
functionality than than the forwarding of traffic. Moreover, network
forwarding devices may be asked to provide those functions in a
variety of environments. This section offers terms to assist in the
charaterization of DUT/SUT behavior in consideration of potentially
interacting factors.
8.1 Forwarding Burdened Multicast Latency
The Multicast Latency metrics can be influenced by forcing the
DUT/SUT to perform extra processing of packets while multicast traffic is
being forwarded for latency measurements. In this test, a set of
ports on the tester will be designated to be source and destination
similar to the generic IP Multicast test setup. In addition to this
setup, another set of ports will be selected to transmit some multicast
traffic that is destined to multicast group 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 (setup A) which is used to
obtain the latency metrics and ports 5, 6, 7, and 8 form the non-burdened
response setup (setup B) which will afflict the burdened response setup,
then setup B traffic will join multicast group addresses not joined by
the ports in this setup. By sending such multicast traffic, the DUT/SUT
will perform a lookup on the packets that will affect the processing of
setup A traffic.
8.2 Forwarding Burdened Group Join Delay
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 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 process Group
Join messages. Therefore, in this test, the ports in setup B will send
a set of IGMP Group Join messages while the ports in setup A are also
joining its own set of group addresses. Since the two sets of group
addresses are independent of each other, the group join delay for
setup A may be different than in the case when there were no other
group addresses being joined.
Appendix A: Determining an even distribution Appendix A: Determining an even distribution
A.1 Scope Of This Appendix A.1 Scope Of This Appendix
This appendix discusses the suggested approach to configuring the This appendix discusses the suggested approach to configuring the
deterministic distribution methodology for tests that involve both deterministic distribution methodology for tests that involve both
multicast and unicast traffic classes in an aggregated traffic stream. multicast and unicast traffic classes in an aggregated traffic stream.
As such, this appendix MUST not be read as an amendment to the 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 methodology described in the body of this document but as a guide
to testing practice. to testing practice.
skipping to change at page 13, line 45 skipping to change at page 14, line 40
environment because it more closely represents a real-world environment because it more closely represents a real-world
scenario. The distribution is modeled by calculating the number of scenario. The distribution is modeled by calculating the number of
multicast frames per destination port as a burst, then calculating multicast frames per destination port as a burst, then calculating
the number of unicast frames to transmit as a percentage of the total the number of unicast frames to transmit as a percentage of the total
frames transmitted. The overall effect of the distribution is small frames transmitted. The overall effect of the distribution is small
bursts of multicast frames intermingled with small bursts of unicast bursts of multicast frames intermingled with small bursts of unicast
frames. frames.
Example Example
This example illustrates the ditribution algoirthm for a 100 Mbps rate. This example illustrates the distribution algorithm for a 100 Mbps rate.
Frame size = 64 Frame size = 64
Duration of test = 10 seconds Duration of test = 30 seconds
Transmission rate = 100% of maximum rate Intended Load (ILOAD) = 100% of maximum rate
Mapping for unicast traffic: Port 1 to Port 2 Mapping for unicast traffic: Port 1 to Port 2
Port 3 to port 4 Port 3 to port 4
Mapping for multicast traffic: Port 1 to Ports 2,3,4 Mapping for multicast traffic: Port 1 to Ports 2,3,4
Number of Multicast group addresses per destination port = 3 Number of Multicast group addresses per destination port = 3
Multicast groups joined by Port 2: 224.0.1.27 Multicast groups joined by Port 2: 224.0.1.27
224.0.1.28 224.0.1.28
224,0.1.29 224,0.1.29
Multicast groups joined by Port 3: 224.0.1.30 Multicast groups joined by Port 3: 224.0.1.30
224.0.1.31 224.0.1.31
224,0.1.32 224,0.1.32
Multicast groups joined by Port 4: 224.0.1.33 Multicast groups joined by Port 4: 224.0.1.33
224.0.1.34 224.0.1.34
224,0.1.35 224,0.1.35
Percentage of Unicast frames = 20 Percentage of Unicast frames = 20
Percentage of Multicast frames = 80 Percentage of Multicast frames = 80
Total number of frames to be transmitted = 148810 fps * 10 sec Total number of frames to be transmitted = 148810 fps * 30 sec
= 1488100 frames = 4464300 frames
Number of unicast frames = 20/100 * 1488100 = 297620 frames Number of unicast frames = 20/100 * 4464300 = 892860 frames
Number of multicast frames = 80/100 * 1488100 = 1190480 frames Number of multicast frames = 80/100 * 4464300 = 3571440 frames
Unicast burst size = 20 * 9 = 180 Unicast burst size = 20 * 9 = 180
Multicast burst size = 80 * 9 = 720 Multicast burst size = 80 * 9 = 720
Loop counter = 1488100 / 900 = 1653.4444 (round it off to 1653) Loop counter = 4464300 / 900 = 4960.3333 (round it off to 4960)
Therefore, the actual number of frames that will be transmitted: Therefore, the actual number of frames that will be transmitted:
Unicast frames = 1653 * 180 = 297540 frames Unicast frames = 4960 * 180 = 892800 frames
Multicast frames = 1653 * 720 = 1190160 frames Multicast frames = 4960 * 720 = 3571200 frames
The following pattern will be established: The following pattern will be established:
UUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMM UUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMMUUUMMMMMMMMMMMM
where U represents 60 Unicast frames (UUU = 180 frames) where U represents 60 Unicast frames (UUU = 180 frames)
M represents 60 Multicast frames (MMMMMMMMMMMM = 720 frames) M represents 60 Multicast frames (MMMMMMMMMMMM = 720 frames)
8. Security Considerations. 8. Security Considerations.
 End of changes. 

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