Subject: [nemo] Route Optimization in Nemo

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 25 Oct 2002 17:12:48 +0100

Hi

Some time ago, I published
http://www.ietf.org/internet-drafts/draft-thubert-nemo-ro-taxonomy-00.tx
t 
Which is an attempt to start a discussion on Route Optimization in the
Nemo context.

I wish to debate issues on this topic if anybody is interested. At the
moment, the goal is to refine our understanding of the problem space.
 
Pascal Thubert

---

From: Takeshi TANAKA <[email-masked]>
Date: Mon, 28 Oct 2002 15:10:06 +0800

Hi Pascal, 

We are also interested in the RO problem of NEMO especially in nested
case.  We see that nested mobile nodes is inevitable in a practical
world deployment scenario.

First of, some comments on your RO-Taxonomy draft:

> 2.1 Nested tunnels optimization
> Such a solution introduces the following problems:
> "Pinball" routing ...
> Packet size ...

I think the problem of nested tunnels can be further broken down into:
"pinball" routing
- HA/MR processing resources consumption
- increased latency
increased in packet size
- wireless link bandwidth consumption
- network resource consumption
- more packet fragmentation(by each termination)

> The potential approaches for avoiding the nesting of tunnels include:
> Route Aggregation ...
> Surrogate ...
> Internal Routing and gateway ...
> RRH ...
Routing header can be used to avoid problems you listed, but I think
naming the paragraph RRH is putting adding presumptions on the method of
constructing the Routing Header, since there could be other method to
collect information needed to construct routing header.

> 3. MR-to-CN
>  ...
>  accept the risk.  If not, the optimization may be limited to
>  triangular routing MR->CN->HA->MR.
> ...
I think packet delivery path in this case will not be a triangular
routing(MR->CN->HA->MR), but "dog-leg" routing (MR->HA->CN, CN->HA->MR).

> 6. Conclusion
> ...MIPv6 seems to be...more difficult to probide a Nemo solution
> with backward compatibility, since: ...
> 2) The RR test has no negotiable option and is not open for extension,
What does this sentence mean?
In MIPv6 draft #18, each messages in RR test can contain some mobility
option field.  These option fields can be used to carry other
information. In addition, we can modify the way each cookie is generated
at CN side if necessary.

For your "call for debate" in laying down the RO requirements, it is a
good idea.  We will try to write down something concrete for futher
discussion in the mailing list.

On a side note, we think there wont be any time slots for discussion
about RO solutions in the upcoming IETF meeting, but if we can laid down
some set of requirements for RO, perhaps we can request for a time slot
to discuss the problem scope of RO?

------------
Takeshi

---

From: Alexandru Petrescu<[email-masked]>
Date: 28 Oct 2002 18:49:53 +0100

> discussion in the mailing list.

Yes, it's good to have a rough idea about what are the RO
implications.  And I'm also interested in looking into the RO
requirements.  If I were to start a document, I would start with
defining the problem of RO before trying the requirements.  For
example a certain number of points of triangular routing could be
feasible, but no more than n.  So we first must know exactly what is
"number of points of triangular routing".

Me too I'm interested in that, but it's maybe for later.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: 28 Oct 2002 19:03:14 +0100

> Me too I'm interested in that, but it's maybe for later.

Sorry for following up on my own email.

A good definition of the RO space is also about stating what are the
non-RO implications to upper layers.  For example, if MN uses TCP, and
if sending packets through the HA to CN, but receiving packets
straight from CN, then this very much looks like an "assymetric" link,
and I think there was recently an iab draft on why it's not good for
TCP to have assymetric links.

I think this is also about RO, but again, for later, maybe I'm posting
too much.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 28 Oct 2002 14:25:57 -0800

IMHO, security is *the* issue for Nemo RO. RR depends on the routing fabric, and
with NEMO, the routing fabric is changing. 

            jak

---

From: Alexandru Petrescu<[email-masked]>
Date: 29 Oct 2002 16:58:43 +0100

"James Kempf" <[email-masked]> writes:
> IMHO, security is *the* issue for Nemo RO. RR depends on the routing
> fabric, and with NEMO, the routing fabric is changing.

Aha, that is well said, the routing fabric seems to be changing,
because mobile networks nest one under the other and as such, the
deepest mobile network will have a set of mobile networks above it
before reaching the fixed infrastructure.  And that set of mobile
networks are changing.

And, while with the current RR tests an MH can think that paths are
secure, in nested mobility the deepest MR can not be sure that one
middle-level mobile network is trustful.  But if I assume that every
MR in this nested structure has done AAA before obtaining
connectivity, then the deepest MR will have less reason to worry.

But yes, IMHO too, RR tests and security are important issues for NEMO
RO for the fact that the normal RR is assuming the CoA and the HoA are
in the same machine (MH), and in the NEMO case, the CoA is of MR and
the HoA is of an LFN, so LFN and MR must trust each other.

What do you think?

Alex