Subject: RE: [nemo] RE: splitting moving networks (was: DND test)

From: "Soliman Hesham" <[email-masked]>
Date: Sat, 27 Mar 2004 00:41:39 -0500

> > => Not sure what you mean, the current spec does that.
 > 
 > Prefix table. Yes, your are right.
 > I am not sure the use of prefix table guarantee the 1MNP-1MR all the
 > case. 
 > 
 > When MR has multiple egress interfaces and register each CoA with
 > respective HoA, HA can not distinguish between the case when one MNP
 > assigned to two MRs and the case of one MNP to multihomed MR. 

=> Of course.

 > When each MR registers to different HAs, we need to verify whether
 > prefix table of each HA is consistent or not. 

=> No we don't need to do that, they're two independent 
entries.

 > >  > Do you think we can just treat this as configuration 
 > errors and do
 > >  > nothing for this?
 > > 
 > > => I'm not sure what you refer to by "this" above.
 > 
 > the case when HA detects there are multiple MRs for the same MNP.

=> As I stated before, I think it's cleaner to have 
different MNPs for MRs. If that's the decision, then
of course we can treat this case as an error just like
MIP treats multiple MNs with the same HoA as an error. 

 > > => On the surface this seems easy but not if you consider
 > > the corner cases, MR reboot, link failures....etc.
 > > I don't think it's that easy actually.
 > 
 > I don't see any problem here.
 > 
 > HA does not have the binding for the MR that reboot or lost 
 > connectivity.

=> If the MR registered for an hour how is 
the binding removed?

 > Only when HA has multiple bindings for the same MR, it checks the
 > split network with registered MRs. 

=> When it checks and one MR doesn't answer what happens?
I've already stated these points before. You can find 
them in earlier emails.

Hesham

---

From: Seongho Cho <[email-masked]>
Date: Sat, 27 Mar 2004 16:34:55 +0900

Hi, 

>  > assigned to two MRs and the case of one MNP to multihomed MR. 

 I agree.

> => No we don't need to do that, they're two independent 

 For some purposes, the consistency *would* be preferable. If we want some
 fault tolerance, multiple HAs and replication (or consistency) can be helpful.
 And this consistency problem can be solved by the HAHA protocol. 
 So, we don't need to close the possibility.

> MIP treats multiple MNs with the same HoA as an error. 

 IMO, multiple MRs can have the same MNP for the fault tolerance.
 That's one of the purpose of multihomed mobile networks, and
 that can be also the decision.

> => If the MR registered for an hour how is 

 The periodic BU can solve this problem. But traffics toward the HA
 which lost it's tunnel with the MR may experience disconnection.

 Seongho

---

From: Seongho Cho <[email-masked]>
Date: Sat, 27 Mar 2004 16:34:55 +0900

Hi, 

 I agree.

 Seongho

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 27 Mar 2004 17:20:56 +0900

At Sat, 27 Mar 2004 00:41:39 -0500,
> => No we don't need to do that, they're two independent 

Do you propose to use prefix table as MUST in the basic ?

> MIP treats multiple MNs with the same HoA as an error. 

OK.
They have mechasnim to detect that such as DAD at home link.

> => If the MR registered for an hour how is 

How to remove binding for reboot MR is not NEMO specific issue. 
Mobile IP has same issue.

ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 27 Mar 2004 17:20:56 +0900

OK.

ryuji

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 28 Mar 2004 14:53:50 +0200

> different MNPs for MRs.

First of all, let's first define what is the goal of having multiple MR, or
put in another way, which is the goal of being multihomed.

Because of the nature of multihoming in NEMO, i think that the support for
multiple technologies is a very important goal, so i guess that a
multihoming solution should support this. This means that we have two MR
with different access technologies, so packets have to be forwarded through
the router that has a link available.
I guess that is expected that links will become available and unavailable
quite often when the network is moving, so it is important that established
connections are preserved when switching technologies (and MRs)

So i think that important requirements for multihoming in nemo are what some
can call transparent support for ubiquity.

Now, this is different from the fault tolerance requirement (despite what i
have claimed before :-), since this is very localized problem, the links
that can "fail" are the links between the MR and the access routers. This
would allow a solution that consists in mechanisms based in the HA, or even
in the Home network perhaps in the visited network, but not much more

An possibility as you mention would be to use multiple prefixes, one per MR.

The problem here is that one prefix is associated with a MR, so with an
access technology. So when this access technology is unavailable, this
prefix would become unavailable.

For example, suppose you have MR1 with Pref1 and MR2 with Pref2
There is also a LFN, that in order to be reachable through both
technologies, it has to configure two addresses, Pref1:LFN and Pref2:LFN
Suppose now that LFN has established a communication with a host in the
internet, Host1, using Pref1:LFN.
suddenly, the network moves and the technology that is using MR1 is no
longer available. How do you preserve the established session?

To do that you can:
Modify the external host Host1 to support multiple addresses per connection.
This may be part of a general multihoming solution, but this will take time
to be deployed
Make some tunnels between the MR so that they forward packets belonging to
the other prefix, which actually you end up with both routers forwarding the
same prefix, which i am not sure this is so clean.

There are also other problems with this multiprefixed setup, like for
instance how do you select the source address that is working properly for
initiating a communication. Probably you will need a mechanism in the LFN to
retry with different source addresses. This may also be part of a general
multihoming solution, but again may take longer to deploy.

So my comment essentially is: the support for ubiquity seems an important
goal and that IMHO can be solved by adding some mechanisms to specific
devices, like the HA, and MR only.
If you adopt a multiprefix solution, a clean support will require support
from the external hosts. Other solutions like the tunnel based solutions,
are not so clean i am not so sure that are cleaner than the single prefixed
ones. Additionally, a multiprefix solution will require support from LFN.

So, my bet would be to try to explore a single prefixed solution that
provides transparent support for ubiquity and see how we can address the
case when it splits.

Regards, marcelo

---

From: "marcelo bagnulo" <[email-masked]>
Date: Sun, 28 Mar 2004 14:53:50 +0200

To do that you can:

Regards, marcelo