Subject: RE: [mobile-ip] Re: Current movement detection process

From: "Ed Remmell" <[email-masked]>
Date: Thu, 8 May 2003 19:16:06 -0700

JinHyeock -

Thanks, this was a useful review of everything we've discussed up to this
point.

I'm starting to be persuaded (I'm not sure who's responsible for this, James
Kempf? ;-) that switch the current default router whenever you get a RA from
a new default router (and thus also changing the primary CoA) may not be a
bad model to start from - it means that the MN needs to keep a cache of all
default routers that it believes are current bi-directionally reachable
(which it may not have confirmed), then when it discovers a new router by
receiving a RA from a router not in that list, it does the following:

1) if the RA doesn't contain a global-scope prefix that can be used to
auto-configure a new primary CoA, then ignore it.
2) otherwise:
2.1) add the router's link-local scope address to the router list, with the
other associated information including prefixes discovered in that RA, the
router's global address if available, etc.
2.2) immediately solicit that router using a unicast NS. If the router
responds to the solicitation with a solicited NA indicating that it is
bi-directionally reachable:
2.2.1) immediately switch to that current default router, form a new primary
care-of address using the prefix information it advertised and update
mobility bindings with the new care-of address

Then, for each entry in this router cache/list, we'd need to track two types
of reachability confirmation:
1) reachability from router, detected by receiving RA from that router
2) NUD bi-directional reachability, detected via unicast NS/NA probing
(periodically).

When we haven't received either of these reachability indications for a
given router for some period of time, it is deleted from the list, and all
associated prefixes, CoAs, etc. there were discovered using it are also
invalidated at the same time.

I haven't implemented our MN move detection yet (we do it through explicit
L2 triggers, currently), I have designed it the way I described previously -
but I'm starting to think I may instead actually implement something closer
to the above.

Thanks!
- Ed
  -----Original Message-----
  From: JinHyeock Choi [mailto:[email-masked]]
  Sent: Thursday, May 08, 2003 6:57 PM
  To: Ed Remmell; Jari Arkko
  Cc: James Kempf; Erik Nordmark; [email-masked];
[email-masked]
  Subject: Re: [mobile-ip] Re: Current movement detection process

  Dear Ed

  > OK, I will work on it this afternoon. I'll go through all of the latest
  > postings on MN, massage/restructure the latest text for MD you posted,
and
  > make these additions where it makes sense. I should have some
new/proposed
  > MD text to send to the list later today.

  Greg and I are updating the following ID.

  Movement Detection Optimization in Mobile IPv6
  (draft-daley-mobileip-movedetect-00.txt)

  We try to incorporate into the text the recent discussion
  on the mailing list. So we think our work may help yours.

  Kindly find an attached file. The contents are like this.

  2.0 The Current Status of Movement Detection
    2.1. Handoff Process
    2.2. Movement Detection Overview
    2.3. Movement Detection Mechanism
    2.4. Movement Detection Performance with Neighbor Discovery

  If you read it and provide some feedback, we will appreciate
  it very much.

  Best regards

  JinHyeock.

---

From: Greg Daley <[email-masked]>
Date: Fri, 09 May 2003 13:33:25 +1000

Hi Ed,

We have also been thinking about whether it is useful to have
a 'current routers' list.

This would mean that in the worst case, there would be N handovers
for each of N routers on the link.  This could only occur if the
routers weren't sending intersecting sets of global prefixes.

This is implicitly an eager binding system with a cache though,
and will detect false movement unless we're careful.

Ed Remmell wrote:
> JinHyeock -
>  
> Thanks, this was a useful review of everything we've discussed up to 
> this point.
>  
> I'm starting to be persuaded (I'm not sure who's responsible for this, 
> James Kempf? ;-) that switch the current default router whenever you get 
> a RA from a new default router (and thus also changing the primary CoA) 
> may not be a bad model to start from - it means that the MN needs to 
> keep a cache of all default routers that it believes are current 
> bi-directionally reachable (which it may not have confirmed), then when 
> it discovers a new router by receiving a RA from a router not in that 
> list, it does the following:
>  
> 2.1) add the router's link-local scope address to the router list, with 
> the other associated information including prefixes discovered in that 
> RA, the router's global address if available, etc.

I think that it may be worthwhile to check if the router advertises
the current CoA's prefix (with an RS/RA). In this case,
no movement has occurred.

Unicast NS tells us the node is available, but doesn't tell us all
the router information.

> 2.2.1) immediately switch to that current default router, form a new 
> primary care-of address using the prefix information it advertised and 
> update mobility bindings with the new care-of address
 >
> Then, for each entry in this router cache/list, we'd need to track two 
> types of reachability confirmation:
> given router for some period of time, it is deleted from the list, and 
> all associated prefixes, CoAs, etc. there were discovered using it are 
> also invalidated at the same time.

Indeed, though I think Brett and JinHyeock are working on a simpler
way to achieve this (no more hints yet though).

> I haven't implemented our MN move detection yet (we do it through 
> explicit L2 triggers, currently), I have designed it the way I described 
> previously - but I'm starting to think I may instead actually implement 
> something closer to the above.

I think that if we can determine that no-movement has occurred quickly,
we should probably prefer that mechanism, for precisely the reasons
outlined before (signalling overhead, halts to packet transmission).

Certainly, I think that the level of detail in the base draft is OK for
now, but we've definitely got a momentum going to find a better MD
solution for a separate document.

Greg

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 08 May 2003 21:19:15 -0700

Hello Greg,

What you say is true, but it turns out in practice that the results
are not at all bad.  Even if there are multiple beacons on power
up, and the mobile device makes some extraneous handovers,
it's not such a big deal.  The payoff in responsivity to forward
motion is well worth the downsides, for "inertial" trajectories.
It is very easy to cook up trajectories that defeat the eager cell-
switching strategy, but they make people dizzy and so aren't
often used.  There is literature about this but I am not now at a
place to dig it up.   I also don't want to minimize the fact that this
is actually a pretty complicated subject.

Regards,
Charlie P.

Greg Daley wrote:

>> I'm starting to be persuaded (I'm not sure who's responsible for 
>> this, James Kempf? ;-) that switch the current default router 
>> whenever you get a RA from a new default router (and thus also 
>> changing the primary CoA) may not be a bad model to start from - it 
>> means that the MN needs to keep a cache of all default routers that 
>> it believes are current bi-directionally reachable (which it may not 
>> have confirmed), then when it discovers a new router by receiving a 
>> RA from a router not in that list, it does the following:
>>  
>> 1) if the RA doesn't contain a global-scope prefix that can be used 
>> to auto-configure a new primary CoA, then ignore it.
>> 2) otherwise:
>> 2.1) add the router's link-local scope address to the router list, 
>> with the other associated information including prefixes discovered 
>> in that RA, the router's global address if available, etc.
>> 2.2) immediately solicit that router using a unicast NS. If the 
>> router responds to the solicitation with a solicited NA indicating 
>> that it is bi-directionally reachable:
>
>
>> primary care-of address using the prefix information it advertised 
>> and update mobility bindings with the new care-of address
>
> >
>
>> Then, for each entry in this router cache/list, we'd need to track 
>> two types of reachability confirmation:
>> 2) NUD bi-directional reachability, detected via unicast NS/NA 
>> probing (periodically).
>>  
>> When we haven't received either of these reachability indications for 
>> a given router for some period of time, it is deleted from the list, 
>> and all associated prefixes, CoAs, etc. there were discovered using 
>> it are also invalidated at the same time.
>
>
>> explicit L2 triggers, currently), I have designed it the way I 
>> described previously - but I'm starting to think I may instead 
>> actually implement something closer to the above.
>
>

---

From: Greg Daley <[email-masked]>
Date: Fri, 09 May 2003 15:43:00 +1000

Hi Charlie,

I've read some literature myself on the subject, and
can see the benefits of eager cell switching.

At the moment I am interested in finding out if Movement
Detection can be performed using more definite movement
information. It may be possible to supplement the supplied
RA information in such a way that the 2nd..Nth router
responding on the MN's new link doesn't cause handover
signalling.

This should not mean discarding eager cell switching, though.

If you have a particular reference in mind, I am
certainly interested in reading it later, though.

Greg

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 9 May 2003 09:05:02 -0700

Greg -

> Unicast NS tells us the node is available, but doesn't tell us all

You do this after having received a RA from a new router. Hence, you already
have the router information. Before switching to a new router, however, you
should verify that it is bi-directionally reachable. That is what the
unicast NS/NA exchange is for. This is only intended for the case where you
are switching away from a perfectly good bi-directionally reachable router
to start using a new router that you just discovered - you need to confirm
that the new router is bi-directionally reachable first, before you do the
switch. It is possible that you can hear the new router's RA beacons, but it
can't hear you.

Thanks.
- Ed