Subject: Re: [nemo] NEMO RO Problem

From: "Fan Zhao" <[email-masked]>
Date: Thu, 7 Oct 2004 21:42:51 -0700 (PDT)

Dear Carlos,

Thank you very much for your comments. 
Please see my reply below.

Sincerely,
Fan

> Dear Fan,
> 
> 	Here they are some comments/questions (maybe some of them have 
been
> already pointed by Alex, I'll try to avoid those, but some duplicates
> may appear).
> 
> El lun, 04-10-2004 a las 08:57, Fan Zhao escribi=F3:
> > Dear all,
> >=20
> > I wrote a document about NEMO RO problem, please click the=20
> > following link to see the details:
> > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt
> > http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc
> >=20
> > This document benefits from a lot of discussions and drafts.
> > It is still a preliminary version, so there are still a lot=20
> > of questions. For example, Alex said that the charter does
> > not requires dealing with multi-homing and NEMO RO. IMO, the
> > requirement that RO solution should function for multi-homing NEMO=20
> > networks and should not conflict with multi-homing mechanism seems
> > OK. We may also take a stepwise approach to solve multi-homing
> > and RO issues. Thanks for your comments.
> 
> 	First, thanks for providing the document. As Alex, I can help you 
with
> the edition if you want to submit this input as I-D.
>
Thanks a lot. I really appreciate it.
 
> "NEMO basic support protocol [...] However, it results in a non-optimal
> (We will define=20
> <93>optimal<94> and <93>non-optimal<94> later.) route (triangle-routing)
> between
> =20
> VMN/LFN/MR and CN with a non-zero and even very large probability,=20
> which causes the significant communication delay."
> 
> IMHO, with NEMO Basic Support (BTW, I suggest to use capital letters in
> "NEMO Basic Support"), 
Sure.

> the route experienced by the traffic is always
> non-optimal (of course, the severeness of this sub-optimal routing
> depends on the scenario).
Not really. In the very extreme case where HA is located on the routing
 path between the location of CN and the location of MR, the route taken
 by the traffic in NEMO Basic Support is the same as the “optimal route”
 according to the definition in the document.

> I'd use MNN instead of "VMN/LFN/MR". With VMN the problem is even worse
> than with a LFN, and a MR, when communicating with a CN as a host (i.e.
> a MN), could perform MIPv6 RO.
>
Yes, I will correct that. 
 
> "[...] VMN/LFN"
> 
> I suggest to use the term MNN. LMNs experience also non-optimal routes
> in a NEMO. Or am I missing something?
>
Yes, you are right. As long as MR performs NEMO Basic support function,
 the route between LMN and Cn is not optimal.
 
> "IP-in-IP or other encapsulation (IPSec) causes the overhead in 
packet=20
> payload. Especially in nested NEMO with multiple levels of mobility,=20
> multiple IP-in-IP headers are added to the packet which represent a=20
> waste on bandwidth."
> 
> As I pointed out in a previous e-mail, I think that not only IP-in-IP
> encapsulation causes overhead. Routing Headers and Home Address DO, for
> example, are sort-of tunnels. Therefore, I propose to use something like
> that: "IP-in-IP or other sort-of tunnels (e.g. Routing Headers, HoA DO)
> causes overhead ...."
>
That is correct. Thanks.
 
> "MR may choose to perform RO function=20
> just with its HA if the number of different CNs is large and all CNs=20
> scatter around the Internet."
> 
> What do you mean with this sentence? I'm not sure, but performing RO
> just with the HA sounds to me like not performing RO at all.
>
Assume that there are n CNs scattering around the Internet, which means
 that there is no one single CR topologically close to all CNs. If MR
 performs the RO functions with all the CN/CRs, the overhead (the number
 of tunnels and states) in MR is O(n). By choosing HA as CR for all these
 n CNs, MR just needs to maintain one tunnel with HA. 

On the other hand, from the perspective of CR, if there are m MRs
 belonging to the same home network scattering around the Internet,
 because of the same reason, CR may also choose to forward the traffic to
