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
