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