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

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

Hi Pascal,

First, thank you very much for the feedback and comments, we really
appreciate so much them. Please, see the comments in-line,

El mar, 19-10-2004 a las 18:57, Pascal Thubert (pthubert) escribió: 
> Hi Carlos :)
> 
> Is the MIRON document already published in a final form or does it make sense to provide feed back for lower interest things like typos? For the time being, let me discuss concepts.

It is already published, so I'm afraid the typos cannot be fixed :-(

> > > 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.
> 
> There are 2 aspects to the proposal, even if (like ORC) it's packaged as one. The first aspect is the proxying for the MNN. The second is obtaining a topologically correct CoA via DHCP.
> 
> 1) proxying
> 
> As we say in this thread, we discussed that on the ML, at least Alex and I, and there are some identified protential problems to the approach (that might be worth more text in the taxonomy?) that you might have to deal with:
> 
> 1a) MNN is VMN
> 	If the MNN is a visitor that handles its own mobility and RO, the MR might in fact act as an attacker (against its will :). CoT messages might clash, and if the MN moves away, the MR might keep the CN binding improperly

This part of the solution ("proxying") is only intended to LFNs, as it's
stated on the document.

> 1b) MNN has an SA with CN
> 	For instance, CN is a VPN entry point for MNN, and MNN handles its own IPSEC. Manipulating packets on the fly will cause them to be dropped.

Agree. We are aware of that. Maybe it is not clearly stated in the doc,
but of course if end-to-end IPSec is used, this part of the solution
cannot be applied.

> 1c) Snooping for CoT
> 	MR has to snoop packets to the MNN in order to find CoT. This defeats the very purpose of the test (collocation). So if the test is improved in some future, it might not work anymore. And it's pretty dirty, reading someone else's packets, isn't it :) ?

I agree that if RR is changed in the future, our solution may not work.
Nevertheless, we proposed this, as you call "dirty" solution, just
because we didn't want to change RR (one of our main goals is to propose
a solution that does not require changes to deployed protocols and
nodes, i.e. MIPv6 MNs and CNs).
I agree that reading someone else's packets is not the ideal solution,
but OTOH, if you don't want your packets to be read, you use IPSEC.
Besides, if you don't use IPSEC, your router (or someone in the path)
can read your packets anyway.

> 1d) modifying packets on the fly
> 	Too bad MIP RO to CN is based on Home addr option as opposed to tunnels, which does not seem to be an option. The MR has to match source AND destination in order to find whether it can do RO to the CN. And then it has to insert the option, which might be a painful operation (apparently more costly then tunnelling, which is already hardware assisted in some boxes). 
> In short, it is going to be software routed for quite some time.

Well, as some other solutions proposed so far, this solution is not
intended to be used with _every_packet routed by the MR. There are many
flows that are not worth to be "MIRON-processed" ;-) (e.g. DNS, etc).
Some heuristics have to be defined to make the decision about which
"LFN-CN" flows should be optimised and which not.

> 2) CoA
> 
> Getting the CoA from the TOP has also been discussed in the ML. As you point out, there are approaches based on PD, like draft-leekj-nemo-ro-pd-02.txt but also draft-droms-nemo-dhcpv6-pd-01.txt. There's also, closer to your proposal, a proxy ND based proposal draft-jeong-nemo-ro-ndproxy-02.txt . See http://www-users.cs.umn.edu/~jjeong/publications/international-conference/vtc2004-spring-jaehoon.pdf as well. I like that proposal a lot, but we must be clear on the use case. We discussed that some time ago on the list as well, but I could not dig out the link.
> 
> The potential issue I see for both approaches is due to the "proxy" states in the network (and this is why RRH uses source routing as opposed to transparent):
> 
> 2a) If the nested structure moves as a whole, it's neat. If it's all swarming then the proxy states are all wrong all the time and the packets do not make it through. So the issue is the resilience to movement. It seems that when the tree grows deeper, or when the inner or in/out movement get more and more important, the chances to reach a node drop rapidly.

Well, we are simulating now our solution in order to check this an other
issues we have detected so far. OTOH, IMHO that is not such a big
problem, if a nested tree moves, root-MR detects the movement, and the
it can inform the other MR using DHCPv6 (DHCPv6 supports sending
information from the server to clients). The new addresses would be
propagated to the MRs within the nested tree and then every MR would be
able to send the appropriate BU.

>                                  
> 
> > >
> > > > 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?
> > 
> 
> Right. It would be very nice if you can keep the ML aware of your progress. This solution seems very representative of the MR-CN solution space.

Actually, we were thinking in submitting a revised version of MIRON to
the WG formatted as an I-D to further discussion, but we were waiting to
have some more simulation results and we were also waiting to the
possible recharter of the WG to focus on RO solutions.

> Simulating and testing should demonstrate the expected benefits of the approach, but also show what the limits are in terms of performance in the MR, scalability in the mobile cloud, and resilience to  the relative movements within the nested NEMO.

Agree. Actually, we are now working on that.

> Note that RRH allows MNN-CN RO, but it's not documented too much and the solution is not finalized at all; but as opposed to your requirements, it would require a change to the MNN and the CN to get there. The idea is that the MNN would insert an RRH with all slots blank.

That's also interesting. The problem, IMHO, is that it would break the
CN and MNN transparency.

> 
> Pascal

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40