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

From: Pete McCann <[email-masked]>
Date: Tue, 3 Oct 2000 13:11:52 -0500

Hi, all,

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

>>
>>
>> 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?

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

Right, the document just makes the "link layer connectivity" abstraction,
which means that MNs are link-layer addressable and reachable from the
FA.  How you actually implement that abstraction is another question,
and I don't see any need for the document to go deeper into it.

> 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).

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

It sounds like Phil is asking for the draft to support soft handoff.
I strongly disagree with this - soft handoff is a technology-specific
thing that should take place underneath Mobile IP.  The "proactive"
draft is designed with "hard handoff" between the FAs in mind.

>> 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.

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

Right, I believe the draft provides exactly the "register in parallel"
solution.

>> 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! :-)

psc> So you must like it, then :)

Again, we are not trying to reinvent soft handoff!  If you want to do
that in the new working group, go ahead, but it is underneath what we
are trying to accomplish.  We are adding mechanisms to support
fast hard handoff between two different network attachment points.

>> 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! :-)

psc> see above comment

See my above comments - this is not about frame selection!

>> 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).

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

psc> IMHO, this would really simplify the I-D.

I also think that anchor is more important than GFA, and I'm glad we
support AFA and wouldn't mind removing GFA support.  However, given that
it's so trivial to support (just put the GFA address in the Update
message) and given that there is a constituency, I think it's best
to leave it in.

>> 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.

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

Again, Phil is trying to do soft handoff in the framework of our draft.
Our draft is intended for hard handoff.  We do not assume that the MN has
the ability to talk to more than one FA at any given moment - in other
words, the FA is behind the frame selector.  I do not think other
approaches make sense.

>> 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.

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

The "trigger" for the handoff could be based on power measurements as Phil
states - but that's a link-layer mechanism, and I don't think we should go
extending Mobile IP with a candidate list and/or power measurements.  That's
the job of the link layer.

>> //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 (:-))

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

>>
>> 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?

psc> Please do!

I would object to attempts to solve the soft handoff problem with this
draft.  It is intended for network-layer handoff, not link-layer handoff.

>> 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.

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

No, our draft does not do this, and shouldn't.  We assume that a
handoff takes place between two FAs connected to two different radio
access networks.  This is a hard handoff with no make-before-break
support, which contrary to popular belief, is NOT supported by today's
cdma air interfaces.

>> 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.

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

The link-layer address can be used as an opaque identifier, and
doesn't need to be understood by the FA, so the protocol is not
link-layer specific.  We just need to maintain a type space to
keep the identifiers unique across different technologies.  If
you have another technology in mind speak up and we can start to
fill in the type space.

-Pete