Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
"Anders Brandt" <abr@sdesigns.dk> Wed, 13 April 2011 11:36 UTC
Return-Path: <abr@sdesigns.dk>
X-Original-To: 6lowpan@ietfc.amsl.com
Delivered-To: 6lowpan@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63133E06FA for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 04:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKhEroUB09FX for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 04:36:00 -0700 (PDT)
Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by ietfc.amsl.com (Postfix) with ESMTP id 5D3D8E068E for <6lowpan@ietf.org>; Wed, 13 Apr 2011 04:36:00 -0700 (PDT)
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 13 Apr 2011 13:35:58 +0200
Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD8A9@zensys17.zensys.local>
In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
Thread-Index: Acv5U0swedas0Ob2TvKeyw12siUHkgAVmIDAAAjvHkA=
References: <4DA4BB1E.2050002@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D0459EB82@XMB-AMS-107.cisco.com>
From: Anders Brandt <abr@sdesigns.dk>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Erik Nordmark <nordmark@acm.org>, 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 13 Apr 2011 11:36:02 -0000
Erik, Pascal Sometimes I cannot recognize topics that I myself initiated! If a sleeping node needs to ask a neighbor for a favour, it has nothing to do with the routing protocol. The routing protocol may be mesh-under or route-over - or none at all. The only important issue is that since the sleeping node is (well, sleeping), it cannot participate in the routing protocol communication. And that also applies to the reactive route discovery introduced with RPL P2P. Thus, I do not agree that this should be a feature of RPL. In that case it should be replicated in RPL, RPL P2P and any future routing protocol - as well as any mesh-under solution in use out there. 6LoWPAN ND is the right place for this feature. For the above reason AND because the message flow is identical to the address registration already taking place in 6LoWPAN ND. I see no need for any new fancy time stamp mechanism if this is just another information conveyed along with the ARO. (Did I miss something here?) Just my $0.05 - Anders -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: 13. april 2011 09:54 To: Erik Nordmark; 6lowpan Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO Hi Erik: The RPL (DAO) sequence number allows the node to increment rapidly in case of rapid changes and then lazily when the situation is stable and DAO are scarce. The increase is strictly monotonous which is critical to us. A time stamp imposes a synchronization between the routers. We do not have such mechanism in RPL. A time unit (a granularity) must be agreed upon. Within that unit, movements go undetected so the time unit must be thin grained to cover rapid changes. Yet, depending on the medium, the time unit, and the size of the network, it is not necessarily easy/possible to guarantee a strictly monotonous value with a thin grained time unit. And we have limited space (2 octets) and have to deal with wrap around, which divides the space by at least 3. So RPL went for a sequence number. And we need that ND TID to redistribute 6LoWPAN ND registration as host routes into RPL if we want to allow a host to switch router over time. Note that a TID also enables to correlate an ARO in NA with the corresponding NS, thus infer loss, latency, out-of-order, etc... MIP has it for the same purpose, HA actually ignore outdated registrations, and nodes expect an ack that matches the latest registration; for ND, it is a lot easier to verify that the ack / status has the latest sequence than to go and check in the ARO that all ack'ed values are the latest ones. (RFC 3775) Sequence # A 16-bit unsigned integer used by the receiving node to sequence Binding Updates and by the sending node to match a returned Binding Acknowledgement with this Binding Update. ... Each Binding Update MUST have a Sequence Number greater than the Sequence Number value sent in the previous Binding Update to the same destination address (if any). The sequence numbers are compared modulo 2**16, as described in Section 9.5.1. There is no requirement, however, that the Sequence Number value strictly increase by 1 with each new Binding Update sent or received, as long as the value stays within the window. The last Sequence Number value sent to a destination in a Binding Update is stored by the mobile node in its Binding Update List entry for that destination. If the sending mobile node has no Binding Update List entry, the Sequence Number SHOULD start at a random value. The mobile node MUST NOT use the same Sequence Number in two different Binding Updates to the same correspondent node, even if the Binding Updates provide different care-of addresses. ... I think ND has the same need as MIP for a TID == Sequence # . We know of MIP; We know of RPL. We know of the backbone router operation. We know we'll need the TID and we know exactly why. I think we should have it in the 6LowPAN ND spec right away to avoid interop issues when we add RPL and BR operations. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Erik Nordmark > Sent: Tuesday, April 12, 2011 10:51 PM > To: '6lowpan' > Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO > > > On 3/30/11 1:30 AM, Pascal Thubert (pthubert) wrote: > > Hi Carsten: > > > > RPL recognizes a movement when a DAO information has a stale > > DAOSequence. The DAOSequence is an information that the owner of the > > advertised target increments. > > If we define an interaction whereby we redistribute ND-15 into RPL, > > then > > (probably) the RPL router will inject a host route on behalf of the > > host. > > When the RPL router injects such a route and then maintains that > > route, it still has has to provide an idea of the freshness of the > > information that it is injecting in a DAOSequence. > > When the host moves to an alternate router, it would have to provide > > something so that the new router sets an updated DAOSequence that the > > routing update percolates up the DODAG. > > IOW, without a TID, a host cannot efficiently move from a router to > > the next. > > Why couldn't the RPL router take a timestamp when it hears an ARO from a > host, and convey that in RPL? Then that timestamp can be used to determine > the most recent registration i.e., determine the most likely topological > location of the host. > > The beauty of such an approach is that it avoids requiring having the hosts > know about routing protocol-specific information like a TID. > > Erik > > _______________________________________________ > 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] Fwd: Re: "Advertize on Behalf" flag… Richard Kelsey
- [6lowpan] Fwd: Re: "Advertize on Behalf" flag in … Erik Nordmark
- [6lowpan] Fwd: Re: "Advertize on Behalf" flag in … Erik Nordmark
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Pascal Thubert (pthubert)
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Anders Brandt
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Richard Kelsey
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Erik Nordmark
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Erik Nordmark
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Samita Chakrabarti
- Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag… Reddy, Joseph