HA rather than each MR. So HA play dual roles, both CR and HA here, 
though we may only put emphasis on one over the other before. 

These are all about the tradeoff. Even though MR has to go though its HA, 
because the traffic forwarded by this MR is aggregated to one 
destination, from the parent MR point of view the number of CNs (The 
child MR acts as one of MNNs.) is reduced, the better route than that in 
NEMO basic support is still possible because the parent MR could perform 
RO function. 
 
> "- Optimal or nearly optimal route between MR and CR, MR and HA as 
well=20
> as VMN/LFN and CN."
> 
> You refer along the whole document to the CR. IMHO, a general RO
> analysis document should try to avoid to think is proposed solutions,
> and face the problem in a more abstract way (I know it is really hard...
> )
>
That is what I am exactly trying to do in this draft. I apologize for 
using a confusing term, CR. Actually I should replace CR with 
Correspondent Agent (CA). CA represents a wider scope than CR used in 
several drafts. We introduce CA for several reasons:

1. There is no appropriate term for the peer of MR when performing RO. CN 
is the peer of MNN but not that of MR. CA is introduced to fill this 
gap.  

2. Under the term of CA, NEMO RO solution and NEMO Basic Support Protocol 
are perfectly united. We use this term to help us describe, compare and 
contrast between NEMO BSP and NEMO RO.
 
> "R2: The solution MUST not require modifications to any node other 
than=20
> MRs, CRs and HAs."
> 
> I agree that the RO should be transparent to the MNNs. On the other hand
> MUST may be so strong. I'm also in favour of, at least, studying
> solutions that, without breaking the transparency to non-NEMO-aware MNNs
> (e.g. LFNs), may provide some enhanced RO to NEMO-aware MNNs.
>
If I understand correctly, you are talking about the sub-optimal route 
when VMN performs MIP6 RO. Is it right? IMO, NEMO RO solution should not 
make any change to protocols running on MNN. Maybe it sounds too solution-
specific, what NEMO RO can do is to let MR broadcast the information of 
NEMO RO capability (Not very great, still require the interaction) or 
even better I see the possibility that NEMO RO can both keep the 
transparency and remove the sub-optimal route caused by MIP6 RO. So I 
strongly feel we should introduce the changes only to MR/CA/HA, one level 
above MNN. Note that CA includes the case of NEMO-aware CN. 
 
> 	Thanks a lot.
> 
> 	Kind regards,
> 
> 	Carlos J.
> 
> 
> >=20
> > Sincerely,
> > fan
> --=20
> Carlos Jes=FAs Bernardos Cano - http://www.it.uc3m.es/cjbc/
> GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 08 Oct 2004 13:03:28 +0200

Dear Fan,

	Thanks for your reply. Please see, some comments in-line

El vie, 08-10-2004 a las 06:42, Fan Zhao escribió:
>  by the traffic in NEMO Basic Support is the same as the optimal route

	OK, you are right. I was thinking in terms of overhead too ...

> though we may only put emphasis on one over the other before. 

	Yes, but if the traffic is sent to the HA, that's the operation of the
NEMO Basic Support protocol, without RO, isn't it? I agree that there
may be scenarios in which performing RO would be worse than not
performing it, so there is a tradeoff.

> NEMO basic support is still possible because the parent MR could perform 

	I don't understand this sentence (sorry about me poor understanding
;->). Do you mean, in a nested NEMO, going only through a single HA, as
a kind of RO?

> make any change to protocols running on MNN. Maybe it sounds too solution-

	I completely agree that a general and global NEMO RO solution should
not (if possible) change the protocols running on MNNs. But, OTOH, I
think that besides having such a solution, perhaps it will be worth also
to study some additional mechanisms, fully compatible with the "NEMO
global RO solution", that may enhance the performance for some MNNs.

	Thanks a lot.

	Kind Regards,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Oct 2004 11:19:55 +0200

Fan Zhao wrote:
> Correspondent Agent (CA).

Just a note to say that CA is widely known as Certificate Authority.

Alex