Re: [6lowpan] -nd-15: Battery host support seems to be incomplete
Mukul Goyal <mukul@uwm.edu> Tue, 01 March 2011 07:02 UTC
Return-Path: <prvs=03478c821=mukul@uwm.edu>
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F42293A6A20 for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 23:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VD+MJSPTJK6 for <6lowpan@core3.amsl.com>; Mon, 28 Feb 2011 23:02:41 -0800 (PST)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 64FCB3A6A97 for <6lowpan@ietf.org>; Mon, 28 Feb 2011 23:02:41 -0800 (PST)
Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 01 Mar 2011 01:03:43 -0600
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 6ACA22B3EF5; Tue, 1 Mar 2011 01:01:11 -0600 (CST)
X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu
Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo25rCKcDM6A; Tue, 1 Mar 2011 01:01:10 -0600 (CST)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E5B562B3EF3; Tue, 1 Mar 2011 01:01:10 -0600 (CST)
Date: Tue, 01 Mar 2011 01:03:43 -0600
From: Mukul Goyal <mukul@uwm.edu>
To: Anders Brandt <abr@sdesigns.dk>
Message-ID: <998941457.367175.1298963023165.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD782@zensys17.zensys.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686)
X-Authenticated-User: mukul@uwm.edu
Cc: 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] -nd-15: Battery host support seems to be incomplete
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Mar 2011 07:02:43 -0000
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" <abr@sdesigns.dk> To: zach@sensinode.com, "6lowpan" <6lowpan@ietf.org> 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: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] 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 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Mukul Goyal
- [6lowpan] Working Group Last call for draft-ietf-… Carsten Bormann
- Re: [6lowpan] Working Group Last call for draft-i… Don Sturek
- Re: [6lowpan] Working Group Last call for draft-i… Pascal Thubert (pthubert)
- [6lowpan] -nd-15: DAD requirement seems too strict Anders Brandt
- [6lowpan] -nd-15: Joining the all-nodes multicast… Anders Brandt
- [6lowpan] -nd-15: Battery host support seems to b… Anders Brandt
- [6lowpan] -nd-15: Purpose of SLLA slightly unclear Anders Brandt
- [6lowpan] 6lowPAN HC in context of draft-thubert-… Anders Brandt
- Re: [6lowpan] -nd-15: Joining the all-nodes multi… Colin O'Flynn
- Re: [6lowpan] -nd-15: Joining the all-nodes multi… Anders Brandt
- Re: [6lowpan] -nd-15: DAD requirement seems too s… Colin O'Flynn
- Re: [6lowpan] -nd-15: DAD requirement seems too s… Anders Brandt
- Re: [6lowpan] -nd-15: Battery host support seems … Mukul Goyal
- Re: [6lowpan] Working Group Last call for draft-i… Dijk, Esko
- [6lowpan] "Advertize on Behalf" flag in ARO Mukul Goyal
- Re: [6lowpan] Working Group Last call for draft-i… Mathieu Goessens
- Re: [6lowpan] Working Group Last call for draft-i… Noriyuki SATO
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Mukul Goyal
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Erik Nordmark
- Re: [6lowpan] -nd-15: Joining the all-nodes multi… Erik Nordmark
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Dijk, Esko
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Carsten Bormann
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Pascal Thubert (pthubert)
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Carsten Bormann
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Mukul Goyal
- Re: [6lowpan] -nd-15: Joining the all-nodes multi… Erik Nordmark
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Anders Brandt
- [6lowpan] How to find the mailbox? (related to "A… Anders Brandt
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Dijk, Esko
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Pascal Thubert (pthubert)
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Pascal Thubert (pthubert)
- Re: [6lowpan] How to find the mailbox? (related t… Richard Kelsey
- Re: [6lowpan] How to find the mailbox? (related t… Jonathan Hui
- Re: [6lowpan] How to find the mailbox? (related t… Pascal Thubert (pthubert)
- Re: [6lowpan] How to find the mailbox? (related t… Noriyuki SATO
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Erik Nordmark
- Re: [6lowpan] "Advertize on Behalf" flag in ARO Erik Nordmark