Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Apr 2011 13:50:38 -0700

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Apr 2011 09:53:31 +0200

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-masked] [mailto:[email-masked]] 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
> 
> 
> > 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.
> > IOW, without a TID, a host cannot efficiently move from a router to
> > the next.
> 
determine
> the most recent registration i.e., determine the most likely
topological
> location of the host.
hosts
> know about routing protocol-specific information like a TID.
> 
>     Erik
> 
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 13 Apr 2011 13:35:58 +0200

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: [email-masked] [mailto:[email-masked]] 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:

(RFC 3775)   Sequence #

Cheers,

Pascal

determine
topological
hosts

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 13 Apr 2011 10:38:34 -0400

> Date: Wed, 13 Apr 2011 13:35:58 +0200
> From: "Anders Brandt" <[email-masked]>
> 
> If a sleeping node needs to ask a neighbor for a favour,
> it has nothing to do with the routing protocol.

What sort of favour did you have in mind?  I thought that
what the sleeping node wanted was to have messages routed to
it, which could be be imagined to have something to do with
the routing protocol :-).

> another information conveyed along with the ARO. (Did I miss something

As I understand it, the issue has to do with a sleepy node
moving its network connection from one router to another.
One part of this is informing the new router that the sleepy
node is now a neighboring host.  That is clearly a job for
ND.  Assuming that is solved, the new router will send a RPL
DAO which will create a downward route to the sleepy node.

The problem is that the old downward route via the original
neighboring router is still in place.  Creating the new
route cannot remove the old one, because the sleepy device
must be allowed to maintain links to multiple routers.  What
I think should happen is that NUD on the original
neighboring router should detect that the sleepy host is no
longer connected, at which point that router needs to send a
DAO that does not include the sleepy host as a RPL target.
I don't know if RPL describes removing a RPL target in this
fashion.

The only way to do NUD for a node that sleeps is to time it
out if it is not heard from.  It might be better to leave
this to the link layer, because there are link layer issues
involved (does the node wake on a schedule? does it send
polling messages?) and because it needs to be done using a
minimal amount of energy.
                                       -Richard Kelsey

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Apr 2011 16:26:55 -0700

> So RPL went for a sequence number.

But the unstated assumption that RPL made is that all host-to-router 
protocols have to now be RPL aware. That doesn't sound like good design. 
A host isn't aware of whether the routers speak IS-IS or OSPF, so why do 
the hosts need to be aware of RPL by passing some TID around?

> the 6LowPAN ND spec right away to avoid interop issues when we add RPL

I don't see a need in 6lowpan-nd for a TID; the protocol works fine 
without it.
I think RPL needs to be improved to deal with reality. Isn't there a 
desire for RPL to handle 4861 hosts? Those would never know about a TID.

    Erik

---

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 25 Apr 2011 15:00:04 -0400

Hi Pascal and Nicolas,

I am in agreement with the following reasons (by Erik) as to why we don't want to add the TID/sequence#
in the ARO message. As discussed many times in the wg that the goal of this 6lowpan-nd work is to provide simple optimized neighbor discovery functionality of the low-power IPv6 network. This is independent of routing protocol functionalities such that it works with multiple routing protocols on top of it.

If RPL  or other routing protocol needs a specific information to pass around, it could do that as an option aka future extension of 6lowpan-nd. We already decided/presented in the Prague wg meeting and the consensus was to  move forward with the 6lowpan-nd as it is plus the editorial changes discussed at the meeting slides.

Besides the dependency of 6lowpan-nd on a specific routing protocol( such as RPL or backbone routing), I have a major concern including a feature like sequence# in the ARO message at this point for supporting a corner case without knowing its larger impact.

As for MIP, I am not sure if we want to run MIPv6 as it is in the 6lowpan network. Our design goal for 6lowpan-nd-basic is to provide the core functionality and then build things on top of it on a modular basis as needed.
Please help in proceeding toward the basic 6lowpan-nd work done first.

Best regards,
-Samita

| A host isn't aware of whether the routers speak IS-IS or OSPF, so why do the hosts need to be aware of RPL by | passing some TID around?

> 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.

| I don't see a need in 6lowpan-nd for a TID; the protocol works fine without it.
| I think RPL needs to be improved to deal with reality. Isn't there a desire for RPL to handle 4861 hosts? | | | Those would never know about a TID.

|   Erik