Hi Anders >If an originating node (keyfob or remote control) has lost all its >working routes to a FLN, it must re-discover a source route to the FLN. >But the FLN is sleeping. >I would like a flag in the ARO: "advertise on behalf". >If set, a default router may use the neighbor information to respond >to discovery requests. The actual response format obviously depends >on the actual routing protocol. RPL-P2P is just my actual example. >Thus, how the default router uses the information is out of scope of >the ND spec.
A very good point. Normally, a 6lowpan host would use the ARO in NS/NA messages to register its address with one or more 6LRs. But, section 6.5.5 in nd-15 draft allows two 6LRs to learn each other's link layer addresses using the ARO mechanism. So, it seems that a registered NCE in a 6LR does not necessarily refer to a 6lowpan host and this 6LR, if it is running RPL, can not advertize this NCE address in its DAO or respond to RPL-P2P route discovery messages listing this NCE address as the target. The ARO flag you mentioned will solve this problem. The 6lowpan hosts would set this flag in the AROs they send, whereas the 6LRs wont. Thanks Mukul ----- Original Message ----- From: "Anders Brandt" <[email protected]> To: [email protected], "6lowpan" <[email protected]> Sent: Friday, February 25, 2011 4:42:12 AM Subject: [6lowpan] -nd-15: Battery host support seems to be incomplete Having read the doc carefully, I have a comment: Section 5.8 addresses sleeping nodes. While I agree with the text in this section it seems to me that the description does not cover an important battery host category: * The frequently listening node (FLN) In a non-storing routing environment like the one we are specifying in RPL-P2P in the ROLL WG, we have the option of issuing a reactive discovery request when needing to get in touch with a host on short notice. This is a major requirement for real users in home control and building automation. The abovementioned FLN is a battery powered host that can be reached with semi-low latency. The typical use is installations where wires would be hard to install without affecting the architectural appearance. Examples include wireless window drape controllers and electronic door locks. 802.15.4 and Z-Wave have different link-layer solutions for this but the user experience is the same: Reaction within a second or less. If an originating node (keyfob or remote control) has lost all its working routes to a FLN, it must re-discover a source route to the FLN. But the FLN is sleeping. I would like a flag in the ARO: "advertise on behalf". If set, a default router may use the neighbor information to respond to discovery requests. The actual response format obviously depends on the actual routing protocol. RPL-P2P is just my actual example. Thus, how the default router uses the information is out of scope of the ND spec. Thanks, Anders -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Bormann Sent: 17. februar 2011 16:58 To: 6lowpan Subject: [6lowpan] Working Group Last call for draft-ietf-6lowpan-nd-15 In September/October, we had the first WGLC on 6LoWPAN-ND, which resulted in a number of detailed comments and two resulting fine-tuning iterations of the draft. draft-ietf-6lowpan-nd-15.txt has been out for two months now. I understand it has taken part in several interops with multiple implementations in this period; no issues came up. We now start the Working Group Last Call on: http://tools.ietf.org/html/draft-ietf-6lowpan-nd-15 The document is planned to be submitted by this Working Group to the IESG for publication as a Standards-Track Document. This is a two-week Working-Group Last-Call, ending on Thursday, 2011-03-03 at 2359 UTC. Please review the changes to the document carefully once more, and send your comments to the 6lowpan list. Please also do indicate to the list if you are all-OK with the document. Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
