Subject: RE: [mobile-ip] MD text

From: <[email-masked]>
Date: Tue, 13 May 2003 13:56:47 -0500

Folks, 

This the final version of the MD text. Any further discussion on
this topic will not impact the text in the MIPv6 base specification.

-chairs

> 
> Hi,
> 
> Here's the final (I hope) text on Movement Detection. Basically
> Ed's version + Erik's L2 + some wordsmithing from me.
> 
> http://www.piuha.net/~jarkko/publications/mipv6/drafts/mobilev
> 6.html#move
> 
> 11.5.1 Movement Detection
> 
>     The primary goal of movement detection is to detect L3 handovers.
>     This section does not attempt to specify a fast movement detection
>     algorithm which will function optimally for all types of
>     applications, link-layers and deployment scenarios; instead, it
>     describes a generic method that uses the facilities of 
> IPv6 Neighbor
>     Discovery, including Router Discovery and Neighbor Unreachability
>     Detection.  At the time of this writing, this method is considered
>     well enough understood to recommend for standardization, 
> however it
>     is expected that future versions of this specification or other
>     specifications may contain updated versions of the 
> movement detection
>     algorithm that have better performance.
> 
>     Generic movement detection uses Neighbor Unreachability 
> Detection to
>     detect when the default router is no longer bi-directionally
>     reachable, in which case the mobile node must discover a 
> new default
>     router (usually on a new link).  However, this detection 
> only occurs
>     when the mobile node has packets to send, and in the absence of
>     frequent Router Advertisements or indications from the link-layer,
>     the mobile node might become unaware of an L3 handover 
> that occurred.
>     Therefore, the mobile node should supplement this method 
> with other
>     information whenever it is available to the mobile node 
> (e.g., from
>     lower protocol layers).
> 
>     When the mobile node detects an L3 handover, it performs Duplicate
>     Address Detection [13] on its link-local address, selects a new
>     default router as a consequence of Router Discovery, and then
>     performs Prefix Discovery with that new router to form new care-of
>     address(es) as described in Section 11.5.2.  It then registers its
>     new primary care-of address with its home agent as described in
>     Section 11.7.1.  After updating its home registration, the mobile
>     node then updates associated mobility bindings in 
> correspondent nodes
>     that it is performing route optimization with as 
> specified in Section
>     11.7.2.
> 
>     Due to the temporary packet flow disruption and signaling overhead
>     involved in updating mobility bindings, the mobile node 
> should avoid
>     performing an L3 handover until it is strictly necessary.
>     Specifically, when the mobile node receives a Router Advertisement
>     from a new router that contains a different set of 
> on-link prefixes,
>     if the mobile node detects that the currently selected 
> default router
>     on the old link is still bi-directionally reachable, it should
>     generally continue to use the old router on the old link 
> rather than
>     switch away from it to use a new default router.
> 
>     Mobile nodes can use the information in received Router
>     Advertisements to detect L3 handovers.  In doing so the 
> mobile node
>     needs to consider the following issues:
> 
>     o  There might be multiple routers on the same link, thus 
> hearing a
>        new router does not necessarily constitute an L3 handover.
> 
>     o  When there are multiple routers on the same link they might
>        advertise different prefixes.  Thus even hearing a new 
> router with
>        a new prefix might not be a reliable indication of an 
> L3 handover.
> 
>     o  The link-local addresses of routers are not globally 
> unique, hence
>        after completing an L3 handover the mobile node might 
> continue to
>        receive Router Advertisements with the same link-local source
>        address.  This might be common if routers use the same 
> link-local
>        address on multiple interfaces.  This issue can be avoided when
>        routers use the Router Address (R) bit, since that provides a
>        global address of the router.
> 
>     In addition, the mobile node should consider the 
> following events as
>     indications that an L3 handover may have occurred.  Upon receiving
>     such indications, the mobile node needs to perform Router 
> Discovery
>     to discover routers and prefixes on the new link, as described in
>     Section 6.3.7 of RFC 2461 [12].
> 
>     o  If Router Advertisements that the mobile node receives 
> include an
>        Advertisement Interval option, the mobile node may use its
>        Advertisement Interval field as an indication of the frequency
>        with which it should expect to continue to receive future
>        Advertisements from that router.  This field specifies 
> the minimum
>        rate (the maximum amount of time between successive
>        Advertisements) that the mobile node should expect.  If this
>        amount of time elapses without the mobile node receiving any
>        Advertisement from this router, the mobile node can be 
> sure that
>        at least one Advertisement sent by the router has been 
> lost.  The
>        mobile node can then implement its own policy to determine how
>        many lost Advertisements from its current default router
>        constitute an L3 handover indication.
> 
>     o  Neighbor Unreachability Detection determines that the default
>        router is no longer reachable.
> 
>     o  With some types of networks, notification that an L2 
> handover has
>        occurred might be obtained from lower layer protocols or device
>        driver software within the mobile node.  While furthers details
>        around handling L2 indications as movement hints is an item for
>        further study, at the time of writing this specification the
>        following is considered reasonable:
> 
>        An L2 handover indication may or may not imply L2 
> movement and L2
>        movement may or may not imply L3 movement; the 
> correlations might
>        be a function of the type of L2 but might also be a function of
>        actual deployment of the radio topology.  Unless it is 
> well-known
>        that an L2 handover indication is likely to imply L3 movement,
>        instead of immediately multicasting a router 
> solicitation it may
>        be better to attempt to verify whether the default 
> router is still
>        bidirectionally reachable.  This can be accomplished 
> by sending a
>        unicast Neighbor Solicitation and waiting for a Neighbor
>        Advertisement with the solicited flag set.  Note that this is
>        similar to Neighbor Unreachability detection but it 
> does not have
>        the same state machine, such as the STALE state.  If 
> the default
>        router does not respond to the Neighbor Solicitation it makes
>        sense to proceed to multicasting a Router Solicitation.
> 
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 14 May 2003 09:16:53 +0900

Dear Chairs.

> this topic will not impact the text in the MIPv6 base specification.

I agree that the current MD text is good enough for MIPv6 
base spec. 

But I think there still remain much to be investigated. Moreover 
I am afraid that there is no agreed way to detect movement yet. 

Now, as Vijay said, we'd better present at least one efficient and 
reliable MD method to implementators quickly. Kindly see to it. 
 
Best regards

JinHyeock

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 May 2003 13:08:06 +0300

> reliable MD method to implementators quickly. Kindly see to it. 

Isn't there a plan to have a set of new mobility-related WGs,
one of which is expected to look at MD issues? If I remember
correctly, the MD work was expected to be slightly more general
than just for MIPv6 (take in account DHCP as well etc).

So, it appears that there will be an effort to do this. Also,
people are working on drafts already. But I don't have any
information as to when these new WGs will be started, what
their final charter will be etc. Any news on that, anyone?

--Jari

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 14 May 2003 14:32:13 +0200

Jari Arkko wrote:
 > ...But I don't have any

The chairs are discussing this right now with Thomas and Erik.
In particular, we're directly involved with 3 groups which
will focus on mip4, mip6 ("basic") and mip6 signalling and
handoff optimization (i.e., HMIPv6 and FMIPv6).

Thomas and Erik are handling the MD related working group, but I have
no further info on that. And as you said, this is not considered
a "mobility" working group in that this is more generally
applicable.

-gabriel

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 15 May 2003 11:09:17 +0900

Dear Gabriel 

> a "mobility" working group in that this is more generally

I agree that MD work is more general but think that it affects 
'mobility' the most. Doesn't M in MD represent 'Movement'? :-).  

I am afraid that currently there is not one default MD method 
on which MIPv6 implementators can safely fall back on. 

In brief
1) Eager cell switching may result in excessive & unnecessary handoff.  
2) (pseudo) NUD and Router Discovery will take more than 3 secs, 
     which is likely disrupt on-going TCP session.
3) NS probe, timeout and Router Discovery seems promising. But 
     it still needs more investigation.  

I am worried that this defect will delay MIPv6 deployment. I 
will be more worried if we don't have a definite plan to make up 
this defect either. (I had assumed that mobileip WG (or its progeny) 
would publish a draft on default MD method after MIPv6 work.) 
 
IMHO, for quick MIPv6 deployment, quick MD method should 
be done quickly. As Jari wrote, people are already working on 
drafts. I hope we move these works quickly, whether in mobileip 
WG or in other related WG. 

Best regards

JinHyeock.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 May 2003 08:31:32 -0700

JinHyeock,

> would publish a draft on default MD method after MIPv6 work.)

I do not think that this will have any effect on MIPv6 deployment
whatsoever. Handoff performance is a very minor part of why a wireless
service provider might want to provide MIPv6, though those of us
researching the area would like to think that it is *the* major
reason. :-)  There are far higher barriers to MIPv6 deployment,
starting with the lack of widespread IPv6 deployment.

            jak

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 20 May 2003 08:36:40 +1000

On Thu, May 15, 2003 at 08:31:32AM -0700, James Kempf wrote:
> service provider might want to provide MIPv6 [...]

I'd agree with you there, James.  Which is why it's really important
for us to get a base spec 'out there' as soon as possible, even if
it has ~3 second handovers.

ObHysteria: Otherwise Starbucks will standardize on IPv4/NAT, and 
the world will end!

-----Nick