Subject: [MOBILE-IP] FA-assisted handoff

From: Hannes Hartenstein <[email-masked]>
Date: Mon, 14 Feb 2000 09:10:00 +0000

Hi,
just a few questions/comments on the draft
"Foreign agent assisted handoff" by Kempf and Calhoun.

In the draft it is (implicitly) argued that FA advertisements are
no longer needed when the proposed hand-off request can be sent
and this would save bandwidth over the wireless link.
("...it is questionable whether advertisements are appropriate in a
network whose bandwidth is considered scarce...").
But, as I understand it, in order to
decide a handoff, a FA needs measurement reports from the
mobile node (e.g. link quality parameters), thus, there is some
trade-off involved (in GSM, for example, those reports are sent every
480ms). So, does a network-assisted handoff scheme really
save some bandwidth?

A fast (MN-initiated) handoff can be achieved with Mobile IP using
link layer information as, e.g., demonstrated in the
HUT Dynamics implementation. A network-assisted/initiated
handoff is probably somewhat slower than a locally, i.e.,
on the MN, decided handoff. Therefore, I see the motivation
for the introduction of network-assisted handoffs in the
additional ability to take into account traffic considerations
(not known to the MN). In my understanding a network-
assisted handoff might not be _fast_ but it can nevertheless be
_seamless_ since all the "set-up work" can be done while the MN
continues to listen to the old base station.

Thanks, Hannes

--
Dr Hannes Hartenstein           [email-masked]
Research Staff Member           Tel.: +49 6221 905 11 15
C&C Research Laboratories       Fax.: +49 6221 905 11 55
NEC Europe Ltd.
Adenauerplatz 6
69115 Heidelberg, Germany
http://www.ccrle.nec.de/heidelberg/index.html

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 14 Feb 2000 14:18:47 -0800

All,

As I near implementation of this draft, I still have many concerns that I need
to bring up:

1. GRE Key (or session id) generation. The spec requires that the PCF/RAN (or
initiator of the reg request) creates the pseudo unique GRE id. Since a PDSN
(or termination point of the reg request) will be communicating with many
PCFs, the GRE identifier is hardly unique. Since the GRE id is not unique, the
PDSN cannot use this value alone to identify a data stream from the PCF. So,
we have a couple of options:

        a) Document that tunnel identification is done by using the GRE id AND
           the source IP address of the reg request. Of course, this imposes a
           rather large per packet overhead.
        b) Change the specification to mimick the VTP approach where the tunnel
           initiator sets the most significant 16 bits, and the PDSN sets the
           least significant 16 bits. The 16 bits set MUST be locally unique.
           This scheme works as long as no more than 65535 sessions are needed
           per pair (for lookups, the full 32bits are used).

2. The somewhat complicated requirement that both the FA and rpd (that handles
the protocol defined in this draft) listen on port 434. Some suggestions have
been make that processes only need to listen on certain interfaces, etc. I have
thought more about this, and I REALLY don't like this approach. Since the ONLY
thing that both Mobile-IP and R-P share in common is the packet format (and
the extensions used are different), they are different protocols. Why can we
not simply require that R-P be used over a different port? This is a VERY
simply problem to the solution, and no longer assumes ANY architectural
requirements.

Comments?

PatC

---

From: Pete McCann <[email-masked]>
Date: Tue, 15 Feb 2000 11:19:48 -0600

Hi, Pat,

"[email-masked]" <[email-masked]> (psc) writes:

psc> 1. GRE Key (or session id) generation. The spec requires that the
psc> PCF/RAN (or initiator of the reg request) creates the pseudo
psc> unique GRE id. Since a PDSN (or termination point of the reg
psc> request) will be communicating with many PCFs, the GRE identifier
psc> is hardly unique. Since the GRE id is not unique, the PDSN cannot
psc> use this value alone to identify a data stream from the PCF. So,
psc> we have a couple of options:

psc>         a) Document that tunnel identification is done by using
psc> the GRE id AND the source IP address of the reg request. Of
psc> course, this imposes a rather large per packet overhead.

psc>         b) Change the specification to mimick the VTP approach
psc> where the tunnel initiator sets the most significant 16 bits, and
psc> the PDSN sets the least significant 16 bits. The 16 bits set MUST
psc> be locally unique.  This scheme works as long as no more than
psc> 65535 sessions are needed per pair (for lookups, the full 32bits
psc> are used).

If you think about it carefully, I think you'll see that this actually
limits us to 65535 sessions *total*, *per PDSN*.  There is no
coordination between the PCFs defined to pick unique 16 bit numbers,
so we only have the PDSN's 16 bits of uniqueness to work with.  This
was considered too limiting a number by 3GPP2.  So yes, I think we
need to demultiplex based on the source PCF address as well.  I would
support adding such language to the draft.

psc> 2. The somewhat complicated requirement that both the FA and rpd
psc> (that handles the protocol defined in this draft) listen on port
psc> 434. Some suggestions have been make that processes only need to
psc> listen on certain interfaces, etc. I have thought more about
psc> this, and I REALLY don't like this approach. Since the ONLY thing
psc> that both Mobile-IP and R-P share in common is the packet format
psc> (and the extensions used are different), they are different
psc> protocols. Why can we not simply require that R-P be used over a
psc> different port? This is a VERY simply problem to the solution,
psc> and no longer assumes ANY architectural requirements.

I agree that R-P and Mobile IP are really separate protocols.  I
actually don't have a very strong objection to picking a new port for
R-P aside from the fact that it will introduce some additional delay
in standardization due to getting a new port from IANA, etc.  I still
don't believe it's technically necessary since a PDSN should be
maintaining the kind of "virtual interface" structures you allude to
(how else will we deal with dynamic address assignment?) and the MIP
and RP daemons should be configurable to run on only a single
interface or set of interfaces.

Anyway, let's go ahead and make the change - it shouldn't cause much
more delay over and above the other changes that will probably be
introduced at Adelaide.

-Pete