Subject: [nemo] Generic RO Tunnel (ROT) Model

From: "Jongkeun Na" <[email-masked]>
Date: Thu, 5 Aug 2004 10:50:05 +0900

Hello,

Generic RO Tunnel (ROT) Model was introduced in
http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt

However, unfortunately I've not received any comments on this. So I re-state
the purpose of this work and once again solicit your comments. Your feedback
is very important because I want to confirm that this work is directed to
its right way.

The draft outlines generic RO model for NEMO extended support. I think that
it can provide a useful framework in that defining RO problem spaces,
evaluating the existing RO solutions and discussing a bunch of related RO
issues. As you know, RO problem & solution is some complex so I think we
need a well defined RO model to enable us to find optimal RO solution.

Also, Section 4 in the draft is mentioning on the need of a unified RO
solution. I guess that this point is important in up-coming discussion of WG
about RO. please don't hesitate in expressing your thought. Any feedback is
welcome. 

Regards,

Jongkeun

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Aug 2004 16:53:26 +0200

Jongkeun Na wrote:
> _http://www.ietf.org/internet-drafts/draft-na-nemo-gen-ro-model-00.txt_
> 
> 
> However, unfortunately I’ve not received any comments on this. So I 
> re-state the purpose of this work and once again solicit your 
> comments. Your feedback is very important because I want to confirm 
> that this work is directed to its right way.

Hello Jongkeun,

Thanks to you and co-authors (Seongho Cho, Chongkwon Kim, Changhoi Koo)
for providing this generic RO model.  I've just read through it.

The draft assumes that RO can only be achieved by using tunnels of some
sort.

It proposes a generic architecture (boxes, functions and tunnel types)
of Tunnel Endpoints, Switchers and Relays.  These - still generic -
boxes can perform generic functions/attributes such as Initiator,
Responder, Trigger Source, Discovery and, moreover, tunnels can be of
several types: Simple, Switched and Relayed.

It subsequently maps RRH, HMIPv6, VIP, PCH, ORC, ARO and other RO
schemes on this conceptual architecture.  So this may be a useful RO
taxonomy.

I do not understand why is it assumed (as ORC does) that after RO there
will still be encapsulation.  I thought one of the main goals of
employing RO is to eliminate encapsulation altogether.  I may be wrong.

> [achieve] unified RO in NEMO

I'd say "interoperable" RO for MR, instead of "unified".

> spaces, evaluating the existing RO solutions and discussing a bunch 
> of related RO issues. As you know, RO problem & solution is some 
> complex so

I think it would be useful to define the RO problem itself first, and
what would an RO solution do.

Even define what "route" is in this context, what an "optimal route" is,
etc.

For example:

route: a sequence of IP hops between LFN and CN.

optimal route: a route shorter than through-HA route.

shortest route: the smallest number of IP hops.  The optimal route is
not necessarily the optimal route.

RO problem: find an optimal route.

RO solution for NEMO: a set of protocol message exchanges after which
LFN and CN securely communicate at application level over optimal routes
(no encapsulation and not through HA).

Or something like that.

> I think we need a well defined RO model to enable us to find optimal 
> RO solution.

Yes.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 6 Aug 2004 08:31:47 +0900

Dear all,

I personaly find the draft and the model interesting from an analytical
point of view, but I'm not sure it would be a useful model for the
analysis that we need to carry on in this WG. But let's see.

Would you motivate the need for such an abstraction model in this WG ?

How would you use it ?

What are you plans in using this model ?

Why do you compare VIP ? (if you want to compare host mobility support,
there are tons if them, so why VIP and not other ?

> > that this work is directed to its right way.

Defining a model is good idea and would help. However, I'm concerned
that this model focuses too much on tunneling and on MIP6-based
solutons.So, it might be generic for solutions that use tunneling, but
not generic enough for solutions that  don't rely on tunneling (RO
between 2 VMNs in the same NEMO for instance). So, we miss the complete
picture.

> I'd say "interoperable" RO for MR, instead of "unified".

Well, unified would be a nice goal. But I doubt it could be achieved
easily. In any case, we need to define the RO problem first. Where do we need RO ?

> (no encapsulation and not through HA).

I agree that would help to define the problem statement that we are
still lacking in the NEMO WG.

> > I think we need a well defined RO model to enable us to find optimal 

Agree.  Before analyzing the solution space, we need to analyze the
problem space. Where do we need RO ? Actualy, Watari provided good input
in his presentation.

Thierry.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 06 Aug 2004 04:16:30 +0200

Hi Jongkeun,

	Thanks for providing this draft. I think that's very important to have
some previous analysis of the RO problem if we finally face it. Some
comments (actually some - if not all - have been already pointed by Alex
and Thierry):

	- I think that a RO solution in NEMO is not restricted to two entities
