Subject: [Mipshop] LLA in FBUs

From: Emil Ivov <[email-masked]>
Date: Fri, 15 Apr 2005 16:31:17 +0200

Hello all,

Section 6.2.1 - HI msg fmt (page 23)
draft-ietf-mipshop-fast-mipv6-03.txt says

	The link-layer address of the MN that is
         undergoing handover to the destination (i.e., NAR).
         This option MUST be included so that the destination
         can recognize the MN.

The thing is that when sending a HI the PAR is not necessarily aware of
MN's address.

Ideally (at least according to us here ) a PAR would learn an MN's L2
addr from the FBU. Yet Section 6.3.1. does not mention anything about
including an MH LLA Option. Without such an option we could try and
extract the L2 addr from FBUs L2 packet (which is a bit dirty -
implementation wise) but this would only work for predictive handovers
and there will be no way to do it with an FBU coming from the NAR.

Another way to get MN's L2 addr would be to use the one that arrived
with the RtSolPr and was recorded in the neighbor cache. Yet there is no
guarantee that it will still be there, not to mention the fact that it
might have not been in the RtSolPr in the first place.

So in other words - wouldn't it be better if we had a MUST MH LLA option
for FBUs?

Cheers
Emil

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 15 Apr 2005 12:05:38 -0700

> might have not been in the RtSolPr in the first place.

a neighbor cache for the MN's PCoA does not depend on the
the MN sending a RtSolPr. the PAR most probably will have
one for just forwarding traffic meant for the MN's PCoA.
the PAR can just lookup the neighbor cache to get the L2
address that corresponds to the MN's PCoA.

but, I do agree that it is not certain that the L2 address
is available when the PAR needs it. the PAR might need to
extract the information from the neighbor cache, whenever
available and store it somewhere else.

> So in other words - wouldn't it be better if we had a MUST MH LLA option

thats sounds okay to me.

Vijay

---

From: Emil Ivov <[email-masked]>
Date: Sat, 16 Apr 2005 12:38:28 +0200

Hi Vijay,

> one for just forwarding traffic meant for the MN's PCoA.

True. I was referring to an RtSolPr as the only MN emitted FMIP message 
preceding an FBU but I agree that there is more chance of a valid entry 
being in the cache due to packet forwarding.

> available and store it somewhere else.

Well that would be the same as reimplementing a neighbor cache in 
FMIPv6's AR impl, so you'd pretty much face the same problem. The PAR 
won't be able to store all MN L2 addresses indefinitely so they will 
have to expire at a given moment which puts you in exactly the same 
situation as with the standard neighbour cache.

>> So in other words - wouldn't it be better if we had a MUST MH LLA option

Do you think that there's any chance of updating the draft or is it 
already too late?

Emil

---

From: Koshiro MITSUYA <[email-masked]>
Date: Mon, 18 Apr 2005 11:34:54 +0900

Hello,

I was also referring to the neighbor cache.  But I also agree
that it is not certain that the L2 address is available when
the PAR needs it.

I understand MH LLA option for FBUs would help this situation.
But I think it bring another issues, e.g. What's happen if the
L2 address in FBU and the one which MN is using for real are
different?  So that, I guess we need more study for this.

regards,
Koshiro

On 2005/04/16, at 19:38, Emil Ivov wrote:

> True. I was referring to an RtSolPr as the only MN emitted FMIP 
> message preceding an FBU but I agree that there is more chance of a 
> valid entry being in the cache due to packet forwarding.
>