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

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Apr 2011 11:56:28 -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: Erik Nordmark <[email-masked]>
Date: Tue, 12 Apr 2011 11:59:32 -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: Erik Nordmark <[email-masked]>
Date: Thu, 14 Apr 2011 16:30:14 -0700

On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote:
> 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.

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?

> 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

---

From: "Reddy, Joseph" <[email-masked]>
Date: Tue, 26 Apr 2011 10:50:27 -0500

I agree we should move forward with this draft without adding additional features. 

-Joseph

----------------------------------------------------------------------

Message: 1
Date: Mon, 25 Apr 2011 15:00:04 -0400
From: Samita Chakrabarti <[email-masked]>
To: Erik Nordmark <[email-masked]>, "Pascal Thubert (pthubert)"
	<[email-masked]>, "[email-masked]"
	<[email-masked]>
Cc: 6lowpan <[email-masked]>
Subject: Re: [6lowpan] Fwd: Re:  "Advertize on Behalf" flag in ARO
Message-ID:
	<[email-masked]>
	
Content-Type: text/plain; charset="us-ascii"

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

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan