Subject: [Mipshop] Questions about implementation of FMIPv6

From: Peng Yongchao <[email-masked]>
Date: Mon, 11 Oct 2004 11:22:37 +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: "Sun Jing" <[email-masked]>
Date: Mon, 11 Oct 2004 15:58:42 +0800

> easier implemented if FNA is a ICMPv6 message. 

Maybe it is not difficult to define a new mobility option which can contain the Link-layer Address

> FNA may be lost because of the unstable signal strength, an acknowledge 

I think this question is worth being considering.

> question, but I think it should be answered here..

I agree it is a problem.

> take into account the ping-pong movement.  

I am wondering what's update bindings after MN received FBACK from PAR.
 
> old link (predictive fast handover), should it wait until MN disconnect 

But the problem is how can PAR know MN's disconnect with it. If  the NAR can help 
to buffer the packets for MN which is forwarding through tunnel from PAR, those packets
 would reach  MN in new link. Or while PAR is forwarding the packets, it should also send
them to local link.

---

From: Peng Yongchao <[email-masked]>
Date: Mon, 11 Oct 2004 19:05:49 +0800

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

send BU to HA and CN, update bindings using NCoA. 

> > 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?
>
> But the problem is how can PAR know MN's disconnect with it. If  the
> NAR can help to buffer the packets for MN which is forwarding through
> tunnel from PAR, those packets would reach  MN in new link. Or while
> PAR is forwarding the packets, it should also send them to local
> link.
>

Yes, if NAR can buffer packets, MN will receive the buffered packets 
after it connected with the new link, But, after PAR begin to forward 
packets to new link,  and before MN connects with the new link, MN can 
not receive packets.  How long is this time span?  This question may be 
important for some time-critical applications, such as VoIP. 
It's a good idea that PAR send packets to local link while forwarding 
them, but it's difficult to implement. Even we can implement it, some 
applications may prefer to losing packets then receiving duplicate 
packets, such as VoIP, I think so.

Thanks for your comments.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 11 Oct 2004 15:58:58 -0700

Hi,

thanks for sharing your experience. Comments below.

> easier implemented if FNA is a ICMPv6 message.

The LLA option needs to be used according to MH option guidelines. Perhaps
it is useful to illustrate how in the draft, including the Type usage so
that
there is no ambiguity. This will be in the 03 version as I revise
the draft to reflect the overall IESG feedback for IANA Considerations.
The reason for MH for FNA is to support encapsulation; ICMP has no
next header.

> FNA may be lost because of the unstable signal strength, an acknowledge

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.
The MN should have a good idea of FNA status since it would not receive
any packets if FNA is lost.

> question, but I think it should be answered here..

This "Three-Party" handover was also a subject of some discussion. The
realization was that we wrap up the simpler case of Two-Party handovers
first.  This would be a good candidate for discussion in MobOpts.

> take into account the ping-pong movement.

hmm.. I think it is beyond the scope of this document.

> old link (predictive fast handover), should it wait until MN disconnect

Well, if there are means for PAR to detect when the MN has disconnected,
e.g., via some sort of link indication, it may do so. It is link-specific.
The draft
does not disallow it, nor does it require it.

Thanks,

-Rajeev

---

From: Peng Yongchao <[email-masked]>
Date: Tue, 12 Oct 2004 21:22:12 +0800

Hi, Rajeev

> The LLA option needs to be used according to MH option guidelines.

But LLA option is also included in HI and HACK. 

> The reason for MH for FNA is to support encapsulation; ICMP has no  

I implement FNA as a ICMPv6 message, and encapsulate FBU as the payload 
of FNA. Using next header is more difficult, because the existing code 
of MIPL is incompatible.  

> 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

It's not difficult to implement though the radvd program should be 
extended. But I hope FMIPv6 could be a independent module, Defining a 
new message as the acknowledgement to FNA may be a better solution. It 
tells MN two things: 
1. NAR has received FNA
2. Whether NCoA is valid. 
If NCoA is not valid, MN can send out RS. 

> The MN should have a good idea of FNA status since it
> would not receive any packets if FNA is lost.
>

So if MN can not receive any packets after it sent FNA, should it assume 
FNA is lost and resend FNA?  or should it assume NAR do not support 
fast handover and begin normal handover?  

Sincerely yours,
Y.C Peng

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 12 Oct 2004 12:24:26 -0700

> But LLA option is also included in HI and HACK.

Yes. That's why I will clarify its use in FNA.
Also, LLA could be useful for other MH messages, notably
FBU. There was some discussion on the list regarding
inter-technology handovers where it would be useful
to have the LLA in FBU since LLA would be different on different
links.

> of FNA. Using next header is more difficult, because the existing code

Okay. It would be useful to know where is the problem in using
Next Header.

> If NCoA is not valid, MN can send out RS.

FNA is like sending unsolicited NA which "propagates
information unreliably (RFC 2461)". The ACK model
is similar to what is used for NA; i.e., there are no acks.
It would be better not to send any responses for the
common case, i.e., no conflicts.

> fast handover and begin normal handover?

If FNA is lost, normal NS/NA should trigger packet forwarding.
I realize that when NAR is buffering packets for NCoA, some
implementations may choose to wait for FNA to flush the buffer.
The draft does not (afaik) specify that normal NS should not be done.
So, between FNA and NS, the router should sync up with the MN,
although I agree that default period between NS retransmissions
(1 second) is too high. I think we can take up FNA reliability in the
next avatar of the draft for Proposed Standard.  BTW, do you have
any statistics on FNA packet loss?

I will clarify use of LLA in version 03. We can address FNA reliability
and FNA header type, and any other interesting topic in MobOpts.

Thanks,

-Rajeev

---

From: Peng Yongchao <[email-masked]>
Date: Wed, 13 Oct 2004 17:14:17 +0800

> to have the LLA in FBU since LLA would be different on different

Then LLA is a Mobility Option as well as an ICMPv6 Option, right?  

> > I implement FNA as a ICMPv6 message, and encapsulate FBU as the
> > payload of FNA. Using next header is more difficult, because the
> > existing code of MIPL is incompatible.
>

This problem is code related, maybe not suitable to be discussed here.    

> > extended. But I hope FMIPv6 could be a independent module, Defining
> > a new message as the acknowledgement to FNA may be a better
> > solution. It tells MN two things:
> > 1. NAR has received FNA

I agree that in most case the ack is not needed. 

> > So if MN can not receive any packets after it sent FNA, should it
> > assume FNA is lost and resend FNA?  or should it assume NAR do not
> > support fast handover and begin normal handover?
>

It rarely happened. I have only seen once or twice. But there is only 
one mobile node. If the network load is heavy, I think the case will be 
worse.

> I will clarify use of LLA in version 03. We can address FNA
> reliability and FNA header type, and any other interesting topic in
> MobOpts.
>
OK.

Sincerely yours,
Y.C Peng

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 13 Oct 2004 10:09:05 -0700

> Then LLA is a Mobility Option as well as an ICMPv6 Option, right?

Yes, with its own Type number.

> one mobile node. If the network load is heavy, I think the case will be

It would be very useful to have some experimental data on this.

Regards,

-Rajeev