[support] About the architecture of the MIPv6 daemon [Second Part]

[Arnaud Ebalard]

Hi,

Angel Bartomeu Bonillo <angelbartomeu at gmail.com> writes:

> First of all, I need to thank to those who replied to my first
> question (*Arnaud
> Ebalard,** **manish Jamwal and **Romain KUNTZ)* on the thread at
> http://ml.nautilus6.org/pipermail/support/2009-February/000616.html . I had
> problems with my email and I was forced to register again with this other
> address since I was somehow unable to receive any message from the list.
> Hence I will try to continue the thread I once started from here.
>
> As for being more specific about my needs (Answering to Arnaud Ebalard's
> question), I am building a mobile node for a vehicular network that must be
> able to interact with different routing protocols that will be running in
> the mobile node. The node may have Internet access through different access
> networks i.e. UMTS, GPRS, WIFI an so on. So my intention is to use NEPL to
> manage the multiple CoA once acquired on the different links available.
>
> I have been going around the code of the mip6d (NEMO and MCoA patched) and
> though I have found many interesting things but, could anybody tell me based
> on which events the daemon make the decision of starting a handover and
> destroying the tunnel in one interface to redirect the traffic to another
> tunnel on other interface?.
>
> I have found so far that one of these events is the status of the
> interfaces. As I have seen the code register a listener by netlink to get
> the changes in the interfaces. Does the code take any other thing into
> account, like router advertisement timer out or something like that?

In UMIP, the decision to start a handover is mostly due to notification
of a change in link/address configuration received via Netlink, for
instance when a link becomes available (or is not anymore available) or
an address is added or deleted on a given interface (or an interface
disappear). It may also happen due to an asynchronous event, for
instance if some address lifetime (CoA) becomes null or a router
lifetime become null (IIRC). Then, based on available addresses,
interfaces, and associated preferences, the decision is taken to perform
a handover.

I don't know if the MCoA patch changes anything to the logic described
above.

Cheers,

a+