Re: [Mipshop] Questions about implementation of FMIPv6

"Sun Jing" <sunjing@nlsde.buaa.edu.cn> Mon, 11 October 2004 08:19 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12550 for <mipshop-web-archive@ietf.org>; Mon, 11 Oct 2004 04:19:10 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGvZC-00022h-CJ for mipshop-web-archive@ietf.org; Mon, 11 Oct 2004 04:30:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGvI7-0007lK-M0; Mon, 11 Oct 2004 04:12:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGv4v-00057R-TQ for mipshop@megatron.ietf.org; Mon, 11 Oct 2004 03:58:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11046 for <mipshop@ietf.org>; Mon, 11 Oct 2004 03:58:44 -0400 (EDT)
Received: from nlsde.buaa.edu.cn ([202.112.142.51] helo=ibm1.nlsde.buaa.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGvFO-0001bv-1z for mipshop@ietf.org; Mon, 11 Oct 2004 04:09:36 -0400
Received: from hkzjzl7gji5b4a ([192.168.3.250]) by ibm1.nlsde.buaa.edu.cn (8.12.8/8.12.8) with SMTP id i9ANQDLl007750; Mon, 11 Oct 2004 07:26:14 +0800
Message-ID: <003801c4af68$20b021d0$fa03a8c0@hkzjzl7gji5b4a>
From: Sun Jing <sunjing@nlsde.buaa.edu.cn>
To: ycpeng@mail.ustc.edu.cn, mipshop@ietf.org
References: <200410091749.10915.pengyc-1997@ustc.edu>
Subject: Re: [Mipshop] Questions about implementation of FMIPv6
Date: Mon, 11 Oct 2004 15:58:42 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Spam-Score: 2.2 (++)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
X-BeenThere: mipshop@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: mipshop.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mipshop@ietf.org>
List-Help: <mailto:mipshop-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop>, <mailto:mipshop-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1716426729=="
Sender: mipshop-bounces@ietf.org
Errors-To: mipshop-bounces@ietf.org
X-Spam-Score: 2.2 (++)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976

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

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

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

I think this question is worth being considering.

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

I agree it is a problem.

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

I am wondering what's update bindings after MN received FBACK from PAR.
 
> 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.  


 
> Sincerely yours,
> Y.C. Peng
> 
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop@ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop
_______________________________________________
Mipshop mailing list
Mipshop@ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop