Subject: [nemo] NEMO RO Problem

From: "Fan Zhao" <[email-masked]>
Date: Sun, 3 Oct 2004 23:57:35 -0700 (PDT)

Dear all,

I wrote a document about NEMO RO problem, please click the 
following link to see the details:
http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.txt
http://wwwcsif.cs.ucdavis.edu/~zhaofa/NEMORO/ROProblem.doc

This document benefits from a lot of discussions and drafts.
It is still a preliminary version, so there are still a lot 
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 
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.

Sincerely,
fan

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Oct 2004 17:27:44 +0200

Fan Zhao wrote:

> Dear all,
> 
> I wrote a document about NEMO RO problem, please click the following 
> link to see the details: 
> This document benefits from a lot of discussions and drafts. It is 
> still a preliminary version, so there are still a lot 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 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.

Dear Fan, I've read the document and have comments on it.

Please submit it as an Internet Draft, should be easy.  If problems
formatting, boilerplate, deadlines, whatever - I can help.

The document is longish and tries to do many things.  Not only it looks
at defining a NEMO problem in great detail, but it also offers goals for
RO, Rx requirements and even RO performance evaluation metrics.

> As it has been understood for a long time that the routing path in 
> the Internet is asymmetric

The path taken by packets of the same session between two fixed
communicating ends depends on the order of the src and dst fields.  Same
end's outgoing and incoming packets may take different paths.  Also,
packets of the same session and in the same direction, may take
different paths, varying with time and network load.

> More preciously, location

precisely

> Although in MIPv6 the Care-of-Address represents the location of 
> attachment to the Internet, a single Care-of-Address is not 
> sufficient any more to represent the location of VMN/MR in nested 
> NEMO because it sometimes represents the point of attachment to the 
> upper level of mobile network.

I don't understand this.  Why is it necessary to have more than one
CoA  to represent the location of a VMN/MR in a nested NEMO?

> The “optimal route” inside the NEMO network is formed by the decision
>  of each MR along the outbound and inbound path

An "optimal route" is formed by route segments, not by "decisions" no?

> When MRi associates with MRj, it may choose MRj as the default router
> 
Yes ok, but I don't know where this leads to.  "Looping problems"?

> The inbound path inside the nested NEMO may be different from the 
> outbound path. However, since the route inside the NEMO network does
>  not involve HA, the optimal route is based on the decision of each 
> MR.

...is based only on the decision of MR's, and not that of the remote HA's.

> If the intersection of p1 and p2 is not empty, denoted by <MR_1,i1, 
> MR_1,i2, …, MR_1,ik> = <MR_2,j1, MR_2,j2, …, MR_2,jk> where i1 < i2 <
>  … < ik and j1 < j2 < … < jk.

If it is not empty then what?  Premature end?

> Ideally the optimal path between node1 and node2 is <MR_1,1, MR_1,2,
>  …, MR_1,i1, …, MR_2,2, MR_2,1>.

I do not see what the second indices represent (1,2,i1,2,1).  Maybe a
graphical picture would be suggestive.

What is in plain English the optimal path?  The one that is the
intersection of the two sets?

> Worse than MIPv6, in nested NEMO network the packets are forwarded to
>  multiple intermediate boxes

... (the HA's)

> As a TCP/UDP connection is identified by a 4-tuple <source IP 
> address, source port, destination IP address, destination port>, in 
> order to maintain the continuous session, the end point must use the 
> same IP addresses during the session.

Not only for TCP connections are the stable IP addresses needed, but
also for ICMP (ping).

> As IP address perfectly represents both identity and location of end
>  host in the fixed network, we usually just put emphasis on one and 
> sometimes even mix their meanings. However, in the mobile network 
> environment, we need to represent the binding between identity and 
> location that is what the binding between home- address and 
> care-of-address does.

> Similar with MIPv4 and MIPv6, NEMO focuses on the solution in data 
> plane rather than in the signaling plane

What's the data and signalling planes?  Is a BU signalling plane?

> a RO solution in data plane may qualify as a necessary step before

An RO solution would most probably use BU's, is this data or signalling?

> a nature extension

natural...

> MR may choose to perform RO function just with its HA if the number 
> of different CNs is large and all CNs scatter around the Internet

Is this equivalent to saying MR may choose to _not_ do RO?  I don't see
how MR does RO only with its HA.

> 1.7.4 Security vs. optimal route In NEMO basic support, it is very 
> possible that there pre-exists the security association between MR 
> and HA, which helps resist the various attack. However in NMEO RO 
> solution, as the MR-HA tunnel may not exist and there is no 
> pre-existing security association between two entities from the 
> different domains, it is more challenging to maintain the same 
> security strength as in NEMO basic support.

An insecure RO solution for mobile hosts risks a CN and a MH.  An
insecure RO solution for NEMO risks not only CN and MH but also the
bunch of LFN's in the moving network.

It is difficult to do per-host RR tests (as currently RFC3775 does) for
all the hosts within the MNP.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 07 Oct 2004 12:37:15 +0200

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).

> 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.

"NEMO basic support protocol [...] However, it results in a non-optimal
(We will define 
<93>optimal<94> and <93>non-optimal<94> later.) route (triangle-routing)
between
 
VMN/LFN/MR and CN with a non-zero and even very large probability, 
which causes the significant communication delay."

IMHO, with NEMO Basic Support (BTW, I suggest to use capital letters in
"NEMO Basic Support"), the route experienced by the traffic is always
non-optimal (of course, the severeness of this sub-optimal routing
depends on the scenario).
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.

"[...] VMN/LFN"

I suggest to use the term MNN. LMNs experience also non-optimal routes
in a NEMO. Or am I missing something?

"IP-in-IP or other encapsulation (IPSec) causes the overhead in packet 
payload. Especially in nested NEMO with multiple levels of mobility, 
multiple IP-in-IP headers are added to the packet which represent a 
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 ...."

"MR may choose to perform RO function 
just with its HA if the number of different CNs is large and all CNs 
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.

"- Optimal or nearly optimal route between MR and CR, MR and HA as well 
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...
)

"R2: The solution MUST not require modifications to any node other than 
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.

	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: Masafumi Watari <[email-masked]>
Date: Sat, 16 Oct 2004 00:06:31 +0900 (JST)

Hello Carlos,

One quick question I had regarding your comment:

On Thu, 07 Oct 2004 12:37:15 +0200,

> the edition if you want to submit this input as I-D.

<snip>

> just with the HA sounds to me like not performing RO at all.

Are you suggesting that bypassing of all HAs on the way as a
requirement for the solution in RO?  For example, RRH always uses the
HA of the sub-MR, while bypassing the HA of the root-MR.

Masafumi Watari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 15 Oct 2004 18:01:49 +0200

Hi Masafumi,

	Please, see my reply inline.

> HA of the sub-MR, while bypassing the HA of the root-MR.

	No, I'm not suggesting that. I made that comment thinking in a
non-nested NEMO. It sounded to me that if MR decides to perform some RO
function just with its HA, it is like not performing RO at all, because
packets follow the same path than when NEMO Basic Support is used (i.e.
CN<->HA<->MR<->MNN). Of course, in a nested NEMO scenario, if packets
only traverse one HA instead of every MR's HA, these packets are
experiencing some RO. BTW, IMHO the ideal solution would be bypassing
all the HAs, but I don't know if such solution would be feasible or not
while maintaining the transparency to the MNNs. Therefore, I wasn't
suggesting that requirement.

	Kind regards,

	Carlos J.

---

From: Masafumi Watari <[email-masked]>
Date: Thu, 21 Oct 2004 01:31:24 +0900 (JST)

Hello,

Sorry for my delayed reply.

On Fri, 15 Oct 2004 18:01:49 +0200,

> suggesting that requirement.

Okay, I understand.  I also agree actually.  I guess that RO solution
could have different levels; for example, solution which bypass all
HAs or only the HAs of other MRs on the way.

But my concern is that going through even one HA can still be a long
path depending on the location so I don't know.  MIP6 bypass all HAs
so I guess we can with NEMO as well...

Masafumi Watari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 21 Oct 2004 11:01:00 +0200

Hi Masafumi,

<snip>

> so I guess we can with NEMO as well...

Yes, I agree on that. IMHO, we definitely have to look for a solution
that bypass all the HAs, but the problem I see is that it can be maybe
(hopefully not) hard to get if transparency to MNNs and CNs is
considered a strong requirement (as I think, IMHO, it should be, for a
general solution).

Carlos