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