Hi, Jason, On Oct 1, 2013, at 4:35 AM, Jason Manley wrote:
>> Ideally, the 10 GbE block would be modified to recognize multicast >> destination IP addressed and then add in the derived MAC address >> automatically instead of getting it from the ARP table. Then it could send >> both multicast and unicast packets. > > I think this is easy, and I thought it had actually already been done. I agree that it would not be very hard (not sure about "easy" :-)), but I don't think it's already been done. > >> It would be another matter to get the core to listen to multicast packets >> (especially multiple multicast groups). I think that would be a little more >> complicated (unless you set its IP address to a single multicast IP and >> that's the only multicast group you want it to join). > > This is the tricky part. We've thrown around a number of ideas. A true > multicast receiver is probably beyond the scope of our needs, or willingness > to implement. For our purposes, I think we can architect things that a single > receiver only needs to subscribe to consecutive/adjacent multicast addresses. > In this case, we can implement something like a multicast subnet mask, where > the least-significant-bits of the address are configurably ignored. Has > anyone built a multicast receiver on an FPGA? I think building a multicast receiver is non-trivial. Doing multicast "the right way" requires that hosts implement IGMP (Internet Group Management Protocol) and that the switch(es) implement IGMP snooping. Using a switch without IGMP snooping will result in multicast packets being delivered to every port, which can overload ports leading to dropped packets. I think using a switch that supports IGMP snooping with hosts that do NOT implement IGMP will lead to multicast packets not being delivered to those hosts. Maybe the multicast group membership can be statically configured in the switch? Dave
