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

[Angel Bartomeu Bonillo]

Thank you very much to everyone for your valuable information. Its more than
enough.

Greetings

2009/3/10 Romain KUNTZ <kuntz at lsiit.u-strasbg.fr>

> Hi,
>
> On 2009/03/09, at 18:14, Angel Bartomeu Bonillo wrote:
>
>> Can any of the MCoA fellows add more details about this issue?
>>
>
> The algorithm for MCoA is roughly the same than the one Arnaud described,
> and it is applied to each interface registered in the configuration file.
>
> MCoA however restrict handovers to horizontal ones only (i.e. no handovers
> are performed from one interface to another) : when one
> interface/address/network is not available anymore, a de-registering BU is
> sent via another interface to remove the associated binding at the HA.
>
> The src/movement.c source file will also give you better details on this.
>
> Cheers,
> romain
>
>
>
>  2009/3/9 Arnaud Ebalard <arno at natisbad.org>
>> 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+
>> _______________________________________________
>> Support mailing list
>> Support at ml.nautilus6.org
>> http://ml.nautilus6.org/mailman/listinfo/support
>>
>>
>>
>> --
>> Ángel Bartomeu Bonillo.
>> C/ Federico García Lorca 28º Esc1 Bajo  B
>> 30009 Murcia (España)
>> _______________________________________________
>> Support mailing list
>> Support at ml.nautilus6.org
>> http://ml.nautilus6.org/mailman/listinfo/support
>>
>
> _______________________________________________
> Support mailing list
> Support at ml.nautilus6.org
> http://ml.nautilus6.org/mailman/listinfo/support
>



-- 
Ángel Bartomeu Bonillo.
C/ Federico García Lorca 28º Esc1 Bajo  B
30009 Murcia (España)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.nautilus6.org/pipermail/support/attachments/20090310/4a085c4f/attachment-0002.htm