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

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

On 3/29/11 5:32 PM, Mukul Goyal wrote:

> A router running RPL would not always know which of its registered
> neighbors are themselves RPL routers. This is because an RPL node
> must ignore any DIOs received from neighbors with higher (in
> numerical value) "rank". Also, a DAG parent may not receive a DAO
> from its child (In non-storing mode operation, it WON'T receive any
> DAO at all unless it is the DAG root and in storing mode, the child
> may decide not to send its DAO to this parent).
>
> Now, we have 2 options:
>
> 1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and
> have hosts set this flag when they send ARO inside a unicast NS to a
> 6LR. If the host later decides to become a 6LR, it can resend the ARO
> with this flag not set.
>
> 2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has
> suggested) that will specify how a received DIO/DAO from a neighbor
> can be used to mark that neighbor as a router in the registered
> neighbor cache.

Later you wrote:
> I agree. That's why I think 6lowpan ND should provide a mechanism to
> clearly identify a registered neighbor as a 6lowpan host or a 6lowpan
> router.

Sorry for the delay.

I think #1 is both open-ended and undefined. In this case RPL doesn't
care whether the node is a router or a host; it only care whether or not
the node is an RPL speaker. Thus potentially we'd need a different flag
with slightly different semantics for different routing protocols. And
perhaps even need to add multiple flags for different versions or
options in routing protocols (e.g., some future RPLv2, or non-storing,
or something else).

My take is that with 6lowpan-nd we are following the split between
routing protocol and host-router interaction which has served the
internet well for a long time.
If one or more routing protocols need more information about its
neighboring routers, then let's put the onus on providing that in the
routing protocol; there we have the expertize and also we'd avoid having
to revise ND to add more flags just to support a new version or new
routing protocol.

Thus let's do #2 and get this written down, including the assumptions
that RPL makes about hosts, and then see how RPL can be extended to work
correctly in the presence of hosts.

My 2 cents,
     Erik

---

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

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

Why is this needed?  The 6LoWPAN ND draft seems clear AROs
are sent by hosts.  Are they also sent by routers?  (I find
it very confusing that "host" sometimes is used to mean
hosts and routers and other times to mean hosts that do not
route.)  How is the router/host distinction determined when
using normal, non-6LoWPAN ND?

> correctly in the presence of hosts.

+1.  This would be really helpful.

                            -Richard Kelsey