Subject: Re: Movement Detection (was Re: [mobile-ip] Connectathon 2003 issuesfor MIPv6 draft-20)

From: "Paul Tan Hock Lai" <[email-masked]>
Date: Tue, 18 Mar 2003 00:01:32 +0800

hi all,

>> Erik Nordmark <[email-masked]> >>
>> If you know that the MNs can get a local trigger from L2 that they
>> might have moved, then there is no need to waste bandwidth by sending
>> RAs every 50ms. 
>> The frequent RAs help when there is no such local trigger.

I have done some studies on using L2 messages to carry L3 information (e.g. Prefix Option). I believe that this approach ('tagging cables with label') allows MN to detect L3 movement and also its neighboring ARs more 'quickly'. It is more reliable in a scenerio where there are 2 different ARs on the same link. MN might incorrectly interprete its L3 movement.

You are most welcome to comment on my draft (http://www.ietf.org/internet-drafts/draft-paultan-seamless-ipv6-handoff-802-00.txt).

I am in the process of performing some work (simulation) on this draft, and would really hope to hear/gather some comments (good/bad).

Cheers,
Paul

>>> Erik Nordmark <[email-masked]> 03/17/03 05:18AM >>>
> If the L2 hints that a link may have changed then this is
> a more reliable reason why you would believe an RA from
> a previously unseen router.  This doesn't necessarily
> entail RS/RA exchange with a new router, especially if the
> new network undertakes the MIPv6 RA beaconing behaviour
> (~50ms spacing), or network side L2 systems provide or
> prompt an RA upon MN association.

If you know that the MNs can get a local trigger from L2 that they
might have moved, then there is no need to waste bandwidth by sending
RAs every 50ms. The frequent RAs help when there is no such local trigger.

And the frequent RAs don't guarantee that you've moved.
In somebody adds an additional router on the link
(or an additional existing router can reach the MN)
then it doesn't mean that the old router is no longer bidrectionally
reachable. An RS/RA exchange will indicate whether the old router is
still bidirectionally reachable.

> It doesn't handle the issue of RS delay, which is highly
> link-layer dependent.  The delays (also shared by DAD) seem
> to be aimed at reducing multicast packet bombing on links
> where many devices are configuring at once.
> This can happen in MIPv6 if many devices move and transmit
> simultaneously.

It would be good to have some (experimental or simulation) data on this.
In practise how close together would a busload or trainload of operating
MNs get a movement hint (from L2 or from frequent RA beacons) when
they move as a unit from one link to another?
If they would all move within milliseconds I think it would be required
to have some randomization.

> At this stage, our early 802.11b tests with 10 nodes
> simultaneously transmitting multicast packets have shown few
> problems (all packets received in <20 ms, little or no
> packet loss).  This isn't particularly helpful if the number
> of devices moving simultaneously exceed these values.
> So we're focussing on MAC simulation, in order to
> characterize behaviour in this area.

Great that you are looking into this.

> RA rate limiting is relatively straightforward, if
> the MN has an address from which it can send the original
> RS (FastRA).  I'm not sure that we'd want to significantly
> reduce the interval between solicited Multicast RA messages,
> which is the only available response if the RS comes from the
> unspecified address.

Good point.
I guess it depends on how accurate the movement hints are.
If a movement hint with high probability corresponds to an actual movement
there might not be much harm to send a multicast RA in response to an RS,
because each movement will already incur a few multicast messages
(MLD join of solicited node MC address(es), DAD, RS to find new routers).
But if 90% of the movement hints are false (e.g. due to frequent L2 going up
and down) then it would be a problem to incur additional multicast packets.
In that case a strategy that first performs a unicast RS/RA exchange with the
old default router(s) would make more sense.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Tue, 18 Mar 2003 09:25:33 +1100

Hi Paul,

Here is a little feedback about the L2 movement
detection scheme.

At this stage we have not worked on L2 message specific
movement detection algorithms, but understand that
these will be the fastest movement detection systems.
(They can receive movement information at the time
that L3 comes up).

In dicussion (for completeness sake) they are important.

The modification of link-layers so that they
parse and pass complete 'user-to-user' information
though ties L3 movement to explicit support from L2 drivers.
This support may not be available for some time, especially
in 802.11 client devices where most of the received L2
signalling is handled in firmware.

I'll be interested in the outcomes of your work, but
am worried that the requirement to modify the L2 signalling
and interpretation on every base station and MN is
too onerous for a primary MIPv6 movement detection mechanism.

Certainly, where it is available, it sounds like it
will work consistently and quickly.

Greg D.