Pascal,
Pascal Thubert (pthubert) wrote:
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.
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.
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.
In my opinion the node is a better place to track candidate routers.
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.
Primary router is definitely a must feature.
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.
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.
Pascal
- Zach
-----Original Message-----
From: Zach Shelby [mailto:[EMAIL PROTECTED]
Sent: vendredi 4 juillet 2008 12:23
To: Pascal Thubert (pthubert)
Cc: Erik Nordmark; [email protected]
Subject: Re: [6lowpan] [Fwd: New Version Notification
fordraft-nordmark-6lowpan-reg-00]
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 PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Erik Nordmark
Sent: lundi 16 juin 2008 19:51
To: [email protected]
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 PROTECTED]>
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd. www.sensinode.com
--
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd. www.sensinode.com
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
