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 >-----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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
