Subject: Re: Address config for FMIPv6 (was Re: [mobile-ip] FMIPv6: FBU transmission text)

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Jun 2003 16:48:14 -0700

Hi Youn-Hee Han,

>
> Rajeev,
>
> In fact, from two years ago, I have been deeply impressed with
> your efforts to make your seamless handover protocol completely.
>

as James Kempf already noted, it is not my draft. I do appreciate
your sentiments.

> Please don't think that I am trying to disturb your good working.
>

No such thing.

> I have already investigated your draft repeatedly. Also, I made
> a nice (colorful and minute) presentation material with animation
> effect,
> and explained the protocol to our colleague in our seminar serveral
> times.
> I can send the material to you right now :-)
>

Ok, thanks!

> >
> > I strongly disagree. The proposed text by no means should be
> > seen as "additional" text that gets appended and hence the draft
> > looks longer! If anything, it is a protocol summary.
>
> Ok. I accept the proposed text is a summary including a little updated
> behavior and message. However, it is obvious fact that FMIP has an
> experience of many changes and updates done from the first version.
>

Well, that's the natural progression for a draft. I do believe that
we are pretty close to finishing the specification.

>
> > > What I would like to stress is that the NCoA confirmation itself makes
> > > FMIPv6 complicated. If the NCoA is not guaranteed to be unique,
> > >
> >
> > The "address confirmation" is trivial. As the text says, if the NAR finds
> > an existing ND cache entry, don't over-write it. This almost sounds like
> > implementation issue.
>
> Although "address confirmation" itself is trivial, its effect on
> handover latency
> is significant if non-anticipated mode is performed. If MN can get a
>

In the non-anticipated scenario, the following happens.

- MN detects it has moved to NAR by comparing the
   [AP-ID, NAR] tuple it has learned through PrRtSol/PrRtAdv
- Since FBack has not been received, MN formulates NCoA and
    constructs 'M'
- Encapsulates FBU within M and sends the packet.

Then, NAR verifies if there is already an entry for NCoA in
its ND cache. If there is not one, creates one and forwards FBU
to PAR. The details are in the text I sent.
Hopefully, this clarifies..

> duplication-free
> address from its access router by RS/RA exchange (through new options
> included
> in RS/RA), it can setup the tunnel between PAR and NAR in the fastest
> time without
> any concern about address conflict. How to get such a duplication-free
> address?
> aDAD proposes a method for it.
>

Ok. This could be a proposal where DAD optimizations are
considered.

>
> > > the corresponding and complementary measures must be required
> > > (regardless of the likelihood of collision). The most parts of new text
> > >
> >
> > What are these ? Dropping FBU is matter of memory freeing.
>
> The measures include the scan of ND cache, same address' existence
> check,
> and dropping FBU (also include packet buffering when DHCP address is
> used).
>

Not overwriting an ND cache entry should be part of ND
implementation. Dropping the FBU is freeing memory. I do not
see these as major costs.
Regarding address acquisition through DHCP, yes you would have
to buffer the packet before verifying that the proposed NCoA could
be used. The resulting delay should be stated as part of protocol applicability in my
opinion.

> Also, although its possibility is low, there is the penalty if NAR
> incorrectly
> creates an entry. It is obvious that the scan of ND cache improves the
> chances
> of expeditiously detecting duplicates. However, if so many MNs connect
> to the AR
> at the same time, the above behaviours seem to be burden on the AR and
> time (or memory)-consuming process. Say again, if MN can get a
>

If there is any signaling at all, then the "herd movement" is an
issue. Note that there is signaling from the MN to NAR, but no
signaling from NAR to MN is needed unless there is a conflict.
In any case, I would say this is a good test case for experimentation.

> duplication-free
> address from a new option included in RA, the above behaviours are
> needless.
>
>

I do not know how RS/RA is not immune to herd movement.
Anyway, I think we should leave it for experimentation.

> >
> > Please note that 'M' is not a new message. At the end of the text I sent,
> > 'M' is stated to be a reformatted version of FNA. It would be helpful to
> > have a look at the text and the draft again!
>
> Sorry for my fault. I misunderstood the 'M' message.
>
> > > IMO, NCoA doen't need to be configured from MN's link-layer address,
> > > because it is tentative address valid only during MN resides at a foreign link.
> > > And, I feel uneasy from the fact that the NCoA configuration is done
> > > *expeditiously* using MN's link-layer address during L3 handover.
> > >
> >
> > Could you clarify this ?
>
> What I mean is that.... how about splitting NCoA confirmation process
> from L3 handover process? If that is possible and one of the confirmed
> addresses
> can be delivered to MN as soon as possible (in the previous link if
> anticipation is
> supported, otherwise when it receives new RA from NAR), FMIP can be
> simple
> and robust.
>

We seem to agree about the anticipation scenario.

Regarding the non-anticipation case, I hope my explanation
above is useful. We are not that far apart. The only message the
MN always sends is 'M', and it includes FBU when FBack has
not been received. Avoiding a round-trip for address confirmation
when its likelihood is very small is very highly desirable.

Thank you for your response.

Regards,

-Rajeev

>
> Thanks
>
> Youn-Hee Han.
>
> ps. Please don't think I am just trying to introduce my new DAD
> optimization scheme.
>       I am one of impassioned people hoping make their cellular phone
> equipped with
>       robust seamless L3 handover technology :-).

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 23 Jun 2003 12:52:03 +0900

Hi Rajeev,

>    [AP-ID, NAR] tuple it has learned through PrRtSol/PrRtAdv

How? In the non-anticipated scenario, MN does not engage in exchange
of any messages in the previous link, does it? Is there anything I missing?
IMO, MN detects its moving by receving RA from a NAR. Of course,
there are many issues related to such detection, which is being discussed
in DNA BoF.

> Hopefully, this clarifies..

Ok. I already understood it.

> Ok. This could be a proposal where DAD optimizations are

I agree with Basavaraj and Greg that it would be fine to go 
ahead and build the solution on the enhanced FNA scheme 
('M' message). And once FMIPv6 is more widely deployed, 
we will see if FMIPv6 has benefits over other proposed 
DAD optimizations.

> In any case, I would say this is a good test case for experimentation.

Agree.

> Anyway, I think we should leave it for experimentation.

At least, AR don't have to engage with some works about the address
confirmation.

> when its likelihood is very small is very highly desirable.

In the non-anticipation mode, MN should receive an RA for 
detecting L3 movement. If the obtaining of a duplication-free 
CoA might be achieved with a new option included  in the RA,
we could not consider address conflict any more. I hope this will
be considered as an alternative for seamless L3 handover in 
future time.

Thanks.

Youn-Hee Han.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Jun 2003 10:34:40 -0700

> of any messages in the previous link, does it? Is there anything I missing?

Perhaps.. Even in the non-anticipated case, the MN has exchanged
PrRtSol/PrRtAdv.

> we will see if FMIPv6 has benefits over other proposed

Good.

Regards,

-Rajeev