Subject: [nemo] RO Taxonomy

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 21 Sep 2004 13:43:29 +0800

Hello all,

In the San Diego meeting, there has been mention of the RO Problem Space
Analysis WG item.  As most should be aware, Pascal, Molteni, Ohnishi,
Eun-Kyoung and myself have been working (or had worked on) the RO
Taxonomy draft.  I believe I am speaking for the co-authors as well when
I say that it is my intention to have this piece of work fulfill the
role of the working group item.  However, I remember there has been
comment on the draft lacking some aspects, and perhaps too solution
specific.

It is thus my intention to update the draft to best meet the WG
requirement. Like to ask the WG on their opinions of what is still
lacking for the draft to be put forth as the RO Problem Space analysis. 
All comments are greatly appreciated.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Wed, 22 Sep 2004 10:05:44 +0800

On Wed, 2004-09-22 at 07:02, Vijay Devarapalli wrote:
> the current draft seems to havd expired.
> 

Right, another reason for us to update it ;)
Please find the draft in
http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-ro-taxonomy-02.txt

/rgds
/cwng

> vijay
> Chan-Wah Ng wrote:

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Sep 2004 14:28:06 +0200

The Charter item does not require for an RO Taxonomy (classification).
It requires for a problem definition first so let's define the problem.

Chan-Wah Ng wrote:
>>> As most should be aware, Pascal, Molteni, Ohnishi, Eun-Kyoung and
>>>  myself have been working (or had worked on) the RO Taxonomy 
>>> draft.  I believe I am speaking for the co-authors as well when I
>>>  say that it is my intention

If you were speaking for your co-authors as well you would have said "it
is our intention" and not "it is my intention".  Whose intention is it
in fact?

>>> to have this piece of work fulfill the role of the working group 
>>> item.

I am against this draft becoming the NEMO WG item for route
optimization.  In short, it is more like describing solutions than
actually describing problems, it spends much text in classifying those
solutions, "taxonomy".  I have more arguments below.

>>> However, I remember there has been comment on the draft lacking 
>>> some aspects, and perhaps too solution specific.

I agree.

>>> requirement.

So start with the respective charter item.  I think some parts of the
draft address the charter item while some others go way beyond it.

>>> Like to ask the WG on their opinions of what is still lacking for
>>>  the draft to be put forth as the RO Problem Space analysis. All 
>>> comments are greatly appreciated.

Thanks for asking.

The respective charter item is the following:

> An informational document which specifies a detailed problem 
> statement for route optimization and looks at various approaches to 
> solving this problem.

So: first describe the problem.  The problem is that paths are
artificially long.  They are longer than if MIP6 were not used.  The
problem is worse than with Mobile IPv6 for hosts because multiple HA's
are involved (MIP6 for hosts involves "triangular" paths, MIP6 for
routers involves "multi-angular" paths).  Your "Pinball" routing is your
figurative way of understanding my "multi-angular" routing.  I suggest
the latter term for the terminology document.

The NEMO RO problem is not the same as the multiple encapsulation
problem.  The too-big-packets-because-too-many-headers problem has
solutions like compress-those-headers aka ROHC.  It may be that a NEMO
RO solution reduces the headers size too but that's only a side effect.
  Solving the NEMO RO problem should at least reduce the path lengths but
it is not requiring to reduce the packet sizes.

The charter does not require to define Mobility Transparency either,
while the draft does it in three versions.

The charter does not require dealing with multi-homing and NEMO RO, the
draft deals.

> This document will look into the issues and tradeoffs involved in 
> making the network's movement visible to some nodes, by optionally 
> making them "NEMO aware".

The draft describes (in section Mobility transparency and RO) how some
nodes are NEMO-aware.  That's ok and needed.  But I don't see the good
description satisfying the charter.

First, "end-to-end" principle is mentioned, should have the reference.
I don't understand how not passing mobility from MR to CN breaks the e2e
principle.

Second, having nodes that are NEMO-aware is used as a solution to
achieve "mobility transparency".  The charter does not require "mobility
transparency".  It requires a description of the issues and tradeoffs
involved making the network's movement visible to some nodes,
NEMO-aware.  Id' better write it like this:

"In order to develop a solution for the problem describe in this
document, it might be needed that some nodes become NEMO aware.  The CN
may be required to interpret bindings between a full address and a
partial prefix (instead of between 2 full addresses).  The advantage of
this is that it may help achieve RO for all LFN's under MR but the
tradeoffs are: (1) successful attackers may reroute traffic of an entire
prefix (2) it is difficult to use RR tests for all addresses within a
prefix."

This would be the idea how to write it, but more detailed it should be.

> The interaction between route optimization and IP routing will also 
> be described in this document.

So it should.

> Furthermore, security considerations for the various approaches will
>  also be considered.

So it should.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 30 Sep 2004 16:20:28 +0200

Chan-Wah Ng wrote:
> Like to ask the WG on their opinions of what is still lacking for the
>  draft to be put forth as the RO Problem Space analysis. All comments
>  are greatly appreciated.

Dear Chan-Wah, I've read the draft in more detail and I have several
comments.  I've hesitated before sending them, because they may look too
harsh, but then you say that all comments are greatly appreciated so I'm
sending them.  I think the draft has some good parts and some badly
explained parts and some unnecessary parts.

> between nodes in a mobile network and their correspodnet nodes.

correspondent.

> route optimization with corresponding nodes initiated bu mobile

by for bu.

> 3.  performing RO over the routing infrastructure involving 
> optimizing the route between two routers situated near to each end 
> point, instead of end-to-end;

Last words should be "instead of end-to-end RO" and "end-to-end RO"
should be defined somewhere.  Where is it defined?  google "end-to-end"
the first entry is right so you're lucky.

"End-to-end" is like saying that your app talks to my app, and that your
app does not talk to my kernel.  _That_ is "end-to-end".  Ping is not
"end-to-end" because your app talks to my kernel.  But better rely on
that paper's explanation and on that of RFC 3724 "The Rise of the Middle
and the Future of End-to-End" and of RFC 3439 "Architectural Guidelines".

"End-to-end" is not adapted for what you're trying to say, to my taste.
  I think what you're trying to say with "end-to-end RO" is more like
"keep the network dumb" or "empower the end user" or "keep soft state in
the network" or "fate-sharing" similar.  I don't have a reference handy
for this, but the term "end-to-end" is so much used and so badly so
often that I'd take no risk and not use it at all.

> Lastly, route optimizations involving nested mobile networks are 
> explored. This involves minimizing the number of tunnels required 
> when there is multiple levels of nesting.

One can achieve minimal tunnels without actually offering shorter paths,
with ROHC.  The two goals are different.

> This scenario is useful when a lot of MNNs in a mobile network is 
> communicating with a few

"MNN's are communicating", not the "lot is communicating".

> In such cases the MR only needs to send one binding update (BU) to 
> optimized the route between CN and a few MNNs.

"optimize" instead.

If an MNN is actually a VMN, it is not sufficient for MR to send a BU to
CN, the comm still goes to that VMN's HA.  Better use "LFN" instead of
"MNN".

> A major issue with this form of optimization is that the end-to-end 
> principle of the MIPv6 Reverse Routability (RR) test is broken.

What is the "e2e principle of the MIPv6 RR test(s)"?  RFC 3775 Mobile
IPv6 has no such principle...  RFC 3775 Mobile IPv6 has another
end-to-end mentioning of end-to-end IPsec, but it is not an end-to-end RR.

So the reader is not convinced this is a "major issue"; and also it's
called Return not Reverse.

> If not, the optimization may be limited to triangular routing 
> MR->CN->HA->MR.

better: "optimization would be limited to only eliminating the CN-HA and
HA-MR edges of the MR-CN-HA triangular path."

What's "triangular routing" by the way?  Is it that all 3 edges are used
to send packets?  Is it that only two edges are used so? (a prior
version of MIP6 was wrongly using sending packets MN-CN and receiving
CN-HA-MN, so that was "triangular"; current MIP6 w/o RO is bi-angular
path because there's no CN-MN path and there's CN-HA and HA-MN).

> When a Mobile Node visits a Mobile Network, the best Route 
> Optimization is obtained if the path in the Infrastructure is the 
> same as if the Mobile Network was attached at the attachment point of
>  the Mobile Router (i.e., there is not additional Tunneling that is 
> linked to NEMO).

I don't understand this.  The Mobile Network _is_ attached at the
attachment point of the Mobile Router, yet routes are not optimal.

> In this model, both the LFN behind the MR and the Correspondent can 
> be MIP agnostic.

The CN can not be MIP agnostic because RFC 3775 requires it to be a MIP
believer.  The CN may be NEMO-agnostic, and not be NEMO-aware.

> The goal is to locate the closest (BGP) gateway for a Correspondent 
> that is located outside of the domain, and tunnel between the MR and
>  that gateway as opposed to the Home Agent for that specific 
> Correspondent.

There is a reference for BGP and mobile networks at a this year's NANOG
by Cisco I believe, find it.

"4.2 Correspondent Router"

But earlier the draft was talking about "C-side routers".  What's the
difference?

> The Core Routers for the network of the Correspondent are all CRs.

Yes, because CR stands for Core Router.  Or?

> M-side routers

What do you call an edge router to which MR visits and that also serves
a CN?  Is it a CM-side router?

What is an MR to which two MR's visit whose LFN's talk to each other?
is this AR a CM-side router?

> 5.1 Nested Tunnels Optimization ...
> 
> With no Nested Tunnels Optimization, we would have three 
> bi-directional nested tunnels
> 
> Such a solution introduces the following problems:
> 
> "Pinball" routing

What _is_ Nested Tunnels Optimization?

What "solution" introduces the pinball routing?

By your logic it would mean that Nested Tunnels Optimization is a
solution to the problem of having three bi-directional nested tunnels
and this solution (supposedly eliminating the too many tunnels) induces
pinball routing!  Is this what is meant?

> On the other hand, with a Nested Tunnel Optimization, we would have 
> at most one bi-directional tunnel outside the Mobile Network

Partially agree.  It is possible to have such a NT Optimization and
haveat most zero (instead of one) tunnels, at least within an
aggregation of moving networks.  Zero-encapsulation RO for nested NEMO.

> Mobile Aggregation
> 
> This model applies to a category of problems were the Mobile Networks
>  share a same administration and consistently move together (e.g. a 
> fleet at sea). In this model, there is a cascade of Home Agents.

This is called a "large moving network" and it has only one HA and one TLMR.

By any chance, is "Mobile Aggregation" having a direct link with the
"home network models" draft?

> The Reverse Routing Header (RRH) approach avoids the multiple 
> encapsulation

Depends what you call encapsulation.  RRH, and any routing header for
that matter, is already a form of encapsulation because it adds data
fields to a pure base header.  Of course, multiple encapsulation by
adding multiple 40byte base headers is worse than multiple encapsulation
by adding only 16byte addresses, but still, one can't say RRH is
avoiding multiple encapsulation.

> The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo is
>  to MIPv6.

So use AR-PD with HMIPv6 and HA-PD with NEMO.

The text on the prefix delegation approach should describe first HA-PD
(HA sending prefixes to MR) and second AR-PD (AR sending prefixes to MR).

> Although optimization  within a mobile network is not within the 
> charter of the NEMO working group, it might be insightful to discuss
>  such optimizations.

Optimization within a moving network is as much in the NEMO charter as
optimization outside of it: define the problem.

> These approaches are generally difficult to secure unless all the 
> Mobile Routers and Visiting Mobile Node belong to a same 
> administrative domain and share predefined Security Associations.

Finally something to which I agree wholehartedly.  Something to which
can be added "true if no widely deployed security infrastructure".

> 1.  Binding Update storm

Is this stormy or more windy?  Because I know a paper simulating this
stuff and finding it to be more windy.

> 4.  Missing BU
> 
> If a CN doesn't receive the full set of PSBU sent by the MR, it will 
> not be able to infer the full path to a node inside the nested Mobile
>  Network.  The RH will be incomplete and the packet may or may not be
>  delivered.

Ok but don't try to make the BU-BAck exchanges any more reliable than
currently is.

> 6.3 Mobile Access router selection

Remove this.  This is CARD.  This is specified, Seamoby is closed.

> 6.5 Multihoming stuff

Remove this, it's not required by this charter item.

> 6.5 Mobility Transparency

Remove this, it's not required by this charter item.

However, the effects of some nodes being NEMO-aware is required and this
section has discussion about this.  So maybe write a new section keeping
those.

> 1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,

What is a "MR-LFN dichotomy"?

Alex