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