Hi, (I'm reading and having a think about other people's emails, but this one is easy to respond to)
----- Original Message ----- > From: "Manfredi, Albert E" <[email protected]> > To: Christian Huitema <[email protected]> > Cc: "[email protected]" <[email protected]>; "[email protected]" <[email protected]> > Sent: Tuesday, 2 April 2013 7:06 AM > Subject: RE: [MBONED] "MLDv2 Procedures for Link-Layer Unicast Delivery of > Multicast" > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Christian Huitema > >> There are two solutions today: multicast all the way, from the source >> to the various destinations; and, unicast all the way. The multicast >> solution suffers from very poor performance on the 802.11 network. The >> unicast solution prevents bandwidth optimization in the distribution >> network. The "best" solution would combine unicast on 802.11 > networks >> and multicast on the distribution network. That requires protocol >> changes, so that an 802.11 node that subscribes to a multicast group >> effectively gets unicast delivery from the wireless router, while the >> wireless router gets multicast delivery from the network router. That's >> what Mark's draft is attempting to define. That seems like a fine >> project. > > Agree. I thought the proposal was to retain the IP header as is, i.e. a Class > D > destination address, but to use the unique MAC address at layer 2 (RFC 6085). > To > find the individual MAC address, I thought the plan was to use the source IP > in > the IGMP join, and then find the MAC the old fashioned way. > Yes, that is exactly what I'm proposing. It would only require changes on the multicast sender, and it is only combining the functions of MLDv2 and ND to determine the link-layer unicast address so that it can be used for link-layer unicast delivery of the IPv6 multicast packets (i.e. the IPv6 multicast packet is exactly as originally sent, the link-layer frame is no different either, other than having a unicast destination address). Initially it appeared that there would not be any changes required to either MLDv2 or ND to support this (which is why I haven't got any RFC2119 words in the ID), although Carsten has pointed out that a minor change would need to be made to ND so that NUD is used to track the presence of the neighbors for which multicast traffic is being link-layer unicast to. Best regards, Mark. > Seems like a useful workaround. I think it should be in IETF's scope. > > Bert > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
