Subject: [mobile-ip] Fast Handover document revision: Summary

From: Rajeev Koodli <[email-masked]>
Date: Tue, 25 Feb 2003 17:48:52 -0800

Hello folks,

following is the summary (encapsulated under \b,\e)
on list of issues I had sent earlier to the mailing list.

As I revise the draft, I would also like to
agree with the position that the draft should
avoid dependencies on other works in progress.
However, I would also like to ensure that the
draft is able to, perhaps generously, complement
other relevant work so that developers have a
suite of protocols to build upon (this does not mean
we need to determine in the draft how the protocol
will work with every other protocol :-)).

Thanks for all your input.

Regards,

-Rajeev

-------- Original Message --------
Subject: Fast Handover document revision
Date: Mon, 10 Feb 2003 18:24:47 -0800
From: Rajeev Koodli <[email-masked]>
Organization: Nokia Research Center
To: [email-masked]

Hello folks,

I wish to revise the document. Specifically, I would
like to address the following.

1. Securing the Fast Binding Update. I would like folks to provide
    input on this. What should we do ?

\b
Summary:
Use existing (or more accurately emerging) mechanisms. SEND and
PANA were mentioned. No mechanism specific to FMIPv6 itself was
brought up.

I agree that if there is a proven solution that would work, we
ought to use it. I am not convinced that there is one available
now. Do we want to peg the draft to a solution in works ? How do
we know it would be applicable when done ?

So, at this stage, this is unresolved. I encourage folks to bring
input, proposals.
\e

2. Regardless of whether FBack is received or not, the MN always sends
    the same message to the new router. This message
    - confirms new CoA
    - announces the MN's presence to the new router

The message itself would be a refined FNA, as an option in the
Router Solicitation message. The response would be a NAAck option
in the RA message.

    What do folks think about this ?

\b
Summary:
This would be a good feature to have. It should make sure that
the folloing cases are covered
- FBAck received on previous link, NCoA confirmed
- FBack received on previous link, NCoA invalid
- FBAck not received on previous link

If an FBU has never been sent on previous link, FNA must not
be sent.
\e

3. Based on the discussion prior to the last IETF and
     during the last IETF, I would like to allow PrRtSol and PrRtAdv
    exchange to be possible ahead of the handover. So, for instance,
    a MN may exchange these messages upon attaching to a router.
    This means fewer messages during handover, shorter time for
    which the handover state needs to be managed and better chances
    of anticipating a new CoA. Also, the binding at the old router is
     created upon processing the FBU, and is more consistent with the
base
     Mobile IPv6 spec.
    Please acquaint yourself with the discussion on the ML and the
    presentation slides before you comment :-)

\b
Summary:
What this issue really means is that HI and HAck take place
upon processing FBU. The PrRtSol and PrRtAdv messages can be sent
at any appropriate time, including at the time the MN/PAR receives
some sort of trigger (when available), at the time of attaching to PAR,
etc. This is also a good feature to have since it reduces the time
during
which handover state needs to be managed, fewer protocol messages during

handover and increases the likelihood of anticipating a new CoA. Since
the
messages are already defined, simply allowing for different time epochs
at which
messages are transmitted could provide considerable benefits.
\e