Subject: Re: [MOBILE-IP] Differences between the two MIPv4 handoff approac hes

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 6 Oct 2000 08:21:55 +1100

Pete,

Some initial comments below, Karim will probably add to my comments.

> "Karim El-Malki (ERA)" <[email-masked]> (KE) writes:
>
> KE> Proactive Handoffs draft = draft-calhoun-mobileip-proactive-fa-02
> KE> Fast Handoffs draft = draft-elmalki-mobileip-fast-handoffs-03
>
> KE> 1) The Fast Handoffs draft allows both the network and the
> KE> MN to control L3 handoffs just as normal Mobile IP (RFC2002).
> KE> The MN performs Mobile IP Registrations and is therefore in
> KE> control as to when and with which agent it registers. The
> KE> network is also in control since it may decide whether to
> KE> send the MN an agent advertisement to trigger the MN's
> KE> movement (without which the MN will not perform movement
> KE> detection and MIP Registration). The network may also
> KE> advertise but reject the MN's Registration and thus again
> KE> exercise control. In Proactive handoffs the MN has no control
> KE> over the handoff and may only react to the network-controlled
> KE> handoff after it has obtained L2 connectivity to the new FA
> KE> and starts receiving data from it. Thus the handoff
> KE> is forced on the MN and the MN may only react if and
> KE> when the new FA decides to advertise.
>
> The terms "control" and "force" should be taken with a grain of salt
> here.  It is true that the MN, in the Proactive draft, does not
> receive an agent advertisement before the handoff, but this is for a
> very good reason: we are decoupling the Mobile IP layer-3 handoff from
> the underlying layer-2 handoff.  In typical cellular link layers,
> there is no time for the Mobile IP protocol (advert/request/response)
> to run before the actual handoff must be over and done with and
> connectivity to the old FA is lost.
>
        How did you make that conclusion ? Of course there is time.
        There is lots of messaging that goes on in a "typical" cellular
        handoff. Can you be more specific ?

> To use Karim's Fast Handoff draft, you need to make sure that the
> advert/request/response can run after link-layer power measurements
> indicate a likely handoff, but before connectivity to the current
> FA is lost.  This imposes very tight real-time requirements on the
> MIP client implementation that we were unwilling to impose in the
> Proactive draft - my feeling is that this runs counter to the Internet
> design philosophy.
>
        Which design philosophy is that ? RFC 2002 ? because that's what
        the draft tries to maintain. Again can you please be specific ?

>  You can think of Proactive handoffs as a way to
> remove the layer-3 messaging from the critical handoff path; the
> network proactively sets up a tunnel from the old point of attachment
> to the new point of attachment, and the MN can register there at its
> leisure.
>
        Actually I think it attempts to remove L3 signalling from the MN for

        an unspecified period of time.

> KE> 2) The Fast Handoffs draft allows the MN to register with
> KE> the new FA (or GFA) before it moves and before it obtains L2
> KE> connectivity to that new FA, thus anticipating the MN's
> KE> movement. By interacting with L2 it is possible for the
> KE> FA to synchronize such a registration with the cellular
> KE> network's mobility such that the new Registration is
> KE> completed before the MN is instructed to perform a handoff
> KE> at L2. Local HA functionality (GFA) is used to limit the
> KE> RTT for the MN's registration. In this way we potentially
> KE> eliminate the service disruption caused by L3 handoffs and
> KE> limit the MN's service disruption period to that imposed by
> KE> the specific L2.
>
> Again, this indicates a pretty tight real-time coupling between the
> MIP client and the L2 that we wanted to avoid.
>
        In the MIP client ? where does the draft say or imply that ?

>  Registering after
> the L2 handoff removes this dependency.  Also it eliminates the
> configuration headaches that are implicit in the Fast Handoffs
> scheme: how does the current FA get the advertisement from the
> next FA, how does it propagate the registration over multiple
> routing hops, and how does the new FA associate the registration
> with the soon-to-be-established link-layer connection?
>
        I'm surprised you're bringing this up again. Please refer to our
        previous discussion in the archive and the draft.

        While we're repeating questions :
        How does a proactive FA get the "next" FA's IP address ?

> KE> 4) It is not clear in the proactive approach how an intersystem
> KE> handoff is handled. For example a handoff occuring between two
> KE> different wireless technologies. If the proactive approach is
> KE> to be used for handoffs, and if the MN has a choice of two
> KE> different systems, it is not possible for the MN to choose which
> KE> FA it wants to be connected to (until after the MN has been handed
> KE> off to the new FA). Hence a handoff may result in connecting the
> KE> MN to a less preferred FA. This is especially true if the FAs
> KE> choose not to send agent advertisements for very long periods as
> KE> suggested by the draft. This situation will not arise in Fast
> KE> Handoffs.
>
> Inter-system handoffs using the same technology are exactly where
> the Proactive approach is intended to be used.  The neighboring FAs
> know about each other and have a security association, in the same
> way that neighboring Radio Access Networks in today's cellular systems
> know about each other (otherwise they would not be able to perform
> a hard handoff).  When a handoff from one to another is indicated,
> a proactive tunnel is set up and the handoff indication is sent to
> the MN.  No involvement from the MN's MIP client is required until
> after the real-time handoff is complete.
>
> For inter-system handoffs using different technologies, I don't see
> why the network needs to provide any special support over RFC 2002.
> The MN can presumably use both technologies simultaneously (otherwise
> the handoff cannot possibly be smooth) and can listen for
> advertisements on both devices.
>
        What if the FA's are proactive and are configured not to advertise
for very
        long periods ? Your proposal takes us away from RFC 2002 and that's
        the price you pay.

>  When the MN chooses, and without any
> special assistance from the network, it may register on the new
> technology (let's say, 802.11) and allow its old registration (let's
> say, on the cdma2000 network) to expire.  In the meantime, who cares
> if the MN was momentarily connected to a new cdma2000 RAN?  The
> temporary proactive handoff provides service to the MN while it is
> registering on the 802.11 network, and the MN wasn't required to do
> anything!
>
        Again please refer to my comment above.

> KE> 5) The proactive draft states that a FA MAY choose to send an
> KE> Agent Advertisement to the MN after the handoff has taken place.
> KE> The length of time after which the advertisement is sent is
> KE> unclear. If simultaneous bindings are used (which is suggested by
> KE> the draft), this will result in long lifetimes for the
> KE> simultaneous bindings and consequently an inefficient use of
> KE> bandwidth since multiple copies of the same packet are transmitted
> KE> to FAs. In Fast Handoffs simultaneous bindings will have short
> KE> lifetimes in order to minimize bandwidth consumption.
>
> Obviously, the network operator must decide how to set these parameters
> for optimal network utilization.  If registration is not required for
> some time then use of the 'S' bit may not be appropriate.
>
        The use of S bit was introduced in Fast Handoffs to reduce the
        service interruption. I don't understand the point of associating
its
        use with the registration lifetime. It's needed because it's
important,
        not because it's convenient when the registraion lifetime is short.

> However, if it is possible for the MN to "ping-pong" between two
> different FAs very rapidly, then the simultaneous registrations are
> quite useful - multiple copies of packets are exactly what is desired,
> on copy transmitted from the old FA (if a link layer connection to the
> MN exists there) and another copy from the new FA (again, if a link
> layer connection to the MN exists there).  Forcing the MN to send MIP
> registrations on each ping-pong event is likely to lead to much
> greater strain on the MIP client implementation.
>
        Ok so are you saying that FA's can predict whether ping pong will
happen
        or not before the handoff and then decide whether S bit should be
used or not ?
        It does't sound reasonable to me, hence the point made above.
        Either you use it or not, if you do, then the point above is
relevant and if you
        don't then you have to remove the claims of fixing the ping pong
problem in
        the proactive draft.

> In summary, I think the Fast Handoffs draft has some hidden costs
> associated with it (tight L2 coupling, configuration of adverts from
> neighbor FAs, getting "remote" registration to work properly) that may
> not be immediately obvious on a first read-through.
>
        Could you please be specific ? What are the coupling costs compared
to
        proactive ?

> The Proactive
> draft requires some extra support from the network elements but allows
> us to use a completely vanilla (non real-time) RFC 2002 MIP client
> implementation.
>
        What is a non-real time client ?

> The frequency of advertisements/registrations can be
> adjusted for optimum end-to-end performance without regard to the rate
> of handoffs in the underlying L2 technology.
>
        Yes I realise that, and as I said earlier some of the points Karim
sent shows
        the consequence of loosening the requirements on FA's to advertise.
I'm not saying
        they have to avertise regularly but we believe they MUST advertise
during a handoff.

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sat, 7 Oct 2000 13:22:56 +1100

> >
> > The point is that any further specification of the above interaction
> > of L2/L3 would bring in L2 issues specific to a certain
> wireless/cellular
> > system which is what we decided was out of scope. I think that the
> > above explanation is quite clear.
>
> We need to be careful in setting the scope. In my opinion, what is out of
> scope is a solution that cannot work with known wireless technologies.
>
        => I'm sure you have a good reason for saying that, but could you
        please tell us exactly why this can not work with known wireless
        technologies ?