Subject: [Mipshop] Questions about implementation of FMIPv6

From: Peng Yongchao <[email-masked]>
Date: Sun, 10 Oct 2004 08:19:56 +0800

Hello folks

Recently I implemented FMIPv6 based on mipv6-1.0-v2.4.22 according to 
draft-ietf-mipshop-fast-mipv6-02.txt. From the sight of implementation, 
I hope the following trivial changes be made to the draft:

1. In the draft, FNA is a mobility header message, but I think a ICMPv6 
message is better. Because FNA MUST contain the link-layer address of 
the MN, but no one mobility option defined in rfc3775 can hold 
link-layer address. The LLA option defined in the draft is a ICMPv6 
message option, isn't it? And FNA may encapsulate FBU, it will be 
easier implemented if FNA is a ICMPv6 message. 

2. In the draft, when NAR receive FNA, if NCoA is not valid, NAR will 
send out RA containing NAACK option. I think a new ICMPv6 message 
should be defined as the acknowledgement to FNA, and whether the NCoA 
is valid or not, the acknowledgement should be sent out. Because RA is 
sent out by a user space daemon program (radvd), not kernel protocol, 
so it is not suitable to act as the acknowledgement to FNA. Considering 
FNA may be lost because of the unstable signal strength, an acknowledge 
to FNA is always needed. 

3. In the section 5.5 of the draft, it said that:
   "IP layer mobility, however, introduces its own limits.  IP layer
   handovers should occur at a rate suitable for the MN to update the
   binding of, at least, its HA and preferably that of every CN with
   which it is in communication.  A MN that moves faster than necessary
   for this signaling to complete, which may be of the order of few
   seconds, may start losing packets."
If MN moves too fast, handover may involve 3 (or more) AR: MN moves from 
AR1 to AR2, then to AR3. So in the short time that MN connected with 
AR2, if MN completed the update the binding, should AR2 be the PAR in 
the handover from AR2 to AR3? It seems that the author bypass this 
question, but I think it should be answered here..

4. The draft not clarify when fast handover should transit to normal 
handover, i.e, after MN received FBACK from PAR, when should it begin 
update bindings?  I think it is better to wait several seconds, if we 
take into account the ping-pong movement.  

5. When should PAR begin forward using tunnel? I think, if PAR received 
FBU from new link (reactive fast handover), then it should immediately 
begin forward after received HACK from NAR, but if it received FBU from 
old link (predictive fast handover), should it wait until MN disconnect 
with it? 

Sincerely yours,
Y.C. Peng

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 12 Oct 2004 10:51:04 -0400

Hi Charlie, 

 > 
 > You bring back pleasant memories.

=> :) It's been a while for me too.

 > 
 > Doesn't one typically arrange to select() on
 > input from a file descriptor opened from,
 > say, /dev/trigger?  I reckon the value of the
 > data retrieved from the device driver could
 > provide any details about the kind of trigger
 > fulfilling the select().

=> I think you're referring to the case where you
set a filter from user space on a dev to receive
certain packets. But I don't know what granularity you
could achieve with this filter and anyway, I didn't think 
the intention was to receive the packet. My understanding 
was that the MIPv6 implementation needed to be *informed*
about the arrival of an FNA and that the FNA should be 
processed by the ND code. So in this case there is some
internal communication needed between ND and MIP. 
At least that's what I thought the question is about.

Hesham

 > 
 > If I'm remembering it all wrong, please
 > forgive.
 > 
 > Regards,
 > Charlie P.
 > 
 > 
 > Soliman, Hesham wrote:
 > 
 > > > I thought the new MIPL version had MIPv6 in user space except for
 > > > per-packet processing (routing header, home address option 
 > > > processing).
 > > > So, FNA processing would also be in user space..
 > > > In any case, the point of not sending an RA for every FNA is 
 > > > that you do
 > > > not
 > > > need to send them unless there is a conflict or the router 
 > > > wants to supply
 > > > an address. If FNA processing is in kernel, you need raw 
 > sockets or
 > > > something
 > > > like that to trigger the routing daemon to send an RA in 
 > > > rare instances.
 > >
 > >=> In my experience it's  very hard to do this, at least in
 > >BSD. Having a kernel event to trigger a user space event is 
 > >not trivial, it's much easier to communicate from user space to
 > >the kernel than the other way around.
 > >
 > >
 > >Hesham
 > >  
 > >
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================