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. Better to leave the mapping up to
the link-layer.
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