establishing a tunnel between them. At this point of time, in which it
is not very clear how to provide RO in NEMO (IMHO because it is not
completely clear in which situations we need/it's worth to have RO), we
should not restrict us to a certain type of solutions. IMHO, being so
focused in RO provided by some kind of IP tunnel, also makes the
terminology difficult to understand in the first look at the draft.
Maybe it could be redefined or simplified.

	- IMHO a model should be more general, more abstract, not so specific.
I think that it would be easier to understand the problem and find the
solutions if they were presented in a more abstract way.

	- As Thierry has said, I think that it's more important to have a clear
view of the problem space prior to trying to handle the solution space.
IMHO the problem space should take also into account the scenarios in
which NEMO is expected to be involved to, I mean, we can make a sort of
taxonomy of situations in which RO would be needed (LFN talking to a CN
outside the NEMO, LFN talking to another LFN in a different NEMO,
nesting, and so on...), but I think that it's also important to evaluate
which of these situations are more likely to happen.

	Thanks,

C.J.

P.S. How are you edited/generated the i-d. I don't know if it only
happens to me, but it seems that the left margin is bigger than it
should be. If I try to print it, it looks weird, and difficult to read.

El jue, 05-08-2004 a las 03:50, Jongkeun Na escribió:
> The draft outlines generic RO model for NEMO extended support. I think
> that it can provide a useful framework in that defining RO problem
> spaces, evaluating the existing RO solutions and discussing a bunch of
> related RO issues. As you know, RO problem & solution is some complex
> so I think we need a well defined RO model to enable us to find
> optimal RO solution.
> 
> solution. I guess that this point is important in up-coming discussion
> of WG about RO. please don’t hesitate in expressing your thought. Any
> feedback is welcome. 
> 
>  
> 
> Regards,
> 
> Jongkeun
> 
>  
-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40

---

From: "Jongkeun Na" <[email-masked]>
Date: Fri, 6 Aug 2004 12:47:04 +0900

Hi Alex, 
Thank you for your comments. See my response in line.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Thursday, August 05, 2004 11:53 PM
> To: Jongkeun Na
> Cc: [email-masked]
> Subject: Re: [nemo] Generic RO Tunnel (ROT) Model
> 
> Jongkeun Na wrote:
> > However, unfortunately I've not received any comments on this. So I
IP tunneling is a basic mechanism to re-route packets at some intermediate
points without any modification on the original packets. I thought that it
can well express the purpose of RO such as packet redirection service. And,
the tunneling contains most of procedures involved in RO, negotiation
between two entities, the method of transferring packets, etc. So, I think
that eliminating encapsulation or other optimizations can be considered
under the concept of IP tunneling.

> I'd say "interoperable" RO for MR, instead of "unified".
Okay, it is not bad to me. But, I saw we can make a universal solution in
working on the unified RO for some main RO problems like RO in the
infrastructure, nested RO.
Our another draft addresses this point. This is still not discussed in NEMO
ML, but here are some parts of content for your understanding: 
"we propose a route optimization scheme based on PCH(Path Control Header)
piggybacking by HA. The scheme is a unified solution that can solve a
several types of route optimization problem with applying the same principle
to the routing facilities such as HA, MR and Correspondent Router(CR). In
the proposed scheme, HA does piggyback PCH on the packet which is reversely
forwarded from MR through bi-directional MR-HA tunnel. PCH is a hop-by-hop
option header so that it can be processed by all of the routing facilities
on the path that is from HA to CN. HA forwards the packet with PCH to CN for
the route optimization. CR on the path makes a RO(Route Optimization) tunnel
between MR and itself using the information which is the CoA of MR that is
contained in PCH."
Please see
http://www.ietf.org/internet-drafts/draft-na-nemo-path-control-header-00.txt
for details.

> Even define what "route" is in this context, what an "optimal route" is,

Good point, I'd like to share with you. We need some terminologies & basic
performance metrics to discuss RO problems, evaluate RO solutions.

> (no encapsulation and not through HA).
Good example. IMHO, definitely defining some of those things is a base work
that is required to elaborate our RO work. Thanks.

---

From: "Jongkeun Na" <[email-masked]>
Date: Fri, 6 Aug 2004 14:41:14 +0900

Hi Thierry,
Thank you for your comments. Some thoughts are in line.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Thierry Ernst
> Sent: Friday, August 06, 2004 8:32 AM
> To: [email-masked]
IMHO, it is to see a forest, not a tree. RO problem has various situations
to be fixed to diminish inefficient IP routing incurred by mobility.
Case-by-case approach in handling RO problem & solution is not enough to get
a big picture.

> How would you use it ?
In my opinion, we can use it as a descriptive framework to describe some
sort of things like which situation want RO, which entities involved in RO,
how RO can be achieved, etc. Second, it could be used to evaluate some
existing RO solutions, in what range does it support RO, does it satisfy the
minimum requirement in performance or some operational restrictions. Lastly,
it can inspire new universal RO solution.

> What are you plans in using this model ?
Frankly speaking, currently not planed but I think we need to come up with
on what plan is useful to WG together.
> there are tons if them, so why VIP and not other ?
I don't understand what's your point. 

> between 2 VMNs in the same NEMO for instance). So, we miss the complete
IMHO, the same principle & structure can be applied into ROT model if VMN or
CN can be a Tunnel Endpoint. But, personally RO for CN including VMN in NEMO
could be approached by MIPv6 RO. Still it's not clear to me. Can you show me
an example like MIPv6 RO can't be applied to CN or VMN?

> easily. In any case, we need to define the RO problem first. Where do we
need
> RO ?

---

From: "Jongkeun Na" <[email-masked]>
Date: Fri, 6 Aug 2004 15:10:33 +0900

Hi Carlos, 
Thank you for your comments. See below inline.

> Carlos Jesus Bernardos Cano
> Sent: Friday, August 06, 2004 11:17 AM
> To: Jongkeun Na
> Cc: [email-masked]
As you know, ROT model was focused on Tunnel-based RO. So it explicitly does
not include the considerations of other RO approach that do not need any
tunnel. I will try to include other RO types in ROT model by extending some
attributes if it is possible.

> solutions if they were presented in a more abstract way.
Okay, I agree with you.

> which of these situations are more likely to happen.
ROT model looks like RO scope limited. Also, it lacks of some other RO
situations that you and Thierry have pointed out. More elaboration is
required. Thanks.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Aug 2004 12:09:12 +0200

Jongkeun Na wrote:
>> I do not understand why is it assumed (as ORC does) that after RO 
>> there will still be encapsulation.  I thought one of the main goals
>>  of employing RO is to eliminate encapsulation altogether.  I may 
>> be wrong.
>> 
> IP tunneling is a basic mechanism to re-route packets at some 
> intermediate points without any modification on the original packets.
>  I thought that it can well express the purpose of RO such as packet
>  redirection service. And, the tunneling contains most of procedures
>  involved in RO, negotiation between two entities, the method of 
> transferring packets, etc. So, I think that eliminating encapsulation
>  or other optimizations can be considered under the concept of IP 
> tunneling.

So we basically have two competing types of RO solutions here:
-RO eliminating all the encapsulating tunnels, a.k.a MIP6 RO
-RO reducing some of the tunnels encapsulations and further relying on
  IP tunneling techniques to reduce the encapsulations, like RRH.  Maybe
  even add ROHC.

Or maybe we need to better define what "encapsulating" means.  One can
have encapsulated packets with full new base headers (and trailers in
case of ESP) or encapsulation with only extension headers like RH.

Do you mean "encapsulation" to interpret both the cases where new base
headers are added and the cases where only RH is added?  Or only base
header?

And the "encapsulating" case with RH can actually be only a 1-address
RH, like the MIP6 RH Type 2, so multiple "encapsulating" is not quite
possible in this way.

> Okay, it is not bad to me. But, I saw we can make a universal 
> solution in working on the unified RO for some main RO problems like
>  RO in the infrastructure, nested RO.

So we basically have three other sorts of RO techniques:
-RO for nested aggregation (RRH)
-RO for the infrastructure (MIP6 RO)
-RO Unified, a combination of the above, and PCH

Or?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Aug 2004 12:34:43 +0200

> easily. In any case, we need to define the RO problem first. Where do

RO may be needed when:
-certain mobility configurations are not supported by NEMO Basic, e.g.
  the "cross-over" tunnels stuff and the Card/Zabele demo (sorry, I don't
  have a tech name for that issue, maybe one can find one).  If RO solves
  any of those issues, and if OSPF, AODV are not capable of solving them,
  then RO is definitely needed.

-the IP route LFN-MR-CN is significantly shorter than LFN-MR-HA-CN (note
  the length LFN-MR-CN and LFN-MR-HA-CN are not always very significantly
  different).  I would not run 7packet RO exchanges when MR is close to
  its HA, much closer than where CN is with respect to HA.

-the gain of eliminating a number of encapsulating headers over certain
  low-MTU, low-bdwth, assymmetric wireless links is significant in terms
  of improving e2e application performance (note MR performs RO but it's
  not for itself, it's for the sake of LFN-CN communications).  But I
  would not add 7packet RO secure message exchanges only to find out that
  a LFN-CN e2e application does not induce any user-perceptible
  improvement for a video stream.

Alex