Subject: Re: [Mipshop] Last Call Comments on draft-ietf-mipshop-fast-mipv6-00.txt

From: おがわ <[email-masked]>
Date: Fri, 14 Nov 2003 11:21:07 +0900

Hello　Rajeev,

Thank you for your answers.

I have some comments below.
I'm sorry, if those issues have been concluded in mailing 
list or IETF meetings.
I would very appreciate it if I hear your opinion on those 
and the background of the conclusion.

> Hello Takeshi,
> 
> >
> > 1) In the case FMIPv6 is combined with advance DAD to reduce
> > hand-over processing time, I suppose an NCoA (a pooled
> > Duplicated-free address in the NAR) should be notified to
> > the MN by an FBack message prior to its movement. However,
> > on page 25 of FMIPv6 ID-00(mipshop), The Destination Address
> > of an FBack message is noted "The NCoA".
> > I suppose the destination address of an FBack message shall
> > be "the source address of the FBU message" to carry the
> > message to the MN on the old link in such case.
> >
> 
> Sending FBack to source address of the FBU always means it could
> be lost when the MN has already moved.
> 
> On the other hand, sending it always to NCoA ensures that the
> MN does not have to wait on the old link and it receives it
> reliably on the new link.
>
> For the stateful scenario, even if the MN leaves
> link without receiving FBack, the FNA exchange allows NAR
> to supply NCoA to use. Besides, the draft states that FBack MAY
> also be sent on the old link (to PCoA).
> 
> Please note that the draft does not specify how NAR should provide
> duplicate-free addresses (i.e., Advance DAD or any other method).
> However, any method should be readily usable.
> 

If the PAR sends an FBack to PCoA and the MN can receive the 
FBack on the old link, the sequence is illustrated in fig. A.

MN					NAR				 	PAR
|					|				 	|
|-----FBU------------------------------>|
|					|<-----HI-----------|
|					|------HACK-------->|
|<-----FBack(NCoA)----------------------|
|					|				 	|
====ataches to the NAR======
|					|				 	|
|----FNA----------->|					|
|<----NAACK---------|					|
|					|				 	|

				fig.A

But, if PAR sends an FBack always to NCoA, I suppose the 
sequence is illustrated in fig. B, more complicated than fig. A. 
And if this sequence is right, the FBack(NCoA)(1) is not 
effective, isn't it?

-The PAR sends the FBack (1) to NCoA and the NAR buffers it.
-The MN resends FBU (2) in FNA as soon as it attaches to the NAR.
-NAR discards the FBU (2) in FNA because the NCoA in the FBU 
 is not valid in this case, and sends NAACK with alternated 
 NCoA.
-The MN re-resends FBU (3) in FNA because it does not know 
 if the PAR has received any FBU.
-The NAR forwards the FBack (1) and FBack (3) to the MN.

MN					NAR				 	PAR
|					|				 	|
|--FBU(1)------------------------------>|
|					|<-----HI-----------|
|					|------HACK-------->|
|					|<--FBack(NCoA)(1)--|
|					|				 	|
====ataches to the NAR======
|					|				 	|
|----FNA(FBU(2))--->|(Discard FBU(2))	|
|<----NAACK(NCoA)---|					|
|-----FNA(FBU(3))-->|-----FBU(3)------->|
|<--FBack(NCoA)(1)--|					|
|					|	（NO HI/HAck?) 	|
|					|				 	|
|<--FBack(NCoA)(3)----------------------|
|					|				 	|

				fig.B

On the other hand, if PAR sends an FBack to PCoA, but the MN 
moves to new link without receiving the FBack, I suppose the 
sequence is illustrated in fig. C, and the handover ends 
successfully.

MN					NAR				 	PAR
|					|				 	|
|--FBU(1)------------------------------>|
|					|<-----HI-----------|
|					|------HACK-------->|
|       <-----FBack(NCoA)(lost)---------|
|					|				 	|
====ataches to the NAR======
|					|				 	|
|----FNA(FBU(2))--->|(Discard FBU(2))	|
|<----NAACK(NCoA)---|					|
|-----FNA(FBU(3))-->|-----FBU(3)------->|
|					|	（NO HI/HAck?) 	|
|					|				 	|
|<--FBack(NCoA)(3)----------------------|
|					|				 	| 

				fig.C

So I have not understood clearly the merit of "sending FBack 
always to NCoA" yet, and I still think the destination of an 
FBack had better be "the source address of the FBU".

> >
> > 2) In the case of "predictive HO", I suppose a PAR had
> > better start buffering when it receives an FBU message
> > instead of a RtSolPr message to reduce buffering delay.
> > So, I suppose If an MN knows it can send an FBU message
> > prior to its movement, it should send a RtsolPr message with
> > its U bit "off", and the PAR starts buffering when it
> > receives an FBU message, and sends a HI message to the NAR
> > with its U bit "on".
> >
> 
> The problem is that MN may have to move (or forced to move)
> without being able to send FBU. In such a case, it could have done
> PrRtSol right after establishing connectivity. Setting the 'U' bit in
> RtSolPr requests the router to buffer and forward at the same time.
> So, if FBU comes from the new link, buffered packets can be tunneled
> to the NCoA.
> 
> Buffering at PAR after FBU is received is problematic because
> we don't know when to stop it and begin tunneling (i.e., two seprate
> problems) 

I understand the merit of U bit in RtSolPr mentioned above. 

But, if FMIP is applied to free way or train, distance of 
cells and moving speed of an MN are may be estimable, and I 
suppose the MN had better send "predicative" FBU from old 
link.
In such case, the buffered packets in the PAR before 
receiving the FBU need not to be sent to the MN and cause to 
some delay.

If this scenario is considerable, I propose to introduce a 
new "U bit" in an FBU and that when the PAR receives an FBU 
with U bit "on", it clears the buffer and restarts buffering 
but not forward packets to PCoR, and stops buffering and 
starts tunneling them to NCoA when it receives HAck.

> 
> >
> > 3)In the case the network notifies MNs of NCoAs with FBack
> > messages, I suppose there should be some way to notify an MN
> > by a PrRtAdv message that the NCoA will be notified by an
> > FBack message. For example a new code of PrRtAdv or code "0",
> > but NCoA=all "0".
> >
> 
> Could you say why ? The current method works without requiring
> the MN to wait for FBack.

I agree.

With best regards,

-Takeshi.

> 
> Thanks,
> 
> -Rajeev
> 
> 
> >
> > Best regards,
> >
> > Takeshi
> >
> > _______________________________________________
> > Mipshop mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 
> _______________________________________________
> Mipshop mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mipshop

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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 18 Nov 2003 15:22:16 -0800

Hi,

the scenario in Figure B) below is not correct.

If the NCoA in FNA is not what NAR wishes to support, the
assigned NCoA in NAACK allows the MN to send FBU without
again encapsulating it in FNA as you show. Furthermore,
as I mentioned previously, the PAR MAY always send FBack to
PCoA as well. So, this option should be sufficient for your purpose.

Regarding the comment on buffering, I did not understand the
concern for buffering delay from your desciption. Independent of
whether/when PAR does buffering, as soon as FBU is processed,
packets will start to be tunneled towards NCoA.

Regards,

-Rajeev