Subject: RE: [mobile-ip] some comments on the FMIP draft

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 4 May 2001 03:04:18 +0200

> 3) As I've said before, it would be nice to decouple 
>    the need to do the HI/HACK from the rest of this
>    draft. The mobile node should be able to just 
>    ask the old access router to buffer its packets
>    while it's in transition. In fact, this has the
>    positive side effect if the oldAR doesn't know
>    anything about the newAR, 
> 
	=> I agree with you. But when we discussed the 
	alternative (MN performs DAD in parallel with 
	sending and receiving packets) we found that 
	it may not work in all cases. Also there were 
	some open issues with ND. I would prefer 
	that approach (my technical bias) if it 
	can work. So if you think it can work when
	considering it in detail, I don't see why not.

> the mobile node can
>    still register on the newAR 
> 
	=> What do you mean by the "MN
	registers with the new AR" ?
	This is not MIPv6. This is a MIPv4 
	scenario.

> as if it were just
>    booting up, and when it's ready, send the BU
>    to the oldAR to start flowing the buffered 
>    packets. Another benefit is that if, for some
>    reason, the MN can't attach to the ARnew, it
>    can abandon the handoff and still get the 
>    buffers from ARold (assuming it is still 
>    in range, but if not you're really hosed
>    anyway).
> 
	=> Doesn't sound like a real time friendly 
	approach though.

> 4) I don't think anything prevents the MN from
>    going through normal DAD procedures on the
>    new AR. If we eliminate the need for the newAR
>    to do the buffering, we can make the HI/HACK
>    completely optional.
> 
	=> See above.

> 5) Is the FBU/FBACK really a different kind of BU?
>    It looks the same as a normal BU. That would 
>    actually be rather nice if it were the same
>    since we're probably need to consider the
>    security aspects of them, and it would be nice
>    to have exactly one kind of BU to modify if
>    necessary. Same goes for HMIP as well.
> 
	=> It would be the same from a security 
	poin of view. I don't see why not. Same 
	for HMIPv6. The F-BU will include the 
	M flag to ensire coexistence with HMIPv6.

	The reason for having a different type is 
	the HI/HACK messages. We need to know 
	if the BU should trigger HI/HACK or not.

	Hesham

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 May 2001 09:14:00 -0700 (PDT)

> 	considering it in detail, I don't see why not.

   Can you outline some of the problems?

 > 	This is not MIPv6. This is a MIPv4 

   Sorry, I didn't mean that in the mipv4 sense.
   I meant, the MN attaches, possibly requiring
   authentication via, say, PPP/CHAP or BURP or
   802.1x...

 > 	=> Doesn't sound like a real time friendly 

   No, of course not. I view this in %*! happens sense,
   as in if the MN tries to move to some place it finds
   out was a mistake. If the packets were buffered back
   at ARold, it could potentially minimize some of its
   loss. Not a huge benefit, I'll agree, but it sort of
   plays off of the old "bird in the hand is worth two in
   bush" principal :-)

 > 	if the BU should trigger HI/HACK or not.

   Could this not be done with a flag in the RS?
   As far as I can tell, what I'm proposing would
   require the following flags:

Router Solicit (and RA, I suspect):

BUFFER: buffer the packets until you see a Binding Update
HANDOVER: execute the HI/HACK

BU: nothing special since it executes once the MN arrives
BACK: nothing special since it's just a BU
F-NA: deprecate since it's not necessary

Two new flags in the RS and RA seems a lot cleaner in
my mind than 3 new messages.

	Mike