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

Does your box handle multicast frame replicating in hardware or by the CPU? 
>> Hardware

Is IGMP membership reports hardware or CPU?
>> CPU

I believe that is typical for many switches.

John

-----Original Message-----
From: Perser, Jerry [mailto:jerry.perser@spirentcom.com] 
Sent: Wednesday, April 23, 2003 10:42 AM
To: BMWG (E-mail)
Subject: RE: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)

Tony,

I am not sure L2/L3 switches work the way you describe them.  Analyzing the
packet is simply if it is not in the FDB, then send it to the CPU. The
"writing the layer 2 header + replicating the packet for subsequent group
joins" are handled by hardware ASICs.

The problem is that frames not in the FDB go to the CPU for processing.
This includes the first unicast/multicast frames to a flow,
unicast/multicast with no route, and control plane frames (ARP, IGMP, OSPF,
BGP4, etc.).

Brooks was trying to prevent a DOS type attack on the CPU so that it can
handle the IGMP frame quickly and give an accurate Group Join Delay
measurement.

I would like to hear from any of the switch vendors on the reflector.  Does
your box handle multicast frame replicating in hardware or by the CPU?  Is
IGMP membership reports hardware or CPU?

Jerry.

> -----Original Message-----
> From: Tony DeLaRosa [mailto:tdelarosa@ixiacom.com]
> Sent: Tuesday, April 22, 2003 4:40 PM
> To: 'bmwg@ietf.org'
> Subject: FW: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)
> 
> 
> Brooks,
> 
> Your proposed procedure actually requires more DUT processing than the
> current one.  
> 
> The current procedure does not forward the multicast traffic since the
> Multicast Forwarding Information Base (MFIB) does not have the group
> address.  Hence the multicast packets received will be inspected and
> dropped. 
> 
> Your proposed procedure dictates forwarding multicast packets to an
> uninstrumented port to reduce CPU cycles.  However, the DUT 
> must rewrite the
> Layer 2 information for all the forwarded packets.  In 
> addition, since the
> uninstrumented port is receiving multicast packets, the DUT must also
> replicate the packet for any subsequent ports that join that 
> multicast group
> address.  This may affect the test results.
> 
> To summarize:
> 
> DUT Resources required on current procedure
> 	- Analyzing the packet
> 
> DUT Resources required on proposed procedure
> 	- Analyzing the packet + rewriting the layer 2 header + 
> replicating
> the packet for subsequent group joins
> 
> I would recommend that the current procedure be used and be 
> limited to one
> port in order to avoid using CPU resources to replicate 
> multicast packets. 
> 
> -----Original Message-----
> From: Hickman, Brooks [mailto:brooks.hickman@spirentcom.com] 
> Sent: Monday, April 21, 2003 12:11 PM
> To: 'bmwg@ietf.org'
> Subject: [bmwg] draft-ietf-bmwg-mcastm-11 Join Test(Section 6.1)
> 
> 
> 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
> bmwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/bmwg
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/bmwg
> 
_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg