> Date: Tue, 12 Apr 2011 13:50:13 -0700
> From: Erik Nordmark <[email protected]>
>
> 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.
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?
> > 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.
>
> 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.
+1. This would be really helpful.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan