[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Mobile-IP Working Group                                      Greg Daley
INTERNET-DRAFT                                   Monash University CTIE
Expires: December 2003                                   JinHyoeck Choi
                                                            Samsung AIT
                                                               May 2003


             Movement Detection Optimization in Mobile IPv6
                 draft-daley-mobileip-movedetect-01.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is an individual submission to the IETF. Comments
   should be directed to the authors.

   Definitions of requirements keywords are in accordance with the IETF
   Best Current Practice - [RFC-2119]

Abstract

   This draft describes the state of the art techniques in movement
   detection and elaborates on their application to Mobile IPv6
   networks.  The aim of the draft is to describe the applicability of
   each mechanism and stimulate discussion on such techniques.

Table of Contents

   Status of this Memo..........................................  1
   Abstract.....................................................  1
   Table of Contents............................................  1



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 1]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   1.0 Introduction.............................................  2
   2.0 Movement Detection Overview..............................  3
   2.1 Handoff Process..........................................  3
   2.2 Movement Detection Mechanism.............................  4
   2.3 Movement Detection Performance with Neighbor Discovery...  7
   3.0 Movement Detection Schemes...............................  8
   3.1 Periodic Router Advertisement Beaconing..................  8
   3.2 RA caching in Link-layer Access Points...................  9
   3.3 Solicitation on Interval Timeout.........................  9
   3.4 Link-up Triggers on the Mobile Node...................... 10
   3.5 Fast Router Advertisement ............................... 11
   4.0 Performance Considerations............................... 12
   4.1 Effects of Solicitation Delays........................... 12
   4.2 Performance Comparisons.................................. 13
   4.3 Avoiding NUD without eager binding....................... 14
   4.4 Effects of Packet Loss................................... 14
   5.0 Combining Movement Detection Optimizations............... 15
   6.0 Predictive Handover Effects.............................. 15
   7.0 IANA Considerations...................................... 16
   8.0 Security Considerations.................................. 16
   Normative References......................................... 17
   Non-Normative References..................................... 18
   Acknowledgements............................................. 18
   Authors' Address............................................. 18
   Appendix.....................................................
   Changes Since Last Revision..................................

1.0 Introduction

   Seamless handoff systems aim at reducing the disruption caused by
   moving between IP networks.  Movement Detection is a prerequisite
   task necessary for a Mobile IPv6 (MIPv6) Mobile Node (MN) to perform
   handover signaling[MIPv6-20].  As defined in the base MIPv6
   specification, detection of movement is accomplished through
   reception of Router Advertisements (RAs), and comparison of these
   messages with previously received router information.


   Other handover operations, such as Duplicate Address Detection(DAD)
   and movement binding signaling occur subsequently to movement
   detection.  Since Movement Detection is a the first operation to
   occur in a non-predicted handover, Movement detection optimizations
   aim at reducing the time before the RA is received by the MN.  This
   reduction of movement detection time reduces handover duration.

   The MN inspects RA messages to determine if a router on that
   interface is providing routing information which supercedes or
   invalidates a current Care-of-Address (CoA).  The CoA may be



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 2]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   invalidated  because a router retracts a prefix (valid lifetime=0),
   timers expire which deprecate the existing CoA and Router entries or
   a heuristic is in place assumes movement if an RA is received with a
   new prefix, from a new router.  In MIPv6, detection of movement
   causes configuration or selection of new Care of Addresses, and
   binding signaling is commenced.

2.0 The Current Status of Movement Detection

   Movement detection is one of a series of stages in accomplishing
   MIPv6 handover.  The section below indicates the steps required for
   handovers to occur.

2.1. Handoff Process

   When an active MN moves to a new IP subnet, it changes its point of
   attachment to the network through the following handoff process.

   First Link-layer handoff occurs to change the wireless AP to which MN
   is associated.  After a new Link-layer connection is established,
   Network-layer handoff is performed, which broadly involves movement
   detection, IP address configuration and location update.  Initially,
   the MN's IP protocol implementation may be unaware of the link
   change, or may have been informed of the arrival by a link- trigger.
   Alternatively, the network itself may be aware of the MN's movement
   and may make use of this information to aid movement detection.

   The MN then checks the reachability of current AR.  If the MN
   determines the AR  is no longer reachable, the MN performs Router
   Discovery  with new AR and subsequently a Router Advertisement with
   all options arrives from a new AR.

   Once the MN discovers a new AR with necessary informations, stateless
   or stateful address configuration including DAD is
   performed[RFC-2462].  This entails waiting for address validation to
   complete, before further packets may be sent or received by the MN.

   Mobility signaling procedures are then started, with the MN sending a
   Binding Update (BU) to its Home Agent.  Additionally Return
   Routability (RR) procedures are started for route optimized
   conversations with Correspondent Nodes (CNs).  As the Return
   Routability tests are completed, further BU messages are sent to CNs.

   Since Movement Detection is prerequisite for other network-layer
   handoff operations, for seamless handoff, it is necessary to detect
   movement as fast as possible given the underlying link technology.

   Proposals for predictive handovers change these assumptions and



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 3]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   ordering.  The role played by movement detection in predictive
   handovers is defined in section 6.0.


