Subject: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)

From: "Hickman, Brooks" <[email-masked]>
Date: Mon, 21 Apr 2003 12:10:35 -0700

The current procedure for the join test in section 6.1 requires that that
the multicast traffic be offered to the DUT. Then, the destination port(s)
issue a group membership report to join the offered multicast group(s).

There has been a suggestion that the test should include a port that joins
all of the multicast groups at the start of the test. This additional port
would not be used to make any join delay measurements, but would be used to
"prime"(Section 3.1) the DUT, so that it is actually forwarding the
multicast groups before receiving the IGMP group membership report(s). It
has been augured that if no such priming of the DUT is performed, then there
may be a CPU resource contention problem between the multicast frames and
the IGMP message processing and therefore would not measure the actual
"processing time" of an IGMP group.

Again, any input from the reflector would be appreciated and welcome.

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

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 22 Apr 2003 10:32:01 -0400

There's many ways to do this and RFC 2432, intentionally, doesn't try
to constrain how one does this.

But, at first blush, I'd keep it simple: "prime" the DUT w/multicast 
traffic
to traverse on the uninstrumented port[s] on which the join delay is to 
be measured.  Then inject the to-be-measured join event on the instrumented
port[s].

FWIW,
Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 22 Apr 2003 10:32:01 -0400

FWIW,
Kevin

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 22 Apr 2003 10:47:21 -0400

Punched the send button to soon. The below should read:

"prime the DUT w/multicast traffic to traverse on the uninstrumented
port[s], that is the ports that won't be a direct part of the join delay
measurement.  Then inject..."

Hope that's clearer. So much for keeping it simple. :-)

---

From: Kevin Dubray <[email-masked]>
Date: Tue, 22 Apr 2003 10:47:21 -0400