Subject: [6lowpan] 6lowpan-ND between routers

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 13 Jul 2010 14:38:15 +0200

Hi All,

I would like to clarify the use of 6lowpan-ND between routers (this applies
only to the route-over configuration).

My impression is that 6lowpan-ND is very well designed for host-router
interaction but not so much for router-router interaction. I see the
following reasons:

- Router discovery: A router will use the routing protocol for that. Hence,
I don’t see the usage of the RS/RA exchange in this context.

- Registration

-- For a router to register to just any other router does not make sense.
This other router might not even be used as a next hop.

-- A router could registered to a “preferred router” (defined by the routing
protocol). But this preferred router will change based on the routing
protocol logic, hence this introduces some dependency. Also this “preferred”
router might not be used as a next hop for all the traffic.

-- A router should obviously not redistribute any information learnt by a
registration mechanism to the routing protocol

-- There is no natural hierarchy between routers in terms of complexity,
sleeping needs, etc

Hence, it seems to me that we should recommend that routers do not use these
features between them.

Best,

Mathilde

http://www.cisco.com/swa/i/logo.gif

Durvy Mathilde
Software Engineer
Technology center

 <mailto:[email-masked]> [email-masked]
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

Cisco Systems International Sàrl
Av. des Uttins, 5
CH-1180 Rolle

 <http://www.cisco.com> Cisco home page

Think before you print.Think before you print.

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
e-mail and delete all copies of this message.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Jul 2010 15:08:36 +0200

On Jul 13, 2010, at 14:38, Mathilde Durvy (mdurvy) wrote:

> Hence, it seems to me that we should recommend that routers do not use these features between them.

As a minimum, a router node entering a 6LoWPAN needs to learn about the compression context in use in this 6LoWPAN.
Unless the routing protocol is configured to strictly stay within the 6LoWPAN, I have no idea how to do this in a routing protocol.

(As a more general observation, your line of reasoning would ultimately mean all kinds of IPv6 routers should never do ND.
This is not what the IPv6 design has decided to do.)

Gruesse, Carsten

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 14 Jul 2010 09:51:34 +0200

Hi Carsten,

> Hence, it seems to me that we should recommend that routers do not use
these features between them.

As a minimum, a router node entering a 6LoWPAN needs to learn about the
compression context in use in this 6LoWPAN.
Unless the routing protocol is configured to strictly stay within the
6LoWPAN, I have no idea how to do this in a routing protocol.

[Mathilde] Well distributing context is an optional feature of 6lowpan-ND. I
was trying mainly to clarify the registration part. In addition, it seems
possible to work that out with current routing protocols for LLN. If it was
not the case, the RS/RA could be used to learn network parameters only. This
generates quite some overhead traffic but it might be the only solution.

(As a more general observation, your line of reasoning would ultimately mean
all kinds of IPv6 routers should never do ND.
This is not what the IPv6 design has decided to do.)

[Mathilde] This is not my line of reasoning at all, rather I'm trying to
understand if the registration concept makes sense between routers. If not,
this means that:
- We might need to endure the cost of an initial multicast NS for address
resolution (unless the routing protocol messages carry SLLAO)
- In networks where DAD is needed, we might need to decouple DAD from
registration as specified today
 
Best,
Mathilde

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Jul 2010 18:00:28 -0700

> generates quite some overhead traffic but it might be the only solution.

6lowpan-nd allows for different routing protocols.

If your favorite routing protocol ensures that the routers learn both 
the IPv6 and MAC addresses of their peers, and you don't use short 
addresses for the routers, then there wouldn't be any need for the 
routers to register with each other.

But if for instance the routing protocol doesn't carry the MAC 
addresses, then you can use the registration mechanism between the routers.

[And my head hurts too much to think about how a network with routers 
using short addresses bootstrap when those addresses can be duplicates. 
Thus I don't know what is the best approach for that case.]

> resolution (unless the routing protocol messages carry SLLAO)

I don't understand why one would ever want to use multicast NS in the LLNs.

> registration as specified today

That would imply changing the host to router protocol, and I think that 
is the key piece we want to nail down (while allowing different routing 
protocols to be used in different networks).

      Erik

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Thu, 15 Jul 2010 10:26:55 +0200

Hi Eric,

Please see my questions / comments below:

[Eric] If your favorite routing protocol ensures that the routers learn both

[Mathilde] Agree

[Eric] But if for instance the routing protocol doesn't carry the MAC 
addresses, then you can use the registration mechanism between the routers.
[Mathilde] This is where I don't understand how it would work. Imagine you
have a router with several routes. Let say to keep it simple a default route
and two other routes, each of these routes using a different next hop (R1,
R2, R3). 
       R1
       |
 R2 -- R -- R3

The router would then need to register with the 3 different next hops?
Wouldn't it lead to one registration per neighbor cache entry? If yes, it
seems R should decide who to register with based on the routing messages and
not based on RA received. Then, when a routing next hop changes what would
happen to the registration?
Would R1, R2, R3 all perform multi-hop DAD for R address?

[Eric] [And my head hurts too much to think about how a network with routers

using short addresses bootstrap when those addresses can be duplicates. 
Thus I don't know what is the best approach for that case.]
[Mathilde] Use only EUI-64 or DHCPv6 short addresses :-)

> resolution (unless the routing protocol messages carry SLLAO)
[Eric] I don't understand why one would ever want to use multicast NS in the
LLNs.
[Mathilde] Well, if there is no better alternative. Note that between
routers we don't have the sleeping problem and in route-over multicast NS is
not so resource consuming.

> registration as specified today
[Eric] That would imply changing the host to router protocol, and I think
that 
is the key piece we want to nail down (while allowing different routing 
protocols to be used in different networks).
[Mathilde] Well, I guess I just need to be convinced the current model works
for routers as well (see my questions on registration)

Best,
Mathilde

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 25 Jul 2010 14:56:48 -0700

[Sorry for the delayed response]

On 07/15/10 01:26 AM, Mathilde Durvy (mdurvy) wrote:

> [Erik] But if for instance the routing protocol doesn't carry the MAC

It is orthogonal to the next hop determination.

An IP stack does a routing table lookup which results in a IP nexthop. 
This changes based on the operation of the routing protocol.

Then that IP nexthop is looked up in a ARP or Neighbor cache. That cache 
doesn't change as a result of routing changes.

Thus R would have NCEs for R1, R2, and R3 that map to the MAC address of 
R1, R2, and R3 respectively.

> Would R1, R2, R3 all perform multi-hop DAD for R address?

Yes, they would (if multi-hop DAD is using the 6lowpan-nd mechanism). 
Not that this doesn't occur on every re-registration but only when the 
lifetime is about to expire in the 6LBR. I suspect the lifetimes that 
the routers use in their registrations can be set reasonably high so 
that there is no noticable performance impact of the multiple multi-hop 
DAD messages to the 6LBR.

> [Erik] I don't understand why one would ever want to use multicast NS in the
> LLNs.

We already have two working alternatives:
1. The routing protocol carrying the MAC address of the nexthop
2. Using the ARO between routers.

Either of those seem preferable to re-introducing multicast NS messages.

    Erik