Subject: [mobile-ip] Thoughts on using handover capability extension

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 10:33:47 -0800

Hello folks,

there has been some discussion on the timing of various
messages. It occurred to me that one _could_ make use
the handover capability extension to provide some of
the information to the MN ahead of time. For instance,
a MN may request the map of neighboring APs and ARs
via RS much ahead of the actual handover, e.g., when it
first attaches to its router. The AR can provide this via
handover capability extension in a RA.

With this, the functionality of PrRtSol/PrRtAdv is moved
to RS/RA, but also to an earlier time. The MN should be
able to send FBU prior to handover, which then triggers
HI/HAck sequence.

Downside is increased message size (due to the whole
map being sent). Also, the MN may attach to an AP
not in the map, but I guess this can always happen and
we need tunnel establishment subsequent to handover.

Comments ?

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 11:30:04 -0800

This is what Seamoby CARD is supposed to do. In their current draft, the design
team has defined an ICMP type to provide the information.

Please comment on it. I think CARD could be as well defined as an extension of
the prehandover MIP signaling.

            jak

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 12:41:38 -0800

Hi Rajeev, folks,

Did you have a chance to read the eFWD draft?

http://www.ietf.org/internet-drafts/draft-gwon-mobileip-efwd-fmipv6-00.txt

It exactly talks about this. Please see section 4.2.2.

alper

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 12:59:56 -0800

> the prehandover MIP signaling.

I have been behind.. I will take a look. However, all I am looking
for is the ability for a MN to receive a map, which is a configuration
issue in its simplest form. Just as the current version of fmipv6 can
run without having to run CARD, I think providing this map would
be a simple extension. Of course, when CARD is available, one
could use it as well.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 13:42:02 -0800

Hello Alper,

I quickly read through Section 4.2.2. It does talk about
the map, which is really an enumeration
of multi [new AP-id, new AR-IP, new AR-MAC] tuples.
I hope you would agree that such an
enumeration is an extension of providing a single tuple,
which is what PrRtAdv does in the current form.

I am suggesting that the map, no matter how it is
constructed, be delivered to the MN upon request, and
that such a delivery use handover capability extension
already defined in the fmipv6 draft. Furthermore, I am
suggesting that such a map exchange take place ahead of
actual handover, which means HI/HAck sequence takes
place upon receivng the FBU.

Comments ?

-Rajeev

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Nov 2002 14:44:59 -0800

Hi Rajeev,

> place upon receivng the FBU.

makes sense. eFWD says that too:

   Mobile node should be able to request this table from its current
   access router anytime, not necessarily right before a handover.

So, agreed.

alper

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 15 Nov 2002 12:10:12 +0000

Hi folks,

  what I don't understand is why people have to reiterate what we 
proposed _a year_ ago in the proactive mobility model. Why do we have to 
rediscover the wheel with just different names?

The idea has been well received in our recent publications and validate 
the originality of the idea long time ago..

To reflesh people's memory one could peruse (again)

http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.ps
http://www.cs.ucl.ac.uk/staff/t.pagtzis/papers/draft-pagtzis-mobileip-proactivev6-00.txt

and for the sake of completeness people could visit the IEEExplore site 
where the respective publications lay about the proposed mobility 
model... People may want also to get hold of the Computer Communications 
journal for the respective journal publication. How much more does one 
need to give some credit to the idea...

regs
theo
UCL/Mobile Systems Group

-- 

thanks

theo