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

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 8 Nov 2002 20:43:38 +0100

> The MN should be able to solict and the AR should be able 
  > to send unsolicited.
  > Confining it to "neighboring" APs is a bit of a problem, 
  > since it implies some
  > topological or geographical knowledge on the part of the MN 
  > that it might not
  > have. I suppose the AR could filter if it had additional 
  > knowledge about the
  > topology (I can't see it having any on the geography).

=> Sure, it only needs to know about the topology and the
mapping between APs/subnets. Given a single AP, there is 
a finite number of neighbouring APs that that AR
needs to know about.

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 13:37:19 -0800

> a finite number of neighbouring APs that that AR

Well, this is the direction I would like the Seamoby CARD protocol to go so. I
think we could define CARD very simply as an extension of the FMIPv4/v6
prehandover signaling.

        jak

---

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

> think we could define CARD very simply as an extension of the FMIPv4/v6

So, FMIPv6 already has the carrier (as Hesham called it), and CARD
could devise mechanism(s) to compute the map. That's good division.
However, I would be very hesitant to make FMIPv6 depend on CARD
to work. While I might support CARD, I would like to point out, again,
that deployment of FMIPv6 is entirely possible without CARD, and we
ought to allow implementors to have the choice.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 8 Nov 2002 14:17:02 -0800

> to work.

I rather think it is the opposite, that the CARD work should be dependent on
FMIPv6. And, quite frankly, I've got no problem with that.

> While I might support CARD, I would like to point out, again,

From an architectural standpoint, it doesn't make any sense to have two
protocols that do the same thing.

We need one, simple but extensible protocol that provides the MN with wireless
link type, subnet prefixes, link layer address, and IP address. If, later, there
is need to add the ability of the router to advertise QoS, etc. etc., then it
can be added.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 08 Nov 2002 15:48:45 -0800

> protocols that do the same thing.

I don't think there is any. What I am suggesting is to allow RA/PrRtAdv
to include the neighboring AP-AR information (i.e., the map). PrRtAdv
already includes the tuple. It is a matter of _delivering_ more than one tuple.

How the map is constructed is clearly a matter for CARD.

-Rajeev