2.2. Movement Detection Overview


   The primary movement detection mechanism for Mobile IPv6 defined in
   [MIPv6-20] uses the facilities of IPv6 Neighbor Discovery, including
   Router Discovery (RD) and Neighbor Unreachability Detection (NUD).

   In Movement Detection, an MN should check the (partial) reachability
   of the current AR and the validity of the current CoA.  This allows
   the MN to distinguish between link-layer and network-layer handovers.
   In case of IP subnet change, an MN should also discover a new AR with
   necessary information, including on-link prefix to form a new CoA.

   In brief, the Movement Detection process is as follows:

   First there is some hint that MN may have moved to another subnet.
        This hint itself doesn't confirm movement.

   Then the MN probes the current AR to check its reachability and the
        validity of the  current CoA.

   If it turns out that MN has actually moved, it searches for a new AR
        with Router Discovery.  After an RA from a new AR arrives with
        necessary information, the MN performs further operations,
        forming a CoA and sending Binding Updates.

   There are 3 entities which may change in connection with MN movement,
   Access Point (Link-layer connection), Access Router and On-link
   Prefixes (IP Subnet).

   These changes are indicated to MN with the following:
   1) Link-layer trigger (Some information from lower layer which
        notifies link change)

   2) a new IP address (in source address field of RA)


   3) a new Subnet Prefix (in Prefix Information Option in RA)

   To get the above indications, MN can perform NS/NA exchange, RS/RA
   exchange or just receive unsolicited RAs.

   The source address of the RA is a Link-Local address, its uniqueness
   is not guaranteed outside a link.  Hence the fact that MN receives



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 4]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   the RA with the same address doesn't guarantee that it comes from
   current AR.

   ARs may omit a Prefix Information Option for efficiency.  Hence the
   lack of the prefix of the current CoA in RA doesn't mean that current
   CoA  is not valid.

   The above defects may results in the problem like this.  Assume MN
   moves from AR1  to AR2.  If AR1 and AR2  have the same link-local
   address, the MN may not detect its movement even after several RAs.

   The entities may change together or separately.  Therfore any
   indications can't represent subnet movement precisely by itself.


           -------           -------
           | AR1 |           | AR2 |
           -------           -------
        C::3  |                 |D::4
              |                 |
              |AP1               |
            /-------------\     |
           /               \    |AP2
          /         /-------\-------\
          \        /         \       \
           \      /          /        \
   Cell 1   \     \         /  ------ \
   Coverage  \-----\-------/   | MN |  /
                    \          ------ /  Cell 2
                     \---------------/ Coverage

   Figure 1.  MN moving between two networks

   For example, in Figure 1, MN moves from AP1 to AP2  and all three
   entities change.
















Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 5]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


              -------     -------
              | AR1 |     | AR2 |
              -------     -------
            A::1 |           | A::2
              |-----------------|
              |                 |
            /-------------\     |
           /               \    |
          /         /-------\-------\
          \        /         \       \
           \      /          /        \
   Cell 1   \     \         / ------   \
   Coverage  \-----\-------/  | MN |    /
                    \          ------ /  Cell 2
                     \---------------/ Coverage

   Figure 2.  MN sees two access routers on the same subnet

   In Figure 2, AR1 and AR2 are routers on the link. Each advertise a
   prefix A:: to hosts.  When the MN moves from AP1 to AP2, it changes
   AP and AR but remains in same IP subnet.

           -------           -------
           | AR1 |           | AR2 |
           -------           -------
        C::3  |                 | D::4
              |-----------------|
                         |
                  /-------------\
                 /               \
                /                 \
                \          ------  \
                 \         | MN |  /
   Cell 1         \        ------ /
   Coverage        \-------------/


   Figure 3. Two Access routers on the same subnet

   In Figure 3, AR1 and AR2 are routers on the link which share a common
   AP.  Each advertise a prefix C:: or D:: to hosts.  Assume AR1 is MN's
   current default router.  Then the arrival of a RA from AR2  doesn't
   mean MN has moved.








Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 6]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


                    -------
                    | AR1 |
                    -------
                 C::3  |
              |-----------------|
              |                 |
            /-------------\     |
           /               \    |
          /         /-------\-------\
          \        / ------  \       \
           \      /  | MN |  /        \
   Cell 1   \     \  ------ /          \
   Coverage  \-----\-------/           /
                    \                 /  Cell 2
                     \---------------/ Coverage

   Figure 4. MN moves between wireless links in the same subnet

   In Figure 4, If MN moves AP1 to AP2, it still remains at same IP
   subnet even though it receives link-layer change notification from
   lower layer.

   An MN's Movement Detection scheme should combine available
   information to detect movement correctly.  It should not mistake some
   hint as movement while the MN hasn't moved.  That may result in
   continual handoff, and hence excessive mobility signaling.  If the MN
   moves, it needs to detect movement sufficiently fast so that it can
   complete handover signaling without significantly degrading
   application performance.

   On the other hand, if the MN doesn't move though it receives some
   hints (like Figure 3,4), it is not imperative to detect its non-
   movement so fast.  It will not degrade performance even if MN can't
   quickly confirm that it still remains at the same subnet.

   A movement detection scheme should not result in excessive signaling
   traffic.  It should not flood the network with unnecessary RS/RA or
   NS/NA messages.


2.3. Movement Detection Mechanism


   Movement Detection Mechanism consists of following steps.
   Step 1. Hint
   Step 2. Checking the reachability of the current AR
   Step 3. Checking the validity of the current CoA
   Step 4. Discovering new AR  with necessary information.



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 7]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


2.3.1 Receiving Movement Hints


   There is a set of hints which can indicate that Network-layer
   movement has occurred.  The hints can be Link-layer trigger, the
   receipt of a new RA or the lack of RA from current AR.  This hint
   itself doesn't confirm L3 movement.


2.3.2 Checking the reachability of the current AR


   An MN checks whether current AR is still reachable by probing.  The
   MN may probe with NS or RS.

   In case of NS probing similar to NUD, an MN sends unicast NS messages
   to the current AR.  If the current AR replies with a NA, the MN can
   be sure that it is still reachable.  If an NA doesn't arrive after 1
   sec, the MN resends the NS.  After 3 probe attempts, the MN decides
   that the AR is no longer reachable.

   If an MN actually has moved to new IP subnet, it will take 3 seconds
   to detect that the current AR is not reachable (sending 3 NS probes,
   plus waiting 1 second for each).  With NUD, we can detect a node's
   presence very quickly.  Conversely, it takes substantial time (3 Sec)
   to detect that node is NOT there.

   In order to reduce the time taken to detect a router's non-presence,
   the MN may use a timeout.  Instead of retransmitting, the MN just
   sends one NS, and waits for a reply for fixed time.  If the MN times
   out before receiving a reply, it assumes that it has moved.

   Attempts at avoiding the cost of NUD without resorting to eager
   bindings or NS/NA heuristics are discussed in section 4.3.


2.3.3. Checking the validity of the current CoA


   When the NS/NA exchange is for the AR's link-local address, the MN
   can't be sure that it still remains at the same IP subnet since link-
   local scoped addresses uniqueness is only guaranteed on the link.
   The MN may have moved to a new AR  which happens to have the same
   link-local address as the current AR.

   Hence MN also has to confirm the validity of the current CoA by
   checking on-link prefixes.  The MN sends a unicast RA to current AR.
   When a solicited RA with all options arrives, the MN checks whether



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 8]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   it contains the prefix of current CoA in any of its Prefix
   Information Options.

   As an alternative solution, the MN may send the NS to a globally
   unique router address, if it is carried in a MIPv6 modified Prefix
   Information Option advertised by the current router.  An NA response
   from this router address can uniquely provide reachability
   confirmation for the router, since only the current router may have
   this address.



2.3.4. Discovering a new AR


   If it turns out that MN has actually moved, it has to find a new AR
   using Router Discovery[RFC-2461]. The MN sends a Router Solicitation
   to the All-routers multicast address.  When a solicited RA with all
   options arrives, the MN selects a new AR, forms a new CoA and perform
   further operations.

   We can perform Movement Detection Steps 2,3,4, with only one RS/RA
   exchange as illustrated below.

   To check the reachability of current AR, instead of using NS, the MN
   sends an RS to the All-Routers multicast address.

   If current AR  is still reachable, MN will receive an RA with all
   options within roughly 1.5 Sec (1 Sec random RS delay and 0.5 sec
   random RA delay).  Since RA messages do not explicitly indicate if
   they are solicited, we can't say that the current AR is reachable if
   we receive an RA.  We can say though, if we don't receive a RA in
   time, it's highly probable that the current AR is not reachable.

   If a solicited RA with all options arrives from current AR, the MN
   can confirm that current AR can still reach MN and current CoA is
   still valid.

   If no RA arrives from the current AR, but the MN receives several RAs
   from new ARs, the MN chooses a new default AR.

   Though the MN can't confirm reachability of the new AR, if its RA
   contains a Source Link-Layer Address option, the MN will gain a stale
   Neighbor Cache entry for the router.  This means the MN can start
   sending packets.  Moreover the solicited RA from the new AR contains
   all the necessary information for IP configuration.  Hence the MN can
   perform further operations immediately without additional signaling
   messages or delay.  After the handoff process is completed, the MN



Daley, Choi      draft-daley-mobileip-movedetect-00.txt         [Page 9]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   can perform NUD with the new AR to confirm the reachability at its
   leisure.

   Below is a comparison of the comparitive merits of RS/RA and NS/NA
   probing

   The benefits and drawbacks of NS/NA probing are:

   1) Since there is no Random Delay, MN and AR can send NS and NA
        immediately.

   2) The solicited flag confirms bi-directional reachability.

   3) The MN needs to perform at least one RS/RA exchange afterwards.
        (Unless a globally unique router address is probed).


   The benefits and drawbacks of RS/RA probing are:

   1) With only one RS/RA exchange, MN can check the (partial)
        reachability of a current AR, validity of current CoA and
        receive all the necessary information from a new AR.

   2) There are two random delays of up to 1 Sec for RS and 0.5 Sec for
        RA.  Hence it take more time to RS/RA exchange with RA timouts
        being set appropriately. This may be solved with FastRA (Section
        3.5).

   3) It may cause excessive multicast RA traffic.

   4) MN can't confirm reachability of AR.

        We may shorten the time taken to detect movement by performing
        multiple operations in parallel.  For example, by sending NS to
        current AR and RS to all-routers multicast address at the same
        time, we can perform Step 2, 3, 4 simultaneously.  If there are
        many wrong movement hints, this may cause excessive multicast
        traffic.

        There is still much to investigate about the necessary steps of
        Movement Detection, their order of performance order, efficient
        (NS and RS) probing mechanisms and the trade-off between
        Movement Detection time and signaling traffic.








Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 10]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


2.4. Movement Detection Performance with Neighbor Discovery


   Movement detection algorithms are based on Neighbor and Router
   Discovery mechanisms[RFC-2461].  Neighbor Discovery allows
   solicitation of NA in order to confirm reachability.  Router
   Discovery allows the periodic multicast of RAs to nodes on a (fixed)
   IPv6 network.  [RFC-2461] additionally allows solicitation of RAs in
   order to confirm network identity, or speed device configuration.

   Neighbor Discovery protocol constants were sized for networks of many
   nodes, where it was sufficient to provide configuration within a few
   seconds.  This has caused significant delays to be built into
   Neighbor and Router Discovery[RFC-2461].  Networks supporting MIPv6
   MNs need to be able to check (partial) reachability and receive RAs
   in shorter time intervals than are available for standard Neighbor
   Discovery.  This is important if Mobile Nodes have existing higher-
   layer sessions when Movement Detection is performed, which may be
   affected by slow handover times.

   Movement detection performance is measured from the time when the new
   Link-layer connection is established until Movement Detection is
   completed through suitable RA reception from new AR.

   At first MN receives a hint that it may have moved.  The time taken
   to receive for this hint varies.  With Link-layer trigger support, it
   can be done instantly.

   Alternatively an MN can monitor periodic RA beacons.  The base MIPv6
   document uses RA Interval Timer expiry as a hint.  An MN may
   implement its own policy to determining the number of missing RAs
   which it will interprets as hint for possible movement.

   With payload traffic tracking, we may get a hint earlier.  An MN may
   implement its own policy to determining the interval of idle time
   with no traffic which it will interprets as a hint for possible
   movement.  Care should be taken in this case to ensure that spurious
   hints do not cause unnecessary probing of the network.

   Without schemes such as those above to provide hints, the MN must
   wait to receive an RA from a new AR before undertaking Movement
   Detection.  Hence the detection delay depends on the frequency of
   Router Advertisements.

   Periodic RA beaconing transmits packets within an interval varying
   randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.  In
   [RFC-2461] minimums for these values are 3 and 4 seconds,
   respectively.  Since MN movement is unrelated to the advertisement



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 11]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   time on the new network, the MN is expected to arrive on average half
   way through the interval.  This is about 1.75 seconds with [RFC-2461]
   advertisement rates.  Worst case performance (without packet loss) is
   when the MN arrives just after an RA, and the next RA is scheduled
   close to MaxRtrAdvInterval.  If [MIPv6-20] advertisement intervals
   are in use, these values drop to 0.025 and 0.70 seconds respectively.

   Next the MN probes the current AR to check its reachability and CoA
   validity.  There is no single agreed way mandated for this.

   For example, assume the MN uses NS probing.  If the MN probes with NS
   using NUD-like retries, the AR's unreachability will be detected
   after 3 sec for the case when the MN actually has moved.  If the MN
   uses one NS and a timeout, the duration depends on the timeout value.
   We may set timeout value as 2 * RTT  time from MN to AR.  There is no
   consensus on timeout values yet and the RTT time in wireless
   environment may be highly volatile.

   Afterwards, an MN should perform one RS/RA exchange, whether the
   current AR is reachable or not.  This is subject to routers delaying
   0-500 ms before responding to the RS, and the advice that the MN
   delays 0-1000 ms before sending an RS [RFC-2461].  Additionally, if
   there is no verified link-address available for Router Solicitation,
   the router must respond with a multicast RA.

   Movement detection optimizations seek to lower the time taken to
   perform Neighbor and Router Discovery, either through MN
   solicitation, or timely unsolicited advertisement of router
   information.  To achieve this aim, modifications to NUD and Router
   Discovery are made on mobile-supporting networks and MNs.


3.0 Movement Detection Schemes


3.1 Periodic Router Advertisement Beaconing

   Beaconing is a term used to refer to multicasting of network
   identification information at regular intervals.  Mobile IPv6 reduces
   the lower bound of the MinRtrAdvInterval and MaxRtrAdvIntervals to 30
   and 70 ms respectively[MIPv6-20].  With these settings, beacons will
   be sent no more closely than 30 ms apart, and with no greater
   separation than 70ms.  Routers are required to send the beacons at
   random times within this interval.  This means that an MN will
   receive an RA within 70ms of arriving on the link, and may expect to
   receive an RA within 25ms, if we assume MN entry into the network to
   be randomly distributed in the interval.




Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 12]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   This technique requires no action on the part of the MN other than
   listening to RA multicasts.  The bandwidth consumption by multicast
   beacons is 14 kbps when RAs only include one Prefix Information
   option.  Addition of a Source-Link-layer-Address option and a MIPv6
   Advertisement Interval option typically increase this to 16.6 kbps.

   On some networks, such overhead (~20 multicast packets per second)
   causes a serious burden on network bandwidth.  In these cases,
   [RFC-2461] specified intervals SHOULD be used, if other movement
   detection mechanisms are available.

   Additionally, the reduced interval between messages may have side
   effects for non-MIPv6 nodes on the same networks.  The
   AdvDefaultLifetime value is used to set the lifetime of the default
   router in seconds, as advertised in the Router Lifetime field of the
   RA.  The minimum value specified in [RFC-2461] for this value is
   MaxRtrAdvInterval.  This value is less than one second when using
   MIPv6 specified advertisement intervals.  Even if default router
   lifetimes are rounded up to the nearest second, nodes which assume
   MaxRtrAdvInterval is at [RFC-2461] values could be confused about the
   lifetime of their default router.  Routers SHOULD ensure that
   AdvDefaultLifetime is greater than or equal to 4 seconds, in order to
   avoid this confusion.

3.2 RA caching in Link-layer Access Points (Fast Router Discovery
[FRD-00])

   One method which requires no solicitation from the MN is network
   triggering of RA.  Router advertisements are sent to the MN when it
   attaches to an access point (AP) associated with this network.

   In network deployments, the router may not be the link-layer device
   which the MN connects to, and therefore may be unaware of MN link-
   connection.  Only in the case where the the AP advises the router of
   connection or AAA state, can the router send (unscheduled)
   unsolicited RAs before receiving packets from the MN.

   The Fast Router Discovery (FRD) draft[FRD-00] places the
   responsibility of sending triggered RA messages upon APs.  The Access
   Points cache RA's recently sent from the router, and deliver a frame
   to the MN when it connects.  This frame is datalink-unicast to the MN
   and contains the most recent unsolicited RA.

   In this case, less frequent transmission of unsolicited multicast RA
   messages may be used.  At the same time, the first frame which is
   queued for the MN is the RA required for movement detection.

   Deployment of FRD requires each of the APs for the network to be



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 13]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   capable of both the caching and triggered sending operations.
   Analysis and experimental results indicate that this is potentially
   the fastest network-layer based movement detection optimization,
   dependent on AP processing capacity.

3.3 Solicitation on Interval Timeout

   As specified in MIPv6, the Advertisement Interval Option describes
   the maximum time between unsolicited RA messages (MaxRtrAdvInterval).
   This option is used in movement detection as a packet loss management
   system, where after elapse of one or more Advertisement Intervals
   without RA reception, the MN can send a router solicitation.

   In the case where MNs send RSs after the loss of multicast RA
   messages, all MN's which have not received the RAs will time out at
   the same instant.  [RFC-2461] specifies an additional delay of 0-1000
   ms  required for the purposes of desynchronizing RS messages sent
   from many hosts.  An MN which does not have other confirmation that
   it has moved SHOULD follow this policy.  Further details of this
   issue, especially with regard to simultaneous movement, are presented
   in section 4.1.

   In the case where the MN moves by itself, this algorithm provides
   best performance when the MN connects to a new network just before an
   interval passes.  If the MN is acting upon one packet's loss then
   this provides an RS immediately.  If the timer elapses when there is
   no connection to a link, it is implementation dependent whether the
   RS packet is lost.  Typically though, the MN will leave the previous
   access network on average half way through the mean RA interval.  The
   expected time left until the Advertisement Interval elapses upon the
   MN leaving the network is:

      ExpIval = 0.75*MaxRtrAdvInterval - 0.25*MinRtrAdvInterval

   This does not account for the link-layer handover time, which may be
   tens or hundreds of milliseconds.  When these values are the minimums
   described by [RFC-2461], this value is 2.25 seconds and therefore
   does not seem to provide significant benefit unless faster (MIPv6)
   beacons are being sent.  At the MN specified beacon rate, the
   expected residual interval is 45 ms.

   Any of the methods which require responses to Router Solicitations as
   specified by [RFC-2461] also incur an additional delay of between 0
   and 500 ms before a response is sent by the router.  Section 3.5
   describes a mechanism to cope with this issue.






Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 14]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


3.4 Link-up Triggers on the Mobile Node

   For situations where RA packets have been transmitted correctly, the
   Advertisement Interval's best case occurs when the timeout occurs
   just after the MN joins a new link.  In environments where the MN can
   receive an indication a link has been joined, this information can be
   used to trigger an RS immediately[MIPv6-20], although once again a
   random delay before sending RS's is advised by [RFC-2461].

   Additionally, even if the MN doesn't send an RS upon receiving a
   link-up trigger, it can use the trigger to validate received RA
   messages for movement detection with eager-binding.  The MN may be
   able to enter an 'eager-binding' state until it receives its first RA
   on the new link.  If it receives an RA from a previously unseen
   router at this time, it may be useful to confirm bidirectional
   reachability with this outer, and then undertake movement signaling.

   Upon entering a new subnet, there is a small chance that the MN will
   have a duplicate address collision with another device's Link-Local
   address[RFC-2462].  When an MN solicits an RA, it typically sends
   from the Link-Local address, unless this address is
   tentative[RFC-2461].  If the MN sends from the Link-Local address,
   unicast responses are allowed, and in this case, rate limiting of
   multicast RA messages is avoided.

   If the MN joins a link, then until it knows the identity of the link
   (has received an RA), it MUST assume that it is on a new link, where
   its Link-Local address is tentative.  This means that RS messages
   will either be deferred until DAD operations have been performed on
   the Link-Local address or the RS MUST be sent with an unspecified
   address.  A multicast response will be scheduled no sooner than:

      Max(LastMcastRATime + MinDelayBetweenRAs,
                                     now + 0-500 ms RS Response Delay)

   Where MinDelayBetweenRAs could be as high as 3 seconds.  Even if the
   response is not multicast, the RS response delay is still incurred.

3.5 Fast Router Advertisement [FASTRA-02]

   Fast Router Advertisement (FastRA) removes the random delay required
   of a router before it responds to RS messages.  It relies upon only
   one router on a subnet being configured for FastRA, so that responses
   are not simultaneous.  FastRA principally aims at delivery of unicast
   RA messages, since the rate limiting of multicast RA messages
   specified in [RFC-2461] specifies that RA messages may not be sent
   within 3 seconds of each other.




Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 15]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   Similar action could be performed with multicast RA responses if
   FastRA adopted the MinDelayBetweenRAs as in [MIPv6-20].  In this
   case, the response would only be delayed if the last multicast RA
   occurred more recently than MinDelayBetweenRAs ago (or MaxFastRAs has
   been consumed).  This could work well if the arrival of mobile nodes
   occurred much less frequently than the unsolicited multicast RA
   interval.

   FastRA incorporates a rate limiting feature aimed at diminishing the
   potential effect of FastRA traffic on nodes which are already
   connected to the network.  Routers may transmit no more than
   MaxFastRAs advertisements in an interval before discarding
   solicitations until the next unsolicited multicast RA.

   Either of the solicitation mechanisms may be used to get FastRA
   response from a router, although Advertisement Interval timeout will
   only be invoked on packet loss if Link-triggers are available.

   Movement detections times are bounded only by the time to send the
   Multicast RS message and send the unicast RA response.  Recent
   testing has indicated 95% of RAs were received within 15 ms of
   sending an RS on 802.11b networks, when Neighbor Discovery was being
   performed on the MN's Link-Local address.  If RS messages include
   Source link-layer Address options[RFC-2461] or are multicast
   responses with no timer delays, movement detection time will be
   lower.

4.0 Performance Considerations


4.1 Effects of Solicitation Delays

   [RFC-2461] specifies that a node SHOULD delay a random interval of
   between 0 and 1000 (MAX_RTR_SOLICITATION_DELAY) ms before sending an
   RS if it is the first packet the node sends on the link [RFC-2461].
   A similar delay is stipulated for DAD packets in [RFC-2462], for the
   same circumstances.

   These delays are provided for the case where many devices are
   configuring on the link at the same time.  In a mobility environment,
   this may occur if many MNs are traveling together, for example on a
   train, or at peak hours on a freeway.  For this environment, there is
   some possibility that the MNs' simultaneous transmission of multicast
   RS or DAD packets will will cause interference or backoff and
   retransmission.

   The effect of such simultaneous movement and subsequent multicast
   transmission is the topic of current research.  On several wireless



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 16]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   technologies, the effect is thought to be minimal, especially where
   discrete codes or data channels are provided to each subscriber.

   There are certainly other environments where many devices
   simultaneously transmitting have a detrimental effect though, and in
   these cases, the configuration by MNs SHOULD be serialized.  The
   serialization provided by a random timer is one mechanism by which
   simultaneous transmission may be avoided.  Other methods, are reliant
   upon serializing effects in the link-layer, such as AAA operations.
   These effects are link-dependent and  where they provide protection,
   MNs SHOULD take advantage of them to avoid random timer delays.

   It should be noted that multicast bombing may occur even in when no
   RS is performed, if many nodes simultaneously receive an RA beacon
   from a new router.  These MNs' first operation is to undertake DAD
   procedures.  Link procedures are unlikely to provide serialization in
   this case, since all MNs will receive the multicast at approximately
   the same time.

   In any case, the MN SHOULD undertake the RFC-2461 and RFC-2462
   prescribed delays if any of the following is true:

   * The MN has no upper-layer sessions

   * The MN has no sessions which have sent or received data within
        UPPER_LAYER_ACTIVITY seconds.  The value of UPPER_LAYER_ACTIVITY
        is implementation specific, but defaults to 120 seconds.

   * The MN has more highly preferred interfaces which have the
        currently bound CoAs  configured for all current sessions.
        Also, these CoAs are known to be successfully receiving and
        sending data.

   This limits the effect of link contention to active devices requiring
   an expedited handover service.


4.2 Performance Comparisons

   A table is provided which indicates the relative performance of
   several movement detection schemes.

   These handovers do not include delays due to DAD for unicast
   responses, nor do they include RS/DAD delays to avoid multicast link
   bombing.  Additionally, the cost of determining reachability with the
   current AR is ignored.

   Presented times are on a wireless link of ~2 Mbps, which is capable



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 17]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   of multicast at 1 Mbps.
   |--------------------------------------------------------------|
   |         | Uni/Multicast| overhead | Move Detection Time (ms) |
   |         | Advertisement| (kbps)   | Avg   | Max              |
   |--------------------------------------------------------------|
   |Beacon   |   Multicast  |    >14   | 25    | 70               |
   |         |              |          |       |                  |
   |--------------------------------------------------------------|
   |FRD      | Multicast L3 |    <1    | <10   | <20              |
   |         | (unicast L2?)|          |       |                  |
   |--------------------------------------------------------------|
   |Timer(a) |   Unicast    |    <1    |ExpIval|MaxRtrAdvInterval |
   |         |              |          | +250  | +500             |
   |--------------------------------------------------------------|
   |LinkRS   |   Multicast  |    <1    |  250  |  530             |
   |tentative|              |          |       |                  |
   |--------------------------------------------------------------|
   |LinkRS   |   Unicast    |    <1    |  250  |  500             |
   |unicast  |              |          |       |                  |
   |--------------------------------------------------------------|
   |FastRA   |   Multicast  |    <1    |  <10  |  60              |
   |tentative|              |          |       |                  |
   |--------------------------------------------------------------|
   |FastRA   |   Unicast    |    <1    |  <10  | <30              |
   |unicast  |              |          |       |                  |
   |--------------------------------------------------------------|
   Notes:

   (a) These duration values include link-layer handover time,
       where no other row does.

4.3 Avoiding NUD without eager binding


   The cost of performing NUD to the current AR in order to check
   whether movement has occurred is expensive in the case that it has.
   Proposals to avoid using NUD with the current access router have been
   made in the mobile-ip working group.

   One set of proposals which rely upon information in received router
   advertisements to guarantee that a previously configured router is
   uncontactable.

   It is also possible to make use of link-layer information which
   indicates a network domain change.  Link-layer triggers pass
   information to the network-layer which either explicitly provide
   movement detection[WLANPIO-00], or disambiguate subsequently received
   RA information.



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 18]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   Further reference will be made to drafts elaborating on these ideas
   as they become available.

4.4 Effects of Packet Loss


   Packet loss from (network and MN) triggered systems can be a
   significant factor MIPv6 handovers performance.  When a quickly
   delivered RA message is lost, then the MN may wait until the next
   unsolicited multicast RA message, which can take up to four seconds
   (RFC-2461 MaxRtrAdvInterval).

   In MN triggered systems, if RS messages are lost and have to be
   resent, movement detection times are increased by up to four seconds.
   This timeout is governed by the value of the Neighbor Discovery
   constant RTR_SOLICITATION_INTERVAL.

   In solicited RA environments, the exchange of RS/RA messages is
   susceptible to loss of either packet, as is the case with NS/NA if
   the router needs to perform Neighbor Discovery on the MN before
   sending a unicast RA response.

   Beacon systems which transmit RAs at high rate are less susceptible
   to the adverse affects of packet loss, since replacement packets are
   transmitted quickly after the packet loss event.

   Backup effects from Advertisement Interval timers may play a part in
   the solicitation of replacement RA messages, although unless link-
   layer handover times are considered, these provide worse performance
   than beacon based systems.

5.0 Combining Movement Detection Optimizations


   When arriving on a network, an MN is unaware which movement detection
   optimizations are in place on the network, or whether any are in use.
   The MN may therefore choose to send an RS before it receives an
   unsolicited RA, even though either FRD or RA beaconing are in place.
   In all likelihood, both RA delivery mechanisms will be activated.

   In this case, the movement detection time will typically not be
   affected, except that more packets will be sent to the wireless
   medium.  Therefore, if an MN has received a link-trigger, and the MN
   subsequently receives an RA before it has scheduled an RS packet to
   be sent, the MN SHOULD NOT send the RS.

   In most cases without packet loss, the presence of fast beacons will
   not significantly affect the performance of FastRA or FRD systems.



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 19]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   As mentioned in section 4.4 though, the harm caused by packet loss is
   significantly lowered if beacons are received within a short period.
   If the overhead of running beaconing systems is sufficiently low for
   the wireless link type, then beacons MAY be used with either of FRD
   and FastRA.

   Networks with either of FRD or FastRA capability are unlikely to also
   use the other technology on their systems, since FRD and FastRA are
   closely matched in performance and have low latency times.  If the
   network has both capabilities, there is some chance that RA messages
   from AP and Router attempt to be delivered simultaneously to the MN.
   Since there is no way for the MN to know that FRD is in use when
   soliciting, it MAY send an RS in any case, if it has not received an
   RA already from this link.

6.0 Predictive Handover Effects


   Movement detection optimizations' applicability is principally in
   non-predictive movement environments, although there may be some
   benefit for anticipated/fast handover systems as movement
   confirmation and correction mechanisms.

   Handover prediction allows MNs to select the network to which they
   move, and perform handover signaling in anticipation of this event.
   This allows the tunneling and buffering of MN traffic within network
   routers while the link-layer handover is occurring.

   With some link environments, it may not be possible to guarantee that
   the MN will arrive on the selected link, nor that the MN has indeed
   arrived on that link.   In these cases, it is still necessary to
   confirm that the MN is arrived on the link through movement detection
   algorithms.  This allows the MN to send corrective binding signaling
   in the case that the network is a different one than was the
   anticipated destination.

7.0 IANA Considerations


   No new message formats or services are defined in this document.

8.0 Security Considerations

   Movement detection optimizations are reliant upon reception of a
   Router Advertisement with properly configured Prefix Information
   Options [RFC-2461].

   Since Movement Detection is based on Neighbor Discovery, its trust



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 20]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   models and threats are similar to the ones presented in [SEND-
   psreq-01]. The attacks described in 4.0 of [SEND-psreq-01] can be
   applied to Movement Detection too. Movement Detection schemes SHOULD
   incorporate the solutions developed in IETF SEND Working Group if
   available, where threat assessment indicates such procedures are
   required.

   Moreover the threats described in 4.2 of [SEND-psreq-01] may cause
   more serious problems.  When there is an indication that the current
   IP connection has changed (Link down, New Router Advertisement et
   cetera), non-mobile nodes will first perform NUD[RFC-2461].  The
   MIPv6 handoff process (including Movement Detection) is time
   sensitive.  So mobile nodes may start an eager handoff without
   Neighbor Unreachability Detection.

   If higher layer notification of connectivity is not available, and
   eager handoff strategies are in place, any node or router which
   advertises an RA with a false prefix will cause MNs to perform
   spurious handover signaling and DAD operations.

   For non-mobile case, if a node receives a bogus RA which doesn't
   include the prefix of its current address, it doesn't assume that its
   current prefix becomes off-link.  In Neighbor Discovery, the only way
   to cancel a previous on-link indication is to advertise that prefix
   with the L-bit set and the Lifetime set to zero [RFC-2461]. Hence the
   node keeps using the current address and not so much harm is done.

   In the mobile case, the threat is more serious.  Assume an attacker
   sends an RA which includes only false Prefix Information Options.  If
   a MN receives a bogus RA which doesn't include the prefix of the
   current CoA, it will assume that movement has occurred.  The MN will
   start DAD (with the bogus prefix) and send BUs (with a false CoA).
   Hence MN will be disconnected, or its packets will be intercepted and
   subject to man-in-the-middle attack[SEND-psreq-01].

   Moreover if we configure MNs to send RS and DAD without delay, this
   bogus RA attack may cause multicast bombing too.  An attacker can
   send a bogus RA without source link-layer Address option.  Then all
   MNs will receive the bogus RA at the same time and start Neighbor
   Discovery simultaneously.  They will send RS without delay at the
   same time and cause RS congestion.  An attacker can deceive all MNs
   to believe they have moved simultaneously by sending a suitable bogus
   RA.  In this case, DAD would be performed by all nodes on the link
   immediately on multicast RA reception.

   The security issues described above are not specific to any Movement
   Detection scheme presented in this draft but are inherent in any
   mechanism which uses only Router Discovery for movement detection.



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 21]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   Information from lower layers will be useful to mitigate the above
   threats. Assume there is an MN for which link-layer trigger is
   provided to notify link-layer change.  If the link-layer trigger
   precedes a new RA, it is likely that the RA is valid and the MN has
   actually moved.

   When the MN moves to a new IP subnet, link-layer change usually
   precede movement.  So first link-layer change is notified to the MN
   and it anticipates movement.  Hence when a new RA arrives, the MN can
   reasonably believe it.

   On the other hand, if the MN receives a new RA without the
   notification of link layer change, it is likely that the RA is bogus.
   In this case, the MN SHOULD be suspicious:

   Before initiating the handoff process, it SHOULD perform Neighbor
   Unreachability Detection to request a RA from its default router.
   Also, without link-layer information, RFC-2461 and 2462 delays before
   sending RS and DAD messages SHOULD be performed, until NUD has
   completed.

   This document references several other documents, each of which
   defines its own security considerations.  Readers are referred to
   these documents for further information.

Normative References

   [RFC-2119] S. Bradner.  Key words for use in RFCs to Indicate
        Requirement Levels. Request for Comments (Best Current Practice)
        2119 (BCP 14), Internet Engineering Task Force, March 1997

   [RFC-2461]  T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for
        IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
        Internet Engineering Task Force, December 1998.

   [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address
        Autoconfiguration.  Request for Comments (Draft Standard) 2462,
        Internet Engineering Task Force, December 1998.

   [FASTRA-02] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router
        Advertisement (FastRA), Internet Draft (work in progress),
        October 2002.

   [FRD-00] JinHyoeck Choi, DongYun Shin. Fast Router Discovery with RA
        Caching in AP. Internet Draft (work in progress), Feb 2003.

   [MIPv6-20] D. Johnson, C. Perkins, J. Arkko.  Mobility Support in
        IPv6.  Internet Draft (work in progress), January 2003.



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 22]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


   [SEND-psreq-01] P. Nikander (Ed.), J. Kempf, E. Nordmark.  IPv6
        Neighbor Discovery trust models and threats. Internet Draft
        (work in progress), January 2003.


Non-Normative References

   [CGA-00] Tuomas Aura. Cryptographically Generated Addresses (CGA).
        Internet Draft (work in progress), February 2003.

   [WLANPIO-00] Paul Tan. Recommendations for Achieving Seamless IPv6
        Handover in IEEE 802.11 Networks. Internet Draft (work in
        progress), February 2003.

Acknowledgements

   Thanks to the authors and editors of the MIPv6 (David Johnson,
   Charles Perkins Jari Arkko),  FastRA (Mohammed Khalil, James Kempf
   and Brett Pentland), and FastRD (JinHyeock Choi {thx from Greg} and
   DongYun Shin) drafts.  We have relied heavily upon their work and aim
   only to illuminate their good ideas.  Additionally, we thank Ed
   Remmell and Erik Nordmark for their contributions in the working
   group.  We're sure they'll recognise some of their ideas presented
   here.


Authors' Addresses:

   Greg Daley
   E-mail: greg.daley@eng.monash.edu.au
   Phone: +61-3-9905-4655

   Address:
   Centre for Telecommunications and Information Engineering
   Department of Electrical and Computer Systems Engineering
   Monash University
   Clayton 3800 Victoria
   Australia


   JinHyoeck Choi
   E-mail: athene@sait.samsung.co.kr
   Phone: +82-31-280-9233
   Address:
   i-Networking Lab, Samsung AIT (SAIT)


Appendix:



Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 23]


INTERNET-DRAFT   MIPv6 Movement Detection Optimizations         May 2003


     ..

Changes Since Last Revision:

   Since 00:

   More diagrams indicating MD issues.

   Stronger elaboration of MD mechanisms(NUD/NS/NA/RD)

   Added stronger guidance for avoiding multicast bombing.

   Added section on avoiding NUD safely (w/placeholder for potential
   references to LinkIDs draft &etc).

   Added eager-binding heuristic after link-up trigger (EN).

This document expires in December 2003.

































Daley, Choi      draft-daley-mobileip-movedetect-00.txt        [Page 24]