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

[Don Sturek <[e-mail]>]

Hi Esko,

The topic discussed below is really an IEEE 802.15.4 topic.   That
specification has a management information block (MIB) that holds the PAN
ID the device is a member of as well as the short ID of the device within
that PAN.

While it is possible to implement devices which are simultaneously members
of multiple PAN ID's, each with different short ID's, in practice, most
silicon implementations use the MIB values as described in the
specification to perform filtering on incoming packets.   To that end, you
should only see packets with the PAN ID/short or long ID of your device
(or the broadcast PAN ID) but never packets with multiple different PAN
ID's/short ID's (at least from all of the implementations I know
about......)

Don



On 11/15/12 1:46 AM, "Dijk, Esko" <[e-mail]> wrote:

>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: [e-mail] [mailto:[e-mail]] On Behalf Of
>peter van der Stok
>Sent: Wednesday 14 November 2012 9:38
>To: Michael Richardson
>Cc: [e-mail]
>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 <[e-mail]> 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
>[e-mail]
>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.
>
>_______________________________________________
>Roll mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/roll