Subject: Re: [6lowpan] [Fwd: New Version Notification fordraft-nordmark-6lowpan-reg-00]

From: Zach Shelby <[email-masked]>
Date: Fri, 04 Jul 2008 13:23:14 +0300

Hi,

IMHO Erik has the model right regarding multiple routers. In dynamic 
radio environments or in applications with any kind of mobility (e.g. 
Asset Management) the ability to register with multiple routers is 
useful. I also like the new registration message, a clean solution.

- Zach

Pascal Thubert (pthubert) wrote:
> Hi Erik:
> 
> I like very much your idea of a new registration message, that's cleaner
> than changing NS like I do in the BbR proposal. 
> 
> OTOH, we do not seem to have the same model for the LoWPAN. In
> particular, your draft seems to  assume that the host would want to
> reach numerous routers and register to them all.
> 
> For instance, if you have an oil plant or a factory, it makes little
> sense for a sensor node to go all across the factory across numerous
> LoWPAN hops to register to a router that the node will never use.
> 
> In my mind, the LoWPAN nodes form dynamic clusters around the nearest
> router and use it. Routers might share a faster, powered network that is
> called a backbone in ISA parlance, to discover and reach one another.
> 
> Pascal
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Erik Nordmark
>> Sent: lundi 16 juin 2008 19:51
>> To: [email-masked]
>> Subject: [6lowpan] [Fwd: New Version Notification
> fordraft-nordmark-6lowpan-reg-00]
>>
>>
>> -------- Original Message --------
>> Subject: New Version Notification for draft-nordmark-6lowpan-reg-00
>> Date: Mon, 16 Jun 2008 10:44:02 -0700 (PDT)
>> From: IETF I-D Submission Tool <[email-masked]>
>> To: [email-masked]
>> CC: [email-masked]
>>
>>
>> A new version of I-D, draft-nordmark-6lowpan-reg-00.txt has been
>> successfuly submitted by Erik Nordmark and posted to the IETF
> repository.
>> Filename:	 draft-nordmark-6lowpan-reg
>> Revision:	 00
>> Title:		 Neighbor Discovery Registration Extension
>> Creation_date:	 2008-06-16
>> WG ID:		 Independent Submission
>> Number_of_pages: 9
>>
>> Abstract:
>> In order to reduce Neighbor Discovery multicast messages it is useful
>> if the routers on a link can maintain an authoritative list of the
>> IPv6 and layer 2 addresses for all the hosts on the link.
>>
>> This draft specifies an extension to the Router Advertisement
>> messages which trigger to hosts to send periodic registration
>> messages which can be either unicast, multicast, or anycast.  The
>> protocol uses a soft-state approach to gather registration
>> information.
>>
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lowpan
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd.   www.sensinode.com

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jul 2008 09:55:26 +0200

Hi Zach:

There are already a number of industrial solutions that are designed or
being designed to use multiple routers, and that covers not only the
registration by forwarding capabilities such as bi-(pluri)-casting.

What I'm saying is that there is a difference between binding to one or
more routers that are closeby and all the routers across a factory
plant. IOW 802.15.4 is not Ethernet. Considering the cost of maintaining
each binding, I'd suggest that a LoWPAN node binds to one or very few
routers that it selects based on the signals (L2-3 triggers) it gets
from those routers.

I can see that a router suggests alternate routers in the vincinity
(maybe using alternate radios) but there a point where other protocols,
802.21 in this specific case, are already available for the job. The
router, though, is not necessarily in a good position to suggest the
alternate routers that would be close to the node in terms of energy.

When digging into the gory details, one has to figure which backbone
router terminates the 6LoWPAN shim and in particular the fragmentation.
There must be one router somewhere that owns the buffers where a given
packet gets recomposed and expanded. This is one reason why the BbR
draft has a primary router. 

When you keep digging, you find value in including the backbone in the
scope of the node's link local address. We can expand that in a separate
thread if you wish. In any case, this is the rationale behind the
primary router defending the node's address on the backbone using proxy
ND.

Pascal

>From: Zach Shelby [mailto:[email-masked]]
>Sent: vendredi 4 juillet 2008 12:23
>To: Pascal Thubert (pthubert)
>Cc: Erik Nordmark; [email-masked]
>Subject: Re: [6lowpan] [Fwd: New Version Notification

---

From: Zach Shelby <[email-masked]>
Date: Wed, 09 Jul 2008 11:37:25 +0300

Pascal,

> routers that it selects based on the signals (L2-3 triggers) it gets

We agree completely then. My point was also that limited use of 
maintenance to one router in cases of no mobility or small networks and 
a few routers in order to speed up mobility between them or otherwise 
improve performance. Now there is the practical issue whether having 
multiple bindings actually improves performance when a node switches its 
point of attachment.

> alternate routers that would be close to the node in terms of energy.

In my opinion the node is a better place to track candidate routers.

> draft has a primary router. 

Primary router is definitely a must feature.

> primary router defending the node's address on the backbone using proxy

I definitely see the value in this and believe this will be the way to 
go for many applications. I'll pick your brain more about some BbR 
issues in Dublin.

- Zach