Hello Zach, You wrote: I agree, we must minimize the use of multicast so that broadcast storms as you call them don't occur. Even if you use a link-layer adaptation that emulated multicast - you are still broadcasting on wireless links, even flooding. So this all boils down to minimizing the use of multicast.
Comment: Multicast can be done without flooding the network, if the nodes that are members of the multicast group are clumped, not evenly distributed throughout the network. A non-member node decrements a radius count and forwards the multicast. A member node reloads (or computes) the radius count and forwards the multicast. Forwarding is a one-hop broadcast. Once the radius count is 0, forwarding stops. I'm sure that there are even better ways than this simple mechanism. Cheers, Cam --- Cam Williams Schneider-Electric TAC R&D 978 975 9533 office 978 500 8807 cell -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Zach Shelby Sent: Tuesday, May 19, 2009 7:12 AM To: Alexandru Petrescu Cc: 6lowpan Subject: Re: [6lowpan] disagreement on link-layer multicast Hi, Alexandru Petrescu wrote: > Zach, > > I humbly take advantage of this to express disagreement, and my > support of the following: > -LoWPAN node SHOULD join the relevant multicast groups when the > underlying link is multicast-capable (contrary to what > draft-ietf-6lowpan-nd suggests) - risk of inefficient link use. Sure, we can say that (I will take an AP). We will still reduce the frequency and use of multicast wherever possible however in 6lowpan-nd. > -IP LoWPAN node shouldn't use the 0xffff link broadcast addresses - > risk of 'storms'. The IP LoWPAN node makes no such decision at L3... It sends a packet to FF02::1 or FF02::2 for example, the mapping is done by the link-layer adaptation. Most link-layers will use some kind of broadcast (like IEEE 802.15.4) to send such a packet. I agree, we must minimize the use of multicast so that broadcast storms as you call them don't occur. Even if you use a link-layer adaptation that emulated multicast - you are still broadcasting on wireless links, even flooding. So this all boils down to minimizing the use of multicast. > -adaptation layer shouldn't precede the IP header, nor should it > eliminate it (as rfc4944 does) - otherwise there's no more IP. No comment. > -IP layer shouldn't do tasks reserved to the link-layer - risk of > 'layer violation'. Nor is it in this working group. The IP layer also has to live with *existing link layers*, and actually function efficiently with them. Just because you would like a link-layer to function in some way - it doesn't mean it will. This is not a theoretical exercise - we are working with real radios here. > I dare to qualify these as bviously debatable points (although > apparently only I maintain them), and I do think they deserve much > larger discussion. > I do share the point of view of the need to connect these devices to > the Internet. > > Yours, > > Alex > > Zach Shelby a écrit : >> Hi, >> >> Alexandru Petrescu wrote: >>> I need to correct my stance here, now knowing IEEE 802.15.5 >>> mesh-under does offer multicast link-layer. >> >> IEEE 802.15.4-2006 does not support multicast. >> >> RFC4944 Section 9 only has a theoretical mapping of multicast >> addresses to 16-bit short addresses. It assumes that some future >> LoWPAN mesh-under routing algorithm would have some way of realizing >> those multicast mechanisms. Multicast would likely still be mapped to >> IEEE 802.15.4 broadcast, and even worse, over multihops that is >> flooding. In fact, because each link-local scope multicast could be a >> multihop flood, it might even be much worse without IP knowing it. >> Section 9 was done a bit prematurely, as in the end there are no >> LoWPAN mesh algorithms being specified, the concentration is on IP >> routing and ROLL. >> >>> I think when mesh-under is available, multicast link-layer is also >>> available, and when so the LoWPAN ND should take advantage of it: do >>> the typical link-scoped multicast operations: join, leave. >> >> I don't have a problem with a limited amount of link-scope multicast >> use if it is a simple broadcast (not a flood), if it actually reaches >> the nodes intended, and the frequency is low. For example link-local >> scoped multicast is used in ND for 6LoWPAN by RS/RA messages. The >> frequency is optimized using the Trickle algorithm. >> >>> I think the '100' described by 4944 "Multicast Address Mapping" >>> should be known and reserved by IEEE, if it's not already, such that >>> other than IP protocols don't make group addresses which start with >>> '100'. >> >> This has nothing to do with IEEE 802.15.4 right now. If IEEE 802.15.4 >> would support multicast some day, we should of course encourage them >> to consider RFC4944 Section 9 format. >> >>> And I also suggest to have specific text in LoWPAN ND draft which >>> says that if mesh-under is available then group ff02::1 maps into >>> 0x8001 and ff02::2 into 0x8002, and LoWPAN ND should use the >>> link-layer multicast features if mesh-under is available. >> >> Section 9 of RFC4944 refers only to a LoWPAN mesh-under solution >> (which doesn't exist today). Other link-layers which may support >> mesh-under might have a completely different mapping. It would be >> confusing to specify a mapping which is not useful. > > For other link layers with other mappings, specify other > IPv6-over-that-link documents. > >> Better to leave the mapping up to the link-layer. > > IPv6 over Ethernet takes a specific mapping, it doesn't leave it to > Ethernet. > >>> Example specific statement is "LoWPAN node SHOULD or MUST join the >>> group ff02::1, if mesh-under is available". This expands the >>> current LoWPAN ND text which says "A LoWPAN Node does not need to >>> join the solicited-node multicast address for its own addresses and >>> SHOULD NOT have to answer a multicast Neighbor Solicitation." >> >> Avoiding the need for nodes to answer multicast messages has more to >> do with the fact that much of the time nodes are sleeping, and >> furthermore the link-layer scope does not cover all the nodes useful >> for performing ND operations (the whole subnet). Mesh-under has >> exactly the same sleeping node problem as route-over. >> >> Furthermore in a mesh-under configuration, even though it seems >> link-local scope covers the entire LoWPAN, doing an all-nodes >> multicast on the link-layer will likely be a flood. So link-layer >> abstraction here doesn't make things any more efficient. It just >> hides the ugly stuff. >> >> Now that said, the ROLL working group does have a requirement to >> support a more efficient way to support some > link-local scope >> multicast operations. I don't see that helping us with ND for 6LoWPAN >> operations. Furthermore we can't depend on a specific routing algorithm. >> >> - Zach >> >>> What do you think? >> >> >>> Alex >>> >>> >>> _______________________________________________ 6lowpan mailing list >>> [email protected] https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >> > > -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
