Subject: [MOBILE-IP] Comments on draft-calhoun-mobileip-proactive-fa-02.txt

From: Phil Neumiller <[email-masked]>
Date: Wed, 27 Sep 2000 10:35:25 -0500

1).  Sec 1.2 says "MNs connect to FAs via direct, link layer connections.

I disagree, this is not necessary nor desirable in all cases.  The FA in theory
could gain access to "subtending" link layer info through a variety of
mechanisms.
Why must it be assumed that the FA is co-located with the link layer equipment?

2).  In the discussion of the triggering mechanism.  FA handover candidates
should
       be configurable and/or discoverable automagically, allowing active sets
of
       overlapping coverage areas (more on this below).

3).  In 1.2 "problems that must be addressed" section under (1).  Why worry
about
      registration?   Can't we just go ahead and perform the handoff and
register in
     parallel?  If the registration  fails then boot the MN, but get the traffic
going first
     at all costs.

4).  In section 1.2 sub 3, we should allow bi-cast, and tri-cast to all the
candidate FAs that
      were "discovered" as descibed in 2 above.  Gee, this is starting to sound
like
      OBAST! :-)

5).  In sec 1.2 sub 6., mobile power consumption can be reduced by having MORE
      FAs listening and performing selection at the anchor FA.  Yikes, this
smells of
     OBAST! :-)

6).  In sec 2.1 the GFA in theory could be co-located with the one of the two
bi-casting
       FAs.  This would reduce the box count (and this is what OBAST does with
its
      call anchor).

7).  With respect to Movement detection, could we not generalize this coverage
       detection?  The MN knows its in the coverage are of a collection of
subnets
       and can establish new FA relationships with each new subnet, selectively
       dropping the old FA relationships as that coverage disappears.  Why can't
       traffic be deliverec while registration is occuring?  Presumably the MN
already
      has connections with other hosts that are valid.

8).  If a new link layer is detected by a MN it could tell its current FA about
it
      and the FA would know about all valid hand off candidates for that link
type
      due to hand off candidate discovery as described in 2 above.

//BEGIN (:-))
For those of you born after about 1980,  Phil is starting to sound like a piece
of vinyl with grooves encoded with music that would often get  cross threaded
causing the needle to play the same grooves of music over and over again.
//END (:-))

9).  It would not take much of nudge to make this thing work with a make-before
      break capability, then I would be happy and probably shut up!  Do you want
     me take a stab at this?

10).  In section 3.1, To avoid ping-ponging we can use the trick CDMA uses.
         USE MAKE BEFORE BREAK, and add and drops multiple simultaneously
         bi-casted, tri-casted call legs!  Then thresholds can be added.  You
can
         make decisions like, gee statistically, this particular link layer
isn't buying
         me squat anymore, i.e. I don't use the packets coming from that link
layer
        so that active leg can be dropped.

11).  I take objection to including section 9.0-9.2.  All link layers should be
addressed
        in generalities with maybe a distinction between fixed and wireless
being allowed.
        Of course I am not a fan of the MIER approach at all.

Thanks,

Phil

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 Sep 2000 11:07:02 -0700

> I disagree, this is not necessary nor desirable in all cases.  The FA in
> theory could gain access to "subtending" link layer info through a variety of
> mechanisms. Why must it be assumed that the FA is co-located with the link
> layer equipment?

If there is another layer of abstraction, and the trigger makes it to the FA,
then we are happy. I am not really sure that we need to go there in the
document, but if you feel that strongly about it, I can add such text.

>        be configurable and/or discoverable automagically, allowing active
> sets of

good because more is needed in order for me to decode your comment :)

>      parallel?  If the registration  fails then boot the MN, but get the
> traffic going first
>      at all costs.

exactly what our draft does. We simply listed the issues that we know of in
that section. We could add a "Get data to new cell before registration", but
it is covered elsewhere and if you notice, each one of those bullets has a
corresponding section.

>       were "discovered" as descibed in 2 above.  Gee, this is starting to
> sound like
>       OBAST! :-)

So you must like it, then :)

>       FAs listening and performing selection at the anchor FA.  Yikes, this

see above comment

>        FAs.  This would reduce the box count (and this is what OBAST does
> with its
>       call anchor).
I agree, and we support both what we call anchor FA and GFA. We needed to
support both of these modes to comply with the Regional Registration I-D.
Personally, I would prefer NOT to support GFA directly, but only the anchor
mode. If a GFA is deployed in the network, it would be used by the anchor FA
(not the new FA).

IMHO, this would really simplify the I-D.

>        traffic be deliverec while registration is occuring?  Presumably the
> MN already

Not sure I understand your comment, because the way I read it, the draft
already does this.

>
> 8).  If a new link layer is detected by a MN it could tell its current FA
> about it

and this information is sent in the air interface message, right? Are you
proposing that this also has to be sent in the layer 3 (Mobile IP) message?

>
> //BEGIN (:-))
> For those of you born after about 1980,  Phil is starting to sound like a
> piece of vinyl with grooves encoded with music that would often get  cross
> threaded causing the needle to play the same grooves of music over and over
> again. //END (:-))

Yeah, and I had to trash all my vinyls about 6 months ago.... :)

>       break capability, then I would be happy and probably shut up!  Do you

Please do!

>         so that active leg can be dropped.

but our I-D already does this, right? What is missing?

>
> 11).  I take objection to including section 9.0-9.2.  All link layers should
> be addressed

Whether MIER is good or not, it is irrelevant. We have limited address space,
and MIER allows us to conserve some space. What, exactly, would you prefer to
see in sections 9.0-9.2?

Thanks for all the great comments. Certainly does deserve at least one free
beer (which reminds me, we really need to meet in Munich again!).

PatC