Hi some commente regarding the movement detection algorithm.
I agree that it might not be a good idea to tie your movement detection to
when you are seeing an advertisement from a router with a different prefix.

First of all - the statemachine for the movementdetection can be at two
places - either in the 1) mobile node (which is the case today) or 2) it can
sit in the network and then you could have network controlled handoff.

To improve handoff you must make increase mobile IP's link-layer awarness.
This is usually achived by listening on the field strengh or something
similar of the radio link. The solution is different for every different
radio link you have.

Take 802.11 ethernet for instance, there you can associate every radio cell
(and AP) to an IP subnet with a new prefix or you can associate several AP
to an IP subnet (recomended). In case 1) you can associate every radio cell
with a subnetprefix and you modify you movement detection algoritm (MDA) so
that it builds up an internal list with prefixes and subnet and associated
field strengh.

For instance:
General Parameters:
Joning treshsholds: xxx dBm
Leaving Treshholds: xxx dBm

CoA        Current Subnet   Field strengh  Active CoA
CoA1         Prefix 1                   xx dBm           ---
CoA2         Prefix 2                   xx dBm        Active
CoA3         Prefix 3                   xx dBm           ---
CoA4         Prefix 4                   xx dBm           ---
CoA5         Prefix 5                   xx dBm           ---

The intention is also to start bulding new CoA before you must switch over
to a new AP which will make you handover quicker. You listens on the field
strengh of the different radio cells or subnets and associate make you
handover based on the field strengh.

This approach could also be done from the AP or BS which would be a good
aproach o a WAN radio like GSM or CDMA. Then the movement detection
algorithm sits (it is not called that in GSM terms) in a BSC and in tells
you to do you handover but in this case you would have to interupt that let
mobile IP have that info and then mobile IP could be invoked in network
initiated handoffs. This is nice on paper and would really optimize the
radio network for IP but there is a lot of polotics here which can make it
very difficult.

You can also include QoS parameter in your handover design and you can make
it very advanced.

In other it is nothing in the spec that stops you from achieving very good
handoffs.

-- Thomas Eklund








----- Original Message -----
From: "Francis Dupont" <[EMAIL PROTECTED]>
To: "John F. Leser" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, October 17, 2000 4:15 PM
Subject: Re: [MOBILE-IP] MIPv6 node location detection


> In your previous mail you wrote:
>
>    Reading through section 10.4 of the MIPv6 draft (version 12), I get the
>    impression that:
>
>    1. Movement detection is not a simple problem to solve.  The draft
>    doesn't really specifiy what method should be used.
>
> => there are many different methods, some of them are (too) slow,
> some of them can detect movements when there is no movement, this can
> be a problem or not... I think we need to get results from fast/smart/...
> handoff special group and from implemention experiences.
>
>    2. Seeing an adverisement from a router with a different prefix is not
a
>    good way to detect movement.
>
> => I agree but the other way is not better.
>
>    The preferred movement detection method seems to be loss of
>    reachability of the MN's default router,
>
> => this is not good if there are more than one router and of course
> is very bad if the number of potential default routers is large enough...
>
>    which is noticed through neighbor unreachability detection
>
> => which uses neighbor solicitations, not router solicitations !
>
>    and/or use of the router advertisement interval option.
>
> => this point should be added into neighbor discovery specs (ie.
> it is useful in general, not only for mobility).
>
>    > > I also can't find RFC or draft which define exactly address list in
a
>    > > MIPv6 MN. A IPv6 node have a address list and  every prefix has
lifetime
>
> => in *theory* the list is the union of local prefixes and home prefixes,
> both are in router advertisements on the local link and through the tunnel
> with the home agent with the according lifetimes. In order to get the
whole
> list ASAP someone suggested in this list that the home agent sends router
> advertisements to the MN when a home registration is done.
>
> The issue is what happens if the home link is renumbered when the MN is
> stopped. In fact this depends on how the MN knows its home prefix(es):
>  - very stupid implementations believe the MN is started at home then
>    the home prefixes will be prefixes of the first attached link: no
>    problem with renumbering.
>  - stupid implementations use a static config in order to know home
>    prefixes then if the config is too old the MN will not be able to
>    find its home link (and a home agent).
>  - someone suggested in the list to use a name which can be updated
>    when the home prefix is renumbered (but not renamed :-). It is a
>    fine idea out of the scope of the mobile IPv6 draft.
> I think most implementations use the second way (static config)...
>
> An open question is what to do with DHCPv6?
>
> Regards
>
> [EMAIL PROTECTED]
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to