Re: [nemo] RE: RO between MR and CN

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Pascal, Masafumi,

El mié, 13-10-2004 a las 19:08, Masafumi Watari escribió:
> Hi,
> 
> On Wed, 13 Oct 2004 13:34:06 +0200,
> "Pascal Thubert (pthubert)" <[e-mail]> wrote:
> 
> > Hi Tania
> > 
> > I was thinking things like of snooping. MR might intercept all packets to LFN, recognize a HoT and keep it. I remember discussing that with Alex long ago... Anyway, we try to say "don't take that path" as opposed to describe a solution in details.
> 
> I don't think its possible to provide RO while keeping the RR function
> of MIPv6 untouched.  It would probably require modification of the
> packet at MR to use the HoA opt and the routing header for every
> packet, if we want to keep the MIPv6 spec as is.

	Yes, one possible solution is the MR performing all the RR and RO
signalling on behalf of the LFNs of the NEMO, in order to provide RO for
LFNs that are communicating to CNs outside the NEMO. This is actually
the solution we have proposed in MIRON (see my previous e-mail if you
want a pointer to it), so the MR, as you said, has to process the
packets sent/received by a LFN in order to insert HoA DO/remove RH. I
agree that it could have some performance concerns if the process is
performed to every LFN-CN "flow", but as we have already discussed in a
previous thread, some mechanism should be used to perform the RO in a
reasonable way.

> 
> > It seems preferable, for instance, to establish a MR-CR tunnel and exchange fine grained routes for MNPs over the tunnel (route projection).
> 
> I think I agree on this.

	This is, IMHO, a different approach, in which the RO requires some
support from the routing infrastructure, and that present some
advantages. But, OTOH, solutions based on MR-CN RO are also interesting
IMHO, as an approach that does not require support in the routing
infrastructure and puts the RO support functionality only in the edges,
i.e. the CN and the MR (if the transparency to the MNNs is required, the
MR is the other edge in which RO mechanisms can be added).

	What do you think?

	Kind Regards,

	Carlos J.
> 
> Masafumi Watari
> 
> > Pascal
> > 
> > > -----Original Message-----
> > > From: Tânia Pinto Calçada [mailto:[e-mail]]
> > > Sent: mercredi 13 octobre 2004 13:16
> > > To: [e-mail]
> > > Cc: Pascal Thubert (pthubert)
> > > Subject: RO between MR and CN
> > > 
> > > Hello,
> > > 
> > > 
> > > 
> > > I am interested in route optimization between the MR and the CN. I read the taxonomy draft
> > > (draft-thubert-nemo-ro-taxonomy-02.txt), and several other documents related to RO:
> > > 
> > > draft-jeong-nemo-ro-ndproxy-02.txt
> > > 
> > > draft-leekj-nemo-ro-pd-02.txt
> > > 
> > > draft-na-nemo-gen-ro-model-00.txt
> > > 
> > > draft-na-nemo-path-control-header-00.txt
> > > 
> > > draft-wakikawa-nemo-orc-00.txt
> > > 
> > > ROProblem.txt
> > > 
> > > 
> > > 
> > > I also read some threads of the NEMO mailing list http://www1.ietf.org/mail-
> > > archive/web/nemo/current/index.html <http://www1.ietf.org/mail-
> > > archive/web/nemo/current/index.html> , however I am still looking for a document that
> > > describes a solution for the RO between the MR and the CN.
> > > 
> > > 
> > > 
> > > The taxonomy draft says at section 2:
> > > 
> > > "A major issue with this form of optimization is that the end-to-end
> > > 
> > >    principle of the MIPv6 Reverse Routability (RR) test is broken.  The
> > > 
> > >    RR test is meant to ensure the care-of address (CoA) and the home
> > > 
> > >    address (HoA) are collocated. With a mobile network, when the MR
> > > 
> > >    performs RO on behalf of the MNNs, the CoA in BU will be the MR's
> > > 
> > >    CoA.  Thus, a MNN is reachable via the CoA, but not at the CoA.
> > > 
> > > 
> > > 
> > >    Some tricks may be performed on the fly by the MRs but it seems that
> > > 
> > >    a clean MR-to-CN optimization for Nemo will impact the CN function."
> > > 
> > > 
> > > 
> > > Can somebody point the "tricks" that may be performed, or indicate a document that explores
> > > this subject?
> > > 
> > > 
> > > 
> > > Regards,
> > > 
> > > Tania Calcada
> > 
> > 
> > 
-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40