RE: LIN6 i-d for multihoming and mobility support

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Senthilkumar,

> why can't we just make a case for a distributed
> rendenzvous/referral system
> (as proposed in hip) instead of multiple MAs for each LIN6 node?

I guess that the case would depend on the nature of the id that you are
considering.
I mean, in hip the id name space is flat, so you cannot use a hierarchical
structure to organize the name space, so you need something else, like the
DHT
OTOH, if the id space is hierarchical, you could use something like the DNS
(I am not considering the timing constraints here)

I guess then that you have a choice here, hierarchical vs. flat.
IMHO hierarchical is simpler and it is already well known, so a strong
reason is required to use something else. In hip, I can clearly see the
benefits, using public keys as ids allows you to prove id ownership easily.
However, in LIN6 the id is unique and it can be locally generated. while
these are good features, I am not sure that the benefits obtained justify
the creation of a  dht-like system
>
>
...

> true. But, noid assumes that locator set does not change
> frequently. So, DNS
> is a better canditate. For frequent locator updates, we need
> something other than DNS.

Well this is another issue i think.
This is about how fast the name data base can be updated. I don't think that
a dht-like system provides a faster update than the hierarchical DNS-like
system. (this is just a feeling, i don't have any actual data about this, do
you?)

I guess that the time required to update the name data base has to do with
the number of places where the id mapping is stored (i.e. the level of
caching) and also with the lifetime of the mapping information.

Mobility solutions store the information is a single point (i.e. the HA)the
the binding lifetime is really short. This provides you with a very dynamic
system but the scalability of the system is hard, especially if you want it
to be fault tolerant.

>   But, locator changes will be frequent in a simultaneous site multi
> home & mobility/ad-hoc environment.
>

IMHO the stable locator multihoming is a  problem that is difficult enough
:-)

Adding the mobility requirement introduces new requirements that will imply
more tradeoffs, like the time required to update the database versus
reliability.
I don't know if we want to go there...

Regards, marcelo