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

"Dijk, Esko" <esko.dijk@philips.com> Thu, 15 November 2012 10:31 UTC

Return-Path: <esko.dijk@philips.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC10821F858E for <roll@ietfa.amsl.com>; Thu, 15 Nov 2012 02:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level:
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjh1gPhZEzus for <roll@ietfa.amsl.com>; Thu, 15 Nov 2012 02:31:17 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id D166021F88CA for <roll@ietf.org>; Thu, 15 Nov 2012 02:31:16 -0800 (PST)
Received: from mail176-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE004.bigfish.com (10.236.130.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 10:31:14 +0000
Received: from mail176-co9 (localhost [127.0.0.1]) by mail176-co9-R.bigfish.com (Postfix) with ESMTP id BDA41700159; Thu, 15 Nov 2012 10:31:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
X-SpamScore: -38
X-BigFish: VPS-38(zz217bI15d6O9251Jd6eah936eI542M1432I328cMzz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h)
Received: from mail176-co9 (localhost.localdomain [127.0.0.1]) by mail176-co9 (MessageSwitch) id 1352975472714051_3087; Thu, 15 Nov 2012 10:31:12 +0000 (UTC)
Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.233]) by mail176-co9.bigfish.com (Postfix) with ESMTP id AC49DA80064; Thu, 15 Nov 2012 10:31:12 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 10:31:12 +0000
Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.20]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.02.0318.003; Thu, 15 Nov 2012 10:30:06 +0000
From: "Dijk, Esko" <esko.dijk@philips.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
Thread-Index: AQHNwkOFtl9ztYUSrkiATuslfJmcUZfpG0MQgAGQjoCAAARjkA==
Date: Thu, 15 Nov 2012 10:30:06 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED618B0C6CB@011-DB3MPN2-082.MGDPHG.emi.philips.com>
References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <B50D0F163D52B74DA572DD345D5044AF0F6EFA99@xmb-rcd-x04.cisco.com> <50932647.3050509@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F2837@xmb-rcd-x04.cisco.com> <5094202F.4010805@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F6F874A@xmb-rcd-x04.cisco.com> <509C03C2.50809@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F714CBF@xmb-rcd-x04.cisco.com> "<509C5F00.2050204@exegin.com>" <109e9168af966b0ee543f13886fef7ef@xs4all.nl> <8796.1352758060@sandelman.ca> <895d55da5f389dc29760cd52aaf91d61@xs4all.nl> <031DD135F9160444ABBE3B0C36CED618B0C67D@011-DB3MPN2-082.MGDPHG.emi.philips.com> <717524bfa3e3bcd7b8e99d632178d95c@xs4all.nl>
In-Reply-To: <717524bfa3e3bcd7b8e99d632178d95c@xs4all.nl>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [86.94.216.29]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Cc: "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2012 10:31:17 -0000

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.