Subject: [6lowpan] Mesh-under does offer multicast link-layer

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 May 2009 17:56:10 +0200

I need to correct my stance here, now knowing IEEE 802.15.5 mesh-under 
does offer multicast link-layer.

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 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'.

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.

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."

What do you think?

Alex

---

From: Zach Shelby <[email-masked]>
Date: Mon, 18 May 2009 15:15:47 +0300

Hi,

> 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.

> 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.

> 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.

> 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.

> 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

> Alex
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> 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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 May 2009 12:50:26 +0200

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 :
>> I need to correct my stance here, now knowing IEEE 802.15.5 
>> mesh-under does offer multicast link-layer.
> 
> 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.
> 
>>  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'.
> 
>  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.
> 
> 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-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>> 
>> 
>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 19 May 2009 14:11:47 +0300

Hi,

>  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

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.

>  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

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.

>>>  available, and when so the LoWPAN ND should take advantage of it: do 
>>> the typical link-scoped multicast operations: join, leave.
>>
>>> 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'.
>>
>>> 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
>> abstraction here doesn't make things any more efficient. It just hides 
>> the ugly stuff.
>>
>>  operations. Furthermore we can't depend on a specific routing algorithm.
>>
>> - Zach
>>
>>> What do you think?
>>
>>
>>> Alex
>>>
>>>
>>> _______________________________________________ 6lowpan mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/6lowpan
>>>
>>>
>>
> 
> 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: <[email-masked]>
Date: Tue, 19 May 2009 10:27:34 -0400

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-masked] [mailto:[email-masked]] 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:

> 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.

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 do share the point of view of the need to connect these devices to 
> the Internet.
> 
> Yours,
> 
> Alex
> 
> Zach Shelby a écrit :
>> Hi,
>>
>>> other than IP protocols don't make group addresses which start  with 
>>> '100'.
>>

--
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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Zach Shelby <[email-masked]>
Date: Tue, 19 May 2009 22:45:59 +0300

Hi Cam,

> 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…

...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.

> 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 r…

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

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND