Subject: [mobile-ip] MD text

From: Jari Arkko <[email-masked]>
Date: Tue, 13 May 2003 20:45:12 +0300

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/mobilev6.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: "Ed Remmell" <[email-masked]>
Date: Tue, 13 May 2003 10:57:16 -0700

Jari -

Looks good, a minor nit in Erik's L2 text:
s/bidirectionally/bi-directionally/

Thanks!
- Ed

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jari Arkko
> Sent: Tuesday, May 13, 2003 10:45 AM
> To: Mobile IPv6 mailling list
> Subject: [mobile-ip] MD text
> 
> 
> Hi,
>

---

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

Dear Jari

It works for me. Thanks for good work. 

Regards

JinHyeock.