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.
-IP LoWPAN node shouldn't use the 0xffff link broadcast addresses - risk
of 'storms'.
-adaptation layer shouldn't precede the IP header, nor should it
eliminate it (as rfc4944 does) - otherwise there's no more IP.
-IP layer shouldn't do tasks reserved to the link-layer - risk of 'layer
violation'.
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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
