draft-ietf-bmwg-mcastm-12.txt   draft-ietf-bmwg-mcastm-13.txt 
Network Working Group Debra Stopp Network Working Group Debra Stopp
INTERNET-DRAFT Ixia INTERNET-DRAFT Ixia
Expires in: August 2003 Brooks Hickman Expires in: August 2003 Brooks Hickman
Spirent Communications Spirent Communications
April 2003 July 2003
Methodology for IP Multicast Benchmarking Methodology for IP Multicast Benchmarking
<draft-ietf-bmwg-mcastm-12.txt> <draft-ietf-bmwg-mcastm-13.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 2, line 29 skipping to change at page 2, line 29
4.1. Mixed Class Throughput.......................................7 4.1. Mixed Class Throughput.......................................7
4.2. Scaled Group Forwarding Matrix...............................8 4.2. Scaled Group Forwarding Matrix...............................8
4.3. Aggregated Multicast Throughput..............................9 4.3. Aggregated Multicast Throughput..............................9
4.4. Encapsulation/Decapsulation (Tunneling) Throughput..........10 4.4. Encapsulation/Decapsulation (Tunneling) Throughput..........10
4.4.1. Encapsulation Throughput.................................10 4.4.1. Encapsulation Throughput.................................10
4.4.2. Decapsulation Throughput.................................12 4.4.2. Decapsulation Throughput.................................12
4.4.3. Re-encapsulation Throughput..............................14 4.4.3. Re-encapsulation Throughput..............................14
5. FORWARDING LATENCY............................................16 5. FORWARDING LATENCY............................................16
5.1. Multicast Latency...........................................16 5.1. Multicast Latency...........................................16
5.2. Min/Max Multicast Latency...................................18 5.2. Min/Max Multicast Latency...................................18
6. OVERHEAD......................................................19 6. OVERHEAD......................................................20
6.1. Group Join Delay............................................20 6.1. Group Join Delay............................................20
6.2. Group Leave Delay...........................................22 6.2. Group Leave Delay...........................................22
7. CAPACITY......................................................24 7. CAPACITY......................................................24
7.1. Multicast Group Capacity....................................24 7.1. Multicast Group Capacity....................................24
8. INTERACTION...................................................25 8. INTERACTION...................................................25
8.1. Forwarding Burdened Multicast Latency.......................25 8.1. Forwarding Burdened Multicast Latency.......................25
8.2. Forwarding Burdened Group Join Delay........................26 8.2. Forwarding Burdened Group Join Delay........................26
9. SECURITY CONSIDERATIONS.......................................28 9. SECURITY CONSIDERATIONS.......................................28
10. ACKNOWLEDGEMENTS.............................................28 10. ACKNOWLEDGEMENTS.............................................28
skipping to change at page 7, line 23 skipping to change at page 7, line 23
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. networking environment.
The following events MUST occur before offering test traffic: The following events MUST occur before offering test traffic:
o All destination test ports configured to receive multicast o All destination test ports configured to receive multicast
traffic MUST join all configured multicast groups; traffic MUST join all configured multicast groups;
o The DUT/SUT MUST learn the appropriate unicast addresses; o The DUT/SUT MUST learn the appropriate unicast and
and multicast addresses; and
o Group membership and unicast address learning MUST be o Group membership and unicast address learning MUST be
verified through some externally observable method. verified through some externally observable method.
The intended load [Ma98] SHOULD be configured as alternating The intended load [Ma98] SHOULD be configured as alternating
multicast class frames and unicast class frames to a single ingress multicast class frames and unicast class frames to a single ingress
interface. The unicast class frames MUST be configured to transmit interface. The unicast class frames MUST be configured to transmit
in a round-robin fashion to all of the destination ports. in an unweighted round-robin fashion to all of the destination
ports.
Mixed class throughput measurement is defined in RFC2432 [Du98]. A Mixed class throughput measurement is defined in RFC2432 [Du98]. A
search algorithm MUST be utilized to determine the Mixed Class search algorithm MUST be utilized to determine the Mixed Class
Throughput. Throughput. The ratio of unicast to multicast frames MUST remain
the same when varying the intended load.
Reporting Format: Reporting Format:
The following configuration parameters MUST be reflected in the The following configuration parameters MUST be reflected in the
test report: test report:
o Frame size(s) o Frame size(s)
o Number of tested egress interfaces on the DUT/SUT o Number of tested egress interfaces on the DUT/SUT
o Test duration o Test duration
o IGMP version o IGMP version
skipping to change at page 19, line 43 skipping to change at page 19, line 43
o Frame size(s) o Frame size(s)
o Number of tested egress interfaces on the DUT/SUT o Number of tested egress interfaces on the DUT/SUT
o Test duration o Test duration
o IGMP version o IGMP version
o Offered load o Offered load
o Total number of multicast groups o Total number of multicast groups
The following results MUST be reflected in the test report: The following results MUST be reflected in the test report:
o The Max/Min value o The Max/Min value
The following results SHOULD be reflected in the test report:
o The set of all latencies with respective time units related o The set of all latencies with respective time units related
to the tested ingress and each tested egress DUT/SUT to the tested ingress and each tested egress DUT/SUT
interface. interface.
The time units of the presented latency MUST be uniform and with The time units of the presented latency MUST be uniform and with
sufficient precision for the medium or media being tested. sufficient precision for the medium or media being tested.
The results MAY be offered in a tabular format and should preserve The results MAY be offered in a tabular format and should preserve
the relationship of latency to ingress/egress interface for each the relationship of latency to ingress/egress interface for each
multicast group. multicast group.
skipping to change at page 21, line 11 skipping to change at page 21, line 15
In order to minimize the variation in delay calculations as well as In order to minimize the variation in delay calculations as well as
minimize burden on the DUT/SUT, the test SHOULD be performed with minimize burden on the DUT/SUT, the test SHOULD be performed with
one multicast group. In addition, all destination test ports MUST one multicast group. In addition, all destination test ports MUST
join the specified multicast group offered to the ingress interface join the specified multicast group offered to the ingress interface
of the DUT/SUT. of the DUT/SUT.
Method A: Method A:
Method A assumes that the Multicast Forwarding Database <MFDB> of Method A assumes that the Multicast Forwarding Database <MFDB> of
the DUT/SUT does not contain or has not learned the specified the DUT/SUT does not contain or has not learned the specified
multicast group address. In this scenario, the metric represents multicast group address; specifically, the MFDB MUST be in State 0.
the time the DUT/SUT takes to add the multicast address to the MFDB In this scenario, the metric represents the time the DUT/SUT takes
and begin forwarding the multicast packet. Only one ingress and to add the multicast address to the MFDB and begin forwarding the
one egress MUST be used to determine this metric. multicast packet. Only one ingress and one egress MUST be used to
determine this metric.
Prior to sending any IGMP Group Membership Reports used to Prior to sending any IGMP Group Membership Reports used to
calculate the Multicast Group Join Delay, it MUST be verified calculate the Multicast Group Join Delay, it MUST be verified
through externally observable means that the destination test port through externally observable means that the destination test port
is not currently a member of the specified multicast group. In is not currently a member of the specified multicast group. In
addition, it MUST be verified through externally observable means addition, it MUST be verified through externally observable means
that the MFDB of the DUT/SUT does not contain the specified that the MFDB of the DUT/SUT does not contain the specified
multicast address. multicast address.
Method B: Method B:
Method B assumes that the MFDB of the DUT/SUT does contain the Method B assumes that the MFDB of the DUT/SUT does contain the
specified multicast group address. In this scenario, the metric specified multicast group address; specifically, the MFDB MUST be
represents the time the DUT/SUT takes to update the MFDB with the in State 1. In this scenario, the metric represents the time the
additional nodes and their corresponding interfaces and to begin DUT/SUT takes to update the MFDB with the additional nodes and
forwarding the multicast packet. One or more egress ports MAY be their corresponding interfaces and to begin forwarding the
used to determine this metric. multicast packet. One or more egress ports MAY be used to
determine this metric.
Prior to sending any IGMP Group Membership Reports used to Prior to sending any IGMP Group Membership Reports used to
calculate the Group Join Delay, it MUST be verified through calculate the Group Join Delay, it MUST be verified through
externally observable means that the MFDB contains the specified externally observable means that the MFDB contains the specified
multicast group address. A single un-instrumented test port MUST multicast group address. A single un-instrumented test port MUST
be used to join the specified multicast group address prior to be used to join the specified multicast group address prior to
sending any test traffic. This port will be used only for insuring sending any test traffic. This port will be used only for insuring
that the MFDB has been populated with the specified multicast group that the MFDB has been populated with the specified multicast group
address and can successfully forward traffic to the un-instrumented address and can successfully forward traffic to the un-instrumented
port. port.
skipping to change at page 27, line 37 skipping to change at page 27, line 37
Similar to Section 6.1, the following configuration parameters MUST Similar to Section 6.1, the following configuration parameters MUST
be reflected in the test report: be reflected in the test report:
o Frame size(s) o Frame size(s)
o Number of tested egress interfaces on the DUT/SUT o Number of tested egress interfaces on the DUT/SUT
o IGMP version o IGMP version
o Offered load to ingress interface o Offered load to ingress interface
o Total number of multicast groups o Total number of multicast groups
o Offered load to burdening ports o Offered load to burdening ports
o Total number of burdening ports o Total number of burdening ports
o Method used to measure the join delay metric
The following results MUST be reflected in the test report: The following results MUST be reflected in the test report:
o The group join delay time in microseconds per egress o The group join delay time in microseconds per egress
interface(s) for both the baseline and burdened response. interface(s) for both the baseline and burdened response.
The Group Join Delay results for each test MAY be reported in the The Group Join Delay results for each test MAY be reported in the
form of a table, with a row for each of the tested frame sizes per form of a table, with a row for each of the tested frame sizes per
the recommendations in section 3.1.3. Each row or iteration MAY the recommendations in section 3.1.3. Each row or iteration MAY
specify the group join delay time per egress interface, number of specify the group join delay time per egress interface, number of
 End of changes. 

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