Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain

Hi Esko,

I actually don't know of an IEEE 802.15.4 radio implementation that would
not filter on PAN ID.  You should only see (at the next higher layer)
frames with the PAN ID you are a member of or the broadcast PAN ID (but
never multiple different PAN ID's)

Don

On 11/15/12 2:30 AM, "Dijk, Esko" <esko.dijk@philips.com> wrote:

>Hi Peter,
>
>Did not mean to start a new discussion - Just noticed that you assume
>different LoWPAN nodes will process eachother's 6LoWPAN frames, while
>Michael assumed that would never be the case because they are separate
>subnets. So the conclusion is it *can* be the case even though that
>violates the IPv6 link/subnet model.
>
>In ContikiOS (where I have experience with) the Pan-ID is not ignored;
>6LoWPAN frames destined to another PAN than the node is configured with,
>are filtered out.
>
>Esko
>
>-----Original Message-----
>From: peter van der Stok [mailto:stokcons@xs4all.nl]
>Sent: Thursday 15 November 2012 11:01
>To: Dijk, Esko
>Cc: consultancy@vanderstok.org; Michael Richardson; roll@ietf.org
>Subject: RE: [Roll] [roll] #105: trickle-mcast: how to determine scope of
>MPL domain
>
>HI Esko,
>
>The few LoWPAN implementations I have experience with, ignore the
>PANid.
>Actually, this is great because when the original PANid node is removed
>the network continues to exist.
>Contrary to Zigbee, where this is a problem and has led to
>standardization modifications.
>So please do not start this discussion again.
>
>So your implication (strange or not) is correct, and therfore I create
>these problems with unicast prefix based MC addresses.
>
>Greetings,
>
>Peter
>
>Dijk, Esko schreef op 2012-11-15 10:46:
>> Hi Peter, Michael,
>>
>> a question from your last 2 emails is the following:
>> if multiple LoWPAN networks are assigned the same 802.15.4 channel
>> (which is likely as Peter explained), would they not be assigned a
>> different Pan-ID to logically separate them? So for the drawing that
>> shows the 6 border routers case, there would be no mutual
>> connectivity
>> between dissemination regions anyway.
>>
>> A related question is whether nodes from different LoWPANs are
>> allowed, or not, to mutually communicate. (I could not find text on
>> this in RFC 6282 and RFC 6775 (6lowpan-nd) ).
>> If they are allowed that leads to some strange implications, for
>> example a node in LoWPAN1 sends a link-local packet which is received
>> by a node in LoWPAN2 even though it is on a different link (and
>> different IPv6 prefix).
>>
>> I can put this question on the 6lowpan list, if needed.
>>
>> regards,
>> Esko
>>
>>
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf
>> Of peter van der Stok
>> Sent: Wednesday 14 November 2012 9:38
>> To: Michael Richardson
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine
>> scope of MPL domain
>>
>> Hi Michael,
>>
>> sorry to be confusing.
>>
>> Again, this is not a real installation, just an example of what to
>> expect.
>> Surface area can be something like 100x30 square meters.
>>
>> I show 6 border routers coinciding with 6 disseminatiuon areas due to
>> a
>> remark by Dario where he asked if it is possible that multiple
>> disseminations areas can be present in one PAN.
>> The answer is yes, because giving a border router to each
>> dissemination
>> area (6) is quite expensive.
>>
>> Concerning the use of the same channel.
>> When we have one PAN, one channel is used, that is clear.
>> Having several PANs, it perspires that often only 2 channels of the
>> ones specified by 802.15.4 provide good communication ([presence of
>> 802.11, etc.).
>>
>> Several other additional organisational boundary conditions can
>> dictate
>> the channel numbers.
>>
>> Hope this helps,
>>
>> peter
>>
>>
>> Michael Richardson schreef op 2012-11-12 23:07:
>>> splitting up your text to emphasize a few things:
>>>
>>>>>>>> "peter" == peter van der Stok <stokcons@xs4all.nl> writes:
>>>     peter> The nodes in all networks use the same communication
>>> channel.
>>>
>>> ...
>>>
>>>     peter> not forward the message.  In this network configuration
>>> the
>>>     peter> dissemination area is identical with a network.  From a
>>> cost
>>>     peter> perspective (less border routers) it is more realistic if
>>> one
>>>     peter> network covers the whole floor.
>>>
>>> But, in your diagram, you have 6 border routers?!?
>>>
>>> I don't understand why nodes in area1 and area2 should use the same
>>> communication channel.
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
>> ________________________________
>> The information contained in this message may be confidential and
>> legally protected under applicable law. The message is intended
>> solely
>> for the addressee(s). If you are not the intended recipient, you are
>> hereby notified that any use, forwarding, dissemination, or
>> reproduction of this message is strictly prohibited and may be
>> unlawful. If you are not the intended recipient, please contact the
>> sender by return e-mail and destroy all copies of the original
>> message.
>
>
>________________________________
>The information contained in this message may be confidential and legally
>protected under applicable law. The message is intended solely for the
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll