On Apr 2, 2013, at 03:48, Toerless Eckert <[email protected]> wrote: > Why should an AP not be able to convert multicast->unicast.
Oh sure. I haven't checked 802.11 if its four-address structure actually might make this work without any change at the adaptation layer or above. Hacking the destination address visible at the MAC layer API may be a bit heavy, but might still work (what do we know about the implementation status of RFC 6508 or its IPv4 equivalent?). Hey, this might even be supported by snooping a bit in the 6CIO option that indicates RFC 6508 is implemented... So please go ahead and build product :-) Mark's problem of course is that he would like to make this work with commodity consumer APs. > All it would ahve > to do is IGMPv3 snooping to know the clients connected to it. And it does > know the > per-client bitrate, aka: how far or how close a client is. Yes, the AP (or controller) knows all that is needed to do this well. > I guess the one things that not possible is to send the smae multicast > group/channel > in both multicast and unicast from the same AP because that would potentially > create > persistent duplicates. Once you send multicast, you already have wasted the resources. However, a multi-unicast could serve as a fill-in for the losses (e.g., for a station more remote from the AP). Is getting lots of duplicates going to cause a problem? Grüße, Carsten -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
