Hi, On Mon, Jul 27, 2009 at 3:01 PM, Zach Shelby<[email protected]> wrote: > Hi Pars, > > Pars Mutaf wrote: > >> I believe understand the motivations behind avoiding broadcast NS messages >> upon incoming session. However, what happens if the whiteboard approach >> fails >> i.e. if whiteboard bindings are lost due to edge router crash, reboot >> or changing >> the edge router for whatever administrative reason? > > This is a good question. As whiteboards have soft state, and nodes refresh > the addresses they are using periodically, a whiteboard failure is not a > disaster to the network. If an Edge Router crashes: > > 1. If the ER reboots without state - the next NR message will refresh the > entries. It could be nice if the LoWPAN somehow knew that this happened > (how?) to avoid waiting up to NR_PERIOD. At least its default route will > stop working, that is an indication. > > 2. If the ER reboots and kept its whiteboard state (recommended) - then of > course the ER can't forward on behalf of the node while down. Same for any > router, so this isn't a whiteboard problem. > > 3. If the ER goes down permanently, then the node will detect this because > its default route no longer works or the NR can no longer be sent to the ER. > It either starts using an alternative ER or continues operating until a new > ER comes on-line. > > In any case the LoWPAN can continue to operate while an ER is down (routing > within the LoWPAN). In an extended LoWPAN nodes will start using alternative > ERs automatically. Several techniques could be used by an ER vendor to > automatically switch state to an alternative ER, use non-volatile memory for > Whiteboard state, use secondary bindings etc.
Using non-volatile memory would solve the problem perhaps. Btw, how much information you can store in non-volatile memory? I think this solution should be explicitly described in the document. This is a major difference from standard neighbor discovery which does not require that neighbor cache state be stored in non-volatile memory. And, I am still not sure that this approach is completely reliable, even with non-volatile memory. What if, for some reason, the node believes that its address was registered, but it is not yet, and incoming packet arrives? This is a race condition. Standard neigbor discovery does not have this problem. In addition, non-volatile memory does not handle the case where the administrator wants to change or upgrade the edge router. In this case whiteboard state would be lost, all idle nodes would be unreachable for NR_PERIOD which should be long for preserving energy. Standard neighbor discovery does not have this problem. What about the following solution? 1. Use standard neighbor discovery. 2. Increase the number of edge routers, i.e. decrease the number of nodes per edge router. This will very much reduce the rate of incoming sessions from the Internet (per edge router) and hence the rate of broadcast Neighbor Solicitations. 3. Increase the neighbor cache lifetime. This will further reduce the Neighbor Solicitation rate. Standard neighbor discovery may induce high neighbor solicitation signaling cost, yes. But, this looks like a network management problem to me. Not necessarily a protocol design problem. Regards, pars > > Section 7.9 of nd-04 deals with this partially: > > http://tools.ietf.org/html/draft-ietf-6lowpan-nd-04#section-7.9 > >> A related question: how frequent you believe broadcast NS messages >> (i.e. incoming >> sessions) will be in a 6lowpan network? Or, sessions will be mostly >> initiated by >> 6lowpan nodes? > > We aren't using NS messages at all inside the LoWPAN. Node Registration > messages are always node initiated. > > - Zach > >> Regards, >> >> pars >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > http://www.sensinode.com > http://zachshelby.org - My blog “On the Internet of Things” > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
