Hi Cam,
[email protected] wrote:
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.
...in the context of neighbor discovery. Its actually not just flooding
that is a problem, but also node sleep cycles. So you also can't depend
on multicast to actually reach all nodes.
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.
Totally agree. This *could* be provided by some link-layer or adaptation
(unknown today), and e.g. ROLL has a requirement to support larger scope
multicast in its routing algorithm. But this won't help us for neighbor
discovery (RFC4861) where lots of link-local scope all-node and
all-router multicast is used. So instead in draft-6lowpan-nd we use
unicast, and some link-local scope multicast when we don't need to
reaching sleeping nodes.
For other purposes I am sure that ROLL or multicast link-layers will
make some forms of multicast useful in LoWPANs to reach groups of nodes.
- Zach
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
--
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
