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

["Pascal Thubert \(pthubert\)" <[e-mail]>]

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.

> > 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

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.

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 :) ?

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.

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.
                                 

> >
> > > 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.

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.

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.


Pascal