Hi Carsten,
----- Original Message ----- > From: Carsten Bormann <c...@tzi.org> > To: Mark Smith <markzzzsm...@yahoo.com.au> > Cc: "ipv6@ietf.org" <ipv6@ietf.org> > Sent: Friday, 29 March 2013 9:07 PM > Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast" > > On Mar 29, 2013, at 10:52, Mark Smith <markzzzsm...@yahoo.com.au> wrote: > >> Yes. NUD is performed on the link-local addresses used as the source > addresses for the MLDv2 messages. > > RFC 4861 says: > > Neighbor Unreachability Detection detects the failure of a neighbor > or the failure of the forward path to the neighbor. Doing so > requires positive confirmation that packets sent to a neighbor are > actually reaching that neighbor and being processed properly by its > IP layer. Neighbor Unreachability Detection uses confirmation from > two sources. When possible, upper-layer protocols provide a positive > confirmation that a connection is making "forward progress", that > is, > previously sent data is known to have been delivered correctly (e.g., > new acknowledgments were received recently). When positive > confirmation is not forthcoming through such "hints", a node sends > unicast Neighbor Solicitation messages that solicit Neighbor > Advertisements as reachability confirmation from the next hop. To > reduce unnecessary network traffic, probe messages are only sent to > neighbors to which the node is actively sending packets. > > See also > 7.3.1. Reachability Confirmation > > In some cases (e.g., UDP-based protocols and routers forwarding > packets to hosts), such reachability information may not be readily > available from upper-layer protocols. When no hints are available > and a node is sending packets to a neighbor, the node actively probes > the neighbor using unicast Neighbor Solicitation messages to verify > that the forward path is still working. > > So your multicast emitters would be NS-pinging their destinations all the > time? Yes, that is correct. > Probably not too onerous for your TV scenario (with REACHABLE_TIME at 30 s), > and > a good way to shutdown traffic to a hard-failed receiver before the MLDv2 > timeouts kick in, but > maybe not that great in a constrained network that only occasionally sends > multicast packets. > The constrained devices/constrained bandwidth domain is not the one I'm addressing. My focus has been "unicast performs well, sufficient CPU to replicate and unicast packets is cheap and available, low level multicast is acceptable, high level multicast is a problem" domain, although some of the other secondary benefits could make it useful in more than just 802.11 networks. I agree, the efficiencies it provides probably aren't enough for it to be useful in a 6Lowpan scenario. > (Incidentally, 4861 also says: > Neighbor Unreachability Detection is performed only for neighbors to > which unicast packets are sent; it is not used when sending to > multicast addresses. > So this would then have to be adapted, because it's no longer an either/or > with 6085.) That's a good point. Thanks very much, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
