Re: [bmwg] Summary of changes to mcast .12 rev

[Scott Poretsky <[e-mail]>]

Looks good to me.  Changes match as was discussed.

Scott

At 08:58 AM 6/30/2003 -0700, Debby Stopp wrote:
>Here's a summary of the changes from .12 rev to .13 rev:
>
>1) o The DUT/SUT MUST learn the appropriate unicast addresses; and"
>    to:
>    o  The DUT/SUT MUST learn the appropriate unicast and multicast
>addresses; and"
>
>
>2) "The following results MUST be reflected in the test report:
>
>    o The Max/Min value
>    o The set of all latencies with respective time units
>related to the
>tested ingress and each tested egress DUT/SUT interface."
>
>    to:
>
>    "The following results MUST be reflected in the test report:
>    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 to the
>tested ingress and each tested egress DUT/SUT interface."
>
>
>3) "Mixed class throughput measurement is defined in RFC2432 [Du98]. A
>search algorithm MUST be utilized to determine the Mixed
>Class Throughput."
>
>    to:
>
>    "Mixed class throughput measurement is defined in RFC2432 [Du98]. A
>search algorithm MUST be utilized to determine the Mixed
>Class Throughput.
>     The ratio of unicast to multicast frames MUST remain the same when
>varying the intended load."
>
>
>4)from section 4.1:
>"The unicast class frames MUST be configured to transmit in a round-robin
>fashion to all of the destination ports."
>
>     to:
>
>"The unicast class frames MUST be configured to transmit in an unweighted
>round-robin fashion to all of the destination ports."
>
>
>
>5) Modified text for Join Delay text to include ref of state 0/1:
>Method A:
>
>Method A assumes that the Multicast Forwarding Database <MFDB> of the
>DUT/SUT does not contain or has not learned the specified
>multicast group
>address; specifically, the MFDB MUST be in State 0.  In this
>scenario, the
>metric represents the time the DUT/SUT takes to add the
>multicast address to
>the MFDB and begin forwarding the 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
>calculate the
>Multicast Group Join Delay, it MUST be verified through externally
>observable means that the destination test port is not
>currently a member of
>the specified multicast group.  In addition, it MUST be
>verified through
>externally observable means that the MFDB of the DUT/SUT does
>not contain
>the specified multicast address.
>
>
>Method B:
>
>Method B assumes that the MFDB of the DUT/SUT does contain
>the specified
>multicast group address; specifically, the MFDB MUST be in
>State 1.  In this
>scenario, the metric represents the time the DUT/SUT takes to
>update the
>MFDB with the additional nodes and their corresponding
>interfaces and to
>begin forwarding the multicast packet.  One or more egress
>ports MAY be used
>to determine this metric.
>
>Prior to sending any IGMP Group Membership Reports used to
>calculate the
>Group Join Delay, it MUST be verified through externally
>observable means
>that the MFDB contains the specified multicast group address.
>  A single
>un-instrumented test port MUST be used to join the specified
>multicast group
>address prior to sending any test traffic.  This port will be
>used only for
>insuring that the MFDB has been populated with the specified
>multicast group
>address and can successfully forward traffic to the
>un-instrumented port.
>
>6) In section 6.1, change this text <add method to MUST
>config params>:
>
>"Similar to Section 6.1, the following configuration
>parameters MUST be
>reflected in the test report:
>
>o Frame size(s)
>o Number of tested egress interfaces on the DUT/SUT
>o IGMP version
>o Offered load to ingress interface
>o Total number of multicast groups
>o Offered load to burdening ports
>o Total number of burdening ports"
>
>    to:
>
>"Similar to Section 6.1, the following configuration
>parameters MUST be
>reflected in the test report:
>
>o Frame size(s)
>o Number of tested egress interfaces on the DUT/SUT
>o IGMP version
>o Offered load to ingress interface
>o Total number of multicast groups
>o Offered load to burdening ports
>o Total number of burdening ports
>o Method used to measure the join delay metric"
>
>
>Debby Stopp
>Principal Software Engineer
>[phone]
>
>IXIA
>26601 W. Agoura Rd.
>Calabasas
>CA 91302
>Tel: [phone] (US) [phone] (international)
>
>[e-mail]
>http://www.ixiacom.com
>
>
>_______________________________________________
>bmwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/bmwg



_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg