Subject: [nemo] RO Problem snippets

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

I went through various drafts related to RO problem statement and I
extracted the following snippets.  Is this all?

> RO problems have a common property that there is an optimized path, 
> but it cannot be used
> 
> One of NEMO-specific RO problem is a nested tunneling problem
> 
> ... it results in a non-optimal route (triangle-routing) between
> 
> By using IP-in-IP header [...] causes big overheads in packet payload
>  and bandwidth.
> 
> NEMO RO problem introduces more challenges and more difficulties than
>  MIPv6 RO problem because of nested NEMO network
> 
> Without NEMO RO solution, the performance becomes worse especially in
>  nested NEMO.
> 
> Location Privacy problem
> 
> Looping problem
> 
> "Cross-over" tunnels problem
> 
> Disconnected operation problem
> 
> Packets destined to the mobile node will have to be routed not only 
> to its home agent but also the home agent of the mobile router.
> 
> With no Nested Tunnels Optimization, we would have three 
> bi-directional nested tunnels
> 
> "Pinball" routing
> 
> BU Storm
> 
> Protocol Hacks
> 
> Computation Burden of the CN
> 
> Missing BU
> 
> Obsolete BU
> 
> The RR test prevents a MR-LFN dichotomy on the Mobile Side
> 
> The RR test has no negotiable option and is not open for extension
> 
> The HaO and RH type 2 are designed for a collocated CareOf Address.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 06 Oct 2004 18:26:18 +0200

Hi Alex,

	First, thanks for providing this list!

	Then, some minor comments/questions in-line

> > By using IP-in-IP header [...] causes big overheads in packet payload

	IMHO, not only IP-in-IP header causes big overheads. The use of routing
headers and/or Home Address DO adds also overhead (IMHO they can be seen
also as sort-of tunnels), so their use should be minimised (e.g. number
of hops in a routing header, etc)

> >  MIPv6 RO problem because of nested NEMO network

	IMHO, as I understand the Network Mobility problem (i.e. mobility of a
whole network managed by a single entity: the MR, and with the MNNs even
unaware of the mobility - at least the LFNs), I think that the
requirement of providing such a (optimised) solution that maintains this
transparency to the MNNs is also challenging. I'm not saying that the RO
solutions based on NEMO-aware MNNs are not valid, but that one of the
key differenced between Network Mobility and Terminal Mobility IMHO is
that the nodes that are actually moving can be totally unaware of the
movement (and that those nodes should profit of some route optimisation
if possible).

> > Disconnected operation problem

	I'm not sure if it's included in this snippet (probably, it is), but
the RO solutions should be also take into account communications between
nodes of different NEMOs within a nested topology. I mean, not only
ensuring that the nodes can communicate when the NEMO is disconnected
from the infrastructure, but also that this communication is somehow
optimised. BTW, I'm not sure if this makes any sense... just writing
what come up from my mind ;->

> > The HaO and RH type 2 are designed for a collocated CareOf Address.

	I'd add one more (although it's likely implicit): security

	And also a question, do we want to address the RO problem when
multihoming is also involved?

	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: Wed, 06 Oct 2004 18:57:09 +0200

Carlos Jesús Bernardos Cano wrote:
>>> By using IP-in-IP header [...] causes big overheads in packet 
>>> payload and bandwidth.
> 
> IMHO, not only IP-in-IP header causes big overheads. The use of 
> routing headers and/or Home Address DO adds also overhead (IMHO they
>  can be seen also as sort-of tunnels), so their use should be 
> minimised (e.g. number of hops in a routing header, etc)

Agree.  So talk to the author of that draft if you need it corrected,
suggest him/her a better and shorter text and you're done.

>>> NEMO RO problem introduces more challenges and more difficulties
>>>  than MIPv6 RO problem because of nested NEMO network
> 
> IMHO, as I understand the Network Mobility problem (i.e. mobility of
>  a whole network managed by a single entity: the MR, and with the
> MNNs even unaware of the mobility - at least the LFNs), I think that
> the requirement of providing such a (optimised) solution that
> maintains this transparency to the MNNs is also challenging. I'm not
> saying that the RO solutions based on NEMO-aware MNNs are not valid,
> but that one of the key differenced between Network Mobility and
> Terminal Mobility IMHO is that the nodes that are actually moving can
> be totally unaware of the movement (and that those nodes should
> profit of some route optimisation if possible).

So it is a requirement Rx that a NEMO RO solution still allows for LFN's
to not be mobility aware.

>>> Without NEMO RO solution, the performance becomes worse 
>>> especially in nested NEMO.
>>> 
>>> Location Privacy problem
>>> 
>>> Looping problem
>>> 
> I'm not sure if it's included in this snippet (probably, it is)

YEs I think it is.

> but the RO solutions should be also take into account communications
>  between nodes of different NEMOs within a nested topology. I mean, 
> not only ensuring that the nodes can communicate when the NEMO is 
> disconnected from the infrastructure, but also that this 
> communication is somehow optimised. BTW, I'm not sure if this makes 
> any sense... just writing what come up from my mind ;->

I think it does make sense but you've just written new requirements.
What's the problem itself?  What's the problem of not having optimized
communications between two nodes within the nested topology of moving
networks?

If we had a solution to the "disconnected operation problem" what part
of that potential solution would make the intra-aggregation
communication be under-optimal?

> I'd add one more (although it's likely implicit): security

Yes, so what's the snippet?

> multihoming is also involved?

Some WG members agree that the RO problem should include multihoming RO
aspects.  I personally IMHO think that multihoming aspects have not been
clarified not even for the base NEMO protocol (not that it should have);
I don't think that there's anything in "multihoming" that makes it sound
more appealing to RO than to base NEMO.

Caution: do not understand me wrong.  I am not saying that multihoming
is bad or not good.  It's good to have two egress interfaces so that if
one goes down the other takes its place.  It's just that up to now
it looked so much as a problem w/o a NEMO solution (so we get problem
and classification drafts and joined classification drafts).  But it's
not like a problem that we know how to tackle at all, there are so many
ways of addressing "multi-homing".  Or, with NEMO base, we knew it was
relying on Mobile IP...  No offence intended and IMHO.

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 06 Oct 2004 19:15:41 +0200

Hi Alex,

> suggest him/her a better and shorter text and you're done.

	OK

> to not be mobility aware

	Yes, you are right, they are requirements. I was thinking in the
overhead problem if some tunneling is used to enable this communication
within a nested NEMO.

> communication be under-optimal?

	It depends on how this solution works, but it's just the endless
problem: making the things work, but working as better as possible :->
(i.e. allow NEMOs to work disconnected, but also with minor overhead,
and so on...)

> Yes, so what's the snippet?

	Just to address the security issues of the RO problem within NEMO (some
may be the same of MIPv6, some may be new)

> relying on Mobile IP...  No offence intended and IMHO.

	I agree that the multihoming aspects in NEMO are still unclear. I just
wanted to point out that IMHO we should be careful in defining RO
solutions that are compatible with multihoming scenarios.

	Thanks for your comments and clarifications.

	Kind Regards,

	Carlos J.

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 7 Oct 2004 17:11:12 +0900

Dear all,

A few more comments.

> to not be mobility aware.

Back to my the last 2 mails, I suggest to list this (call it "mobility
transparency for MNNs" or "NEMO-enabled") as one of the metric/qualifier
to evaluate which proposition qualifies or not for a solution.  We can
only decide which is our degree of tolerance for each qualifier when we
have a good view of the potential solutions.

> aspects.  

I do personaly think there is a more immediate need for multihoming (as
defined in the NEMO WG i.e. draft-ietf-nemo-multihoming-issues) than for
RO.

> I personally IMHO think that multihoming aspects have not been

I don't understand this last bit, but I think that NEMO Basic Support
just need a few fixes for multihoming. The problem with multihoming is
that most of issues listed in draft-ietf-nemo-multihoming issues are not
NEMO-specific issues. So, a full support of the multihoming expectations
(see draft-ernst-generic-goals-and-benefits) is relying on progress made
in other working groups.

> solutions that are compatible with multihoming scenarios.

100% agree. So, that is another qualifier for RO solutions.

> relying on Mobile IP...  No offence intended and IMHO.

Thierry.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Oct 2004 15:11:54 +0200

Thierry Ernst wrote:
>>>>> NEMO RO problem introduces more challenges and more 
>>>>> difficulties than MIPv6 RO problem because of nested NEMO 
>>>>> network
>>> 
>>> IMHO, as I understand the Network Mobility problem (i.e. mobility
>>>  of a whole network managed by a single entity: the MR, and with
>>>  the MNNs even unaware of the mobility - at least the LFNs), I 
>>> think that the requirement of providing such a (optimised) 
>>> solution that maintains this transparency to the MNNs is also 
>>> challenging. I'm not saying that the RO solutions based on 
>>> NEMO-aware MNNs are not valid, but that one of the key 
>>> differenced between Network Mobility and Terminal Mobility IMHO 
>>> is that the nodes that are actually moving can be totally unaware
>>>  of the movement (and that those nodes should profit of some 
>>> route optimisation if possible).
>> 
>> So it is a requirement Rx that a NEMO RO solution still allows for
>>  LFN's to not be mobility aware.
> 
> Back to my the last 2 mails, I suggest to list this (call it 
> "mobility transparency for MNNs" or "NEMO-enabled") as one of the 
> metric/qualifier to evaluate which proposition qualifies or not for a
>  solution.  We can only decide which is our degree of tolerance for 
> each qualifier when we have a good view of the potential solutions.

Thierry, partially ahree.  Let me say just the not part.  I don't think
we need to metricize/qualify/classify/evaluate solutions.  I think the
Generic RO Model draft and the taxonomy already have large parts that
generalize and qualify the solutions.

I think we need to define the problem in the problem statement draft.
That could be as short as 5 pages.

I think we should turn all explanations of solutions as support of the
problem itself, not as precursors of requirements, or as evaluators
which decide which RO solution is best.

For example, one way that it could be written is: "The problem is that
paths are very long.  Some NEMO RO mechanisms propose that MR updates
the CN's BC not only with its CoA but with its MNP too.  This however
involves a security risk regarding all hosts with addresses configured
from that prefix.  To avoid these risks, the MR may use RR tests for
each address in the MNP; this behaviour is not feasible due to large
number of full 128bit addresses possible out of a 64bit prefix..."  This
leaves us with a standing problem, and not with a selected solution.

Better yet: the problem is that the paths are very long.  To find
optimal paths, some mechanisms propose to: (1) send route updates to AR
but this is not feasible because, (2) send MNP to CN but this is not
feasible because, (3) send XYZ to ZYX but this is not feasible because.

I do not think that the problem statement draft should contain a
reasoning like: RO mechanism 1 offers mobility transparency and no
security, while RO mechanism 2 offers security with no secrecy
transparency, so we prefer mechanism 1.  It is much too early for this.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 8 Oct 2004 12:49:11 +0900

Hi,

> generalize and qualify the solutions.

I propose something more synthetical, but I don't see the motivation of
your opposition ("because there is already attempts to do so in
drafts"). Well, we are discussing about what the WG document should
content, aren't we ?

> feasible because, (3) send XYZ to ZYX but this is not feasible because.

I think that's also going too much into the analysis of the solutions.
The only way to do this from the perspective of the solutions is to
build a (complete) taxonomy of the solutions (what Thubert's draft
attempts at doing) but the problem here is that the taxonomy can only
include already made solutions. Better solutions may come later, once
the problem is well-known for everyone ... 

So, I think that the analysis of the solution space can only start once
we have realized the following 3 steps, in this order:

1. the problem (where routing is not optmized, why, what is the cause
and consequence [packet overhead, longer dely, ...]

2. the design goals (mimimal overhead, minimal delay, minimal number of
"mobility  hops", ...)

3. metrics/qualifiers

> transparency, so we prefer mechanism 1.  It is much too early for this.

Definitely agree with this.

Thierry.