Subject: RE: [nemo] Next steps in RO

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Thu, 3 Nov 2005 15:20:27 +0100

I'm globally with with Chan-Wah on this:

>My personal views are that the following 3 main pieces are needed:
>
>(1) A mechanism for MNNs to send packet from where the NEMO is
attached.
>
>This mechanism would allow MNNs, however deeply they are nested, to
>appear to a node outside the NEMO as if they are a simple mobile node.
>attached to the point of attachement of the root-MR.  This mechanism
>would allow a solution to the nested mobile HA problem, and the
security
>policy prohitbiting visitor traffic problem.  Not only that, it also
>allows VMN to operate MIPv6 RO without being subjected to NEMO-BS
>tunnel.
>
[<PT>] In understand your case 1 as being a nested RO situation. And I
understand that your definition is very open to the meaning of MNN.
Could be a host or a router, and the RO solution could require an
additional support from MNN that does not exist today, right? 

>(2) A mechanism for MRs to offer route optimization to LFNs.
>
>This is less important, but it's a mean to complete the entire RO
>process.  The mechanism above will allowed modified nodes (i.e. VMN) to
>achieve RO in a way compatible to the more "legacy" MIPv6 RO.  This
>mechanism, will allow RO to be achieved for unmodified LFNs.
>
[<PT>] If you meant doing between MRs what MIP6 does between MNs, then
I'd be with you. That is MRs locate each other, establish a tunnel and
exchange MNP routes over that tunnel, using a signaling that is close to
existing NEMO, directly or via MAPs, proxy HAs or such. I do think that
this is really important and that we have to consider it in NEMO; for
instance, 2) is the base for route projection.

But if you mean MR doing some proxy MIP on behalf of LFN to be able to
do RO with MIP6 CN, then I see that as a next step for proxy-MIP as
opposed to a next step for NEMO, and I know of few scenarios that really
require it.

>(3) A correspondent router solution.
>
>The deployment of such an entity would allow two benefits: (1) perform
>RO for non-modified CNs, and (2) the discovery of MR by other mobile
>nodes, if this MR is treated as a CR.
>
>Some of the above may require future research, and may encompass a lot
>of smaller but significant issues to be solved.  One can in fact have
>the NEMO WG re-chartered to work on only 1 or 2 of the above, and have
>the rest moved to IRTF for futher research.
>
[<PT>] Yes. We are introducing a number of boxes which do related things
for related goals. I mean HMIP MAP, EMP EMAP, proxy-MIP, HAHA MIP proxy,
CR. So maybe it will take more than one WG to decide what we really need
from that regional box; I guess that MIP6 and NETLMM would be required
in the loop...

Pascal

---

From: Chan-Wah NG <[email-masked]>
Date: Fri, 04 Nov 2005 00:10:32 +0800

> additional support from MNN that does not exist today, right? 

Perhaps.  I envision all MRs to require additional functionality to
support this.  I suspect VMH to need that as well, but I can at least
give you an example where it does not require this, though it is
achieved in a slightly complicated and less intuitive way.

However, that is going into specific.  What I want to say is the first
pieces is to allow a MNN to appear (to an outside node) as if it is not
nested behind a MR, but directly attached to the AR.  This particularly
important for the problem spelt out in 2.5 and 2.7 of RO-PS draft.

> opposed to a next step for NEMO, and I know of few scenarios that really
I am not looking at it that deep.  This second piece is to enable route
optimization to LFN.  There are different ways to achieved that, (by
modifying CN, for instance).  Since LFN are not-modified, it follows
that someone else must do the RO on its behalf, and the logical best
node to do it will be the MR.

> from that regional box; I guess that MIP6 and NETLMM would be required

Right, which is why I presented the pieces in this order.  This 3rd
piece can potentially have implications in more than the NEMO WG.  For
instance, a CR could very well deployed for MIPv6 RO as well.  And yes,
a HAHA mechanism can be seen as part of this 3rd piece.

/rgds
/cwng

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 03 Nov 2005 21:02:05 +0100

Dear Pascal,

> opposed to a next step for NEMO, and I know of few scenarios that really

	I disagree here. What about a NEMO in a train, bus, ... in which
passengers switch on their laptops/PDAs, obtain an IPv6 address
belonging to the MNP deployed in the NEMO (through stateless/stateful
autoconfiguration) and start communicating using this IP address?. These
nodes would be LFNs (since they are using addresses belonging to the
NEMO and are not going to move from this network to a different one) and
I clearly see the benefit from enabling the traffic of these nodes to be
route optimised.

	Kind Regards,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974