Subject: RE: [mobile-ip] some comments on the FMIP draft

From: James Kempf <[email-masked]>
Date: Fri, 4 May 2001 08:38:34 -0700 (PDT)

>> 3) As I've said before, it would be nice to decouple 
>>    the need to do the HI/HACK from the rest of this
>>    draft. The mobile node should be able to just 
>>    ask the old access router to buffer its packets
>>    while it's in transition. In fact, this has the
>>    positive side effect if the oldAR doesn't know
>>    anything about the newAR, 
>> 
>	=> I agree with you. But when we discussed the 
>	alternative (MN performs DAD in parallel with 
>	sending and receiving packets) we found that 
>	it may not work in all cases. Also there were 
>	some open issues with ND. I would prefer 
>	that approach (my technical bias) if it 
>	can work. So if you think it can work when
>	considering it in detail, I don't see why not.
>

One of the problems with requiring signalling from the MN after L2 has indicated 
handoff is imminent is that, depending on the particulars of the radio link 
protocol, the signalling has a much higher probability of being dropped or 
corrupted. The reason that handoff typically occurs is because there
is a drop in the radio signal quality or power below what the radio protocol
deems sufficient for low error rate communication having the contracted
quality of service from the mobile node to the current base station. 
We went through this discussion once several months ago on the IPv4 design team. 
I don't know whether it surfaced in the IPv6 discussion at all. 

Because this may not necessarily be the case for all radio protocols (for
example, a nanocell protocol), the IPv4 design team decided to offer
the choice of either having the L3 handoff signalling
originate from the mobile node or having the network do the L3 handoff
signalling. The IPv6 design team chose to combine the two techniques and require
both in all cases. IMHO, the need for low latency handoff is poorly
served by this design, because it requires more signalling than if
the two techniques were separated, but I won't try to second guess
the IPv6 design team without more carefully reading the draft.

In any case, I don't think it would be wise to eliminate the network assisted 
part of the handoff. This would assure that the protocol would work
poorly for radio protocols where degraded radio quality of service 
accompanies an L2 handoff decision, because the MN would be forced
to retransmit if packet loss occured.

		jak

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 May 2001 08:56:43 -0700 (PDT)

I didn't ask for network assisted handoff to be
removed, and I didn't change the number or
location in time of the pre-handoff messages from
MN<->ARold. All I asked is for the buffering to be
done on ARold instead of ARnew (a trivial change,
I think) and making the HI/HACK optional if the MN
is willing to take its chances on the new AR of
doing DAD in a timely fashion.

Also: one other thing that folks are missing in
the current draft is that the arrival of MN on AR
and then sending the F-NA is a security hazard
unless MN can cryptographically prove that it is
the same node on on ARold that is pressing the
"go" button. There would need to be some sort of
identity that is transfered in the HI/HACK and
a new security association at ARnew in order to
prevent this attack.

If you let ARold buffer the packets, you don't run
into this hazard (and time sink) because ARold
could have demanded credentials well in advance to
determine the legitimacy of the BU.

	      Mike

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 04 May 2001 10:39:38 -0700

Hello Jim,

> >>    anything about the newAR,

Yes, the mobile node should be able to ask the oldAR to
buffer its packets.  This should be able to be done at
any time.  However, it's not precisely a fast handover
issue, and so I don't believe it belongs in the fast
handover draft.

> I don't know whether it surfaced in the IPv6 discussion at all.

Any signaling that occurs after the L2 handoff indication is either
taken to be (i) highly unreliable or (ii) received by the new
access router.

The error-prone nature of the wireless link was a constant factor
in our discussion, leading us to choose solutions that were robust
against errors in every situation, weird or not, that we could think
of.  For instance, even though we thought it was quite unlikely
for IPv6 interface identifiers to collide, we still made the protocol
to handle that case.  Every message over the air is assumed to be
unreliable since the air link is itself considered to be unreliable.
There is no assumption that layer 2 guarantees delivery of anything.
To this point, we also tried to minimize signaling over the air.

> the IPv6 design team without more carefully reading the draft.

I do not understand this point.  We did try to minimize the signaling
over the air, and if you can find a way to do it with less, that would
very interesting.  The step we did not take was to specify every possible
way of putting multiple signals in the same packet over the air.  Do you
think we could get by with less if we had separate variants for
network-controlled vs. mobile controlled?  Otherwise, what did you
mean by "combine the two techniques"?

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 May 2001 12:48:28 -0700 (PDT)

> issue, and so I don't believe it belongs in the fast

   I think this makes an argument for decoupling, no?
   As far as I can tell, there were three major things
   that FMIP tried to accomplish:

   1) Forward tunnel establishment from the old AR to the MN
   2) Buffer of packets while in transition
   3) Address Assignment either statefully, or through auto
      conf (with the requisite DAD)

   (1) can use normal MIP semantics, obviously
   (2) if the mobile node can request buffering at whichever
       router will accommodate it, we can allow this to
       be an implementation decision
   (3) can either be done through the normal autoconf,
       or HI/HACK method. From my reading, it seems that
       DAD delays might still happen if ARnew isn't able
       to provide proxy functionality, so this entire
       part of the draft seems orthogonal to the fast
       goals (as in, probably shouldn't use an L2 that
       you want fast handovers on which can't do fast DAD).
       As such, this looks like it, too, can be decoupled.

 > To this point, we also tried to minimize signaling over the air.

   Just to be clear, you're not assuming that what I 
   proposed requires more air time, right? As far as
   I can tell, it doesn't.

	    Mike

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 07 May 2001 11:03:43 -0400

Hi Charlie,
  A host route is a routing table entry or "soft-state" as they call it in HAWAII, one
entry per mobile host,
and binding cache entry is also soft-state information associating MN address with its
care-of address.
  In HMIP, at the MAP binding cache entries are functionally equivalent to host routes
and the packets are tunneled to MN's latest address. Intermediate routers (routers
between MAP and AR) do not keep binding cache entry/ host route for each MN, therefore
normal IP routing is used.
   In case of regreg6 each intermediate regreg6 router keeps an entry per MN
downstream, i.e. host routes.

"Charles E. Perkins" wrote:
Subject:
             Re: [mobile-ip] Final(?) Cut on LMM Requirements
        Date:
             Thu, 03 May 2001 12:37:53 -0700
       From:
             "Charles E. Perkins" <[email-masked]>
 Organization:
             Nokia Research Center
         To:
             Behcet Sarikaya <[email-masked]>
  References:
             1 , 2 , 3

Hello Behcet,

I'll have to get back to you on this.

In the meantime, what is the difference between a host
route and a binding cache entry?

Regards,
Charlie P.

Behcet Sarikaya wrote:
>
> Hi Charlie,
>   I found your reference to host routes rather odd.
> I think that HMIPv6 does not have host routes
> maybe expect at the MAP, however regreg6 seems to
> have host routes in routers.
>   Can you please shed some light onto this?
>
> "Charles E. Perkins" wrote:
>
> > Hello folks,
> >
> > I'm finding it difficult to keep up with all the discussion,
> > but the following two items stand out:
> >
> > > 5. LMM shall scale to support millions of nodes.
> > > (Comment had been that this was too broad but only other suggestion
> > > was:
> > > "LMM shall scale so that the number of LMM agents scale linearly or
> > > sublinearly with the number of deployed subnets, not the number of
> > > mobiles." Unless there is more support for the revision we'll stay
> > > with the original)
> >
> > I think the original is better, unless someone can demonstrate that
> > it is actually possible to achieve the suggested linear or sublinear
> > growth rate.
> >
> > > 10. LMM should support autoconfig.
> >
> > Part of the problem of LMM is to figure out what the mobility
> > routing agents are doing, and where they are to be located.
> > If LMM involves host routes, then another part of the problem
> > will be to manage the distribution of the host routes.  A third
> > part of the problem will be to find ways for the mobility routing
> > agents to be able to discover their interrelationships (e.g.,
> > how they fit in a hierarchy or mesh, perhaps).
> >
> > These problems do not all have to be solved at the same time,
> > and therefore not all in the same draft.  So, for instance,
> > one scheme for the distribution of host routes could be compatible
> > with multiple schemes for autoconfiguration.  I'd even suggest
> > that manual configuration is acceptable until we have some
> > experience with testing and deployment of some scheme.  However,
> > this is not at all to say that autoconfiguration schemes are
> > not of interest.  It's just that we can go a long way towards
> > solving LMM problems without the necessary requirement for
> > autoconfiguration.
> >
> > As an example, I think it would be very reasonable to have
> > a Proposed Standard for LMM possibly months or even a year
> > before having a Proposed Standard for LMM autoconfiguration.
> > Look at the example of Router Renumbering for IPv6.  On the
> > other hand, if we have both ready sooner, so much the better!
> >
> > Regards,
> > Charlie P.
Regards,
--
Behcet