Mobileip Working Group                          Karim El-Malki, Ericsson
INTERNET-DRAFT                                  Hesham Soliman, Ericsson
Expires: March 2001                                       September,2000






                         Fast Handoffs in MIPv6
                   <draft-elmalki-handoffsv6-00.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.


Abstract

   This draft describes a method to achieve Fast Handoffs in Mobile
   IPv6. Fast Handoffs are required in Mobile IPv6 in order to limit
   the period of service disruption experienced by a wireless Mobile
   Node when moving between access routers. This requirement becomes
   even more important when supporting real-time services. Fast
   Handoffs involve anticipating the movement of MNs by sending
   multiple copies of the traffic to potential Mobile Node movement
   locations. Both flat and Hierarchical Mobile IPv6 models are



El-Malki, Soliman                                               [Page 1]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


   considered. The Hierarchical MIPv6 mobility Management model in [1]
   already offers improvements to Mobile IP handoffs by providing a
   local Mobility Anchor Point (MAP) functionality. Some additions
   are made to the operation of this existing Hierarchical model to
   achieve Fast Handoffs.




TABLE OF CONTENTS

      1.   Introduction...............................................2

      2.   Fast Handoffs..............................................4
      2.1  Initiating Fast Handoffs through the "previous" AR.........5

      3.   Fast Handoffs in Hierarchical MIPv6........................8

      4.  Acknowledgements...........................................14

      5.  References.................................................14

      6.  Addresses..................................................14


1. Introduction

   Fast Handoffs anticipate the movement of wireless Mobile Nodes
   (MNs) by utilizing simultaneous bindings in order to send multiple
   copies of the traffic to potential Mobile Node movement locations.
   In this way, Fast Handoffs coupled to layer 2 mobility can help in
   achieving seamless handoffs between Access Routers (ARs) by
   eliminating the delay period required to perform a Registration
   following a Mobile IP handoff.
   An alternative method to perform improved handoffs, namely Smooth
   Handoffs, is described in [2]. The method for Fast Handoff
   addresses the need to support services having strict delay bounds
   (i.e. real-time) which in certain cases may be hard to support if
   traffic has to be forwarded between ARs using Smooth Handoffs.
   Also, in the non-realtime case it may be possible that the new AR
   receives buffered traffic from the previous AR (smooth handoff)and
   traffic from the CN which could cause some out-of-order and delayed
   packets to be delivered to the MN. In some cases this may affect
   the performance of higher level protocols (i.e. TCP). This same
   situation will not arise using Fast Handoffs.

   This draft considers both the normal Mobile IPv6 model [2] and the
   hierarchical Mobile IPv6 model [1]. These are shown in Figure 1
   where the Access Points (APs) or Radio Access Networks (RANs) are
   used to provide a MN with wireless L2 access.




El-Malki, Soliman                                               [Page 2]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


   Simultaneous bindings are described in this draft and may be
   achieved by setting a new, "B" flag in the BU sent by the MN to a
   MAP. In this way, the MAP will add a new binding for the MN
   without removing the existing entry.
   Hence packets arriving to the MAP will be tunnelled to both addresses
   in its BC.


         _________          __________
         |         |        |         |
         |   HA    |--------|  (MAP)  |________
         |_________|        |_________|        \
                              /  |  \           \
                                                 \
                           ...  ...  ...          \
                                                   \
                       ______/_     _\______        |
                      |        |   |        |       |
                      | AR2/MAP|   | AR1/MAP|       |
                      |________|   |________|       |
                       ____|___     ____|___    ____|___
                      |        |   |        |  |        |
                      |AP/RAN 2|   |AP/RAN 1|  |AP/RAN 3|
                      |________|   |________|  |________|
                           |        ____|___
                                   |        |
                          CN       |   MN   |
                                   |________|


       Figure 1: Flat (HA only) and Hierarchical (HA and MAP) MIPv6
                 model


   The method to anticipate MN movement by interacting with the wireless
   L2 is described later in this draft.

   The Hierarchical Mobile IPv6 scheme introduced in [1] allows a Mobile
   Node to perform registrations locally with an MAP in order to reduce
   the number of signalling messages to the home network and CNs. This
   achieves a reduction in the signalling delay when a Mobile Node moves
   between ARs and therefore improves the performance of such handoffs.
   This draft describes Fast Handoffs in Hierarchical Mobile IPv6
   (HMIPv6) using Regional Registrations.
   When considering a MIPv6 handoff, two different cases can be
   considered depending on the network architecture:

      - The previous and new AR are physically connected
      - The previous and new AR are connected via another node/network





El-Malki, Soliman                                               [Page 3]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


      The first case can be considered a subset of the more generic
      case. Hence the solution proposed will be addressing the generic
      (second) scenario.

2. Fast Handoffs

   Fast Handoffs address the need to achieve seamless Mobile IP
   Handoffs when the MN moves between ARs. This is done by "bicasting"
   traffic to the "previous" AR and "new" AR while the MN is moving
   between them. The anticipation of the MN's movement is achieved by
   tight coupling with Layer 2 functionality which is
   dependent on the type of access technology used. The coupling between
   L2 and L3 technologies may occur in the network nodes or the MNs, or
   both, depending on the access technology. "Bicasting" is achieved
   through simultaneous bindings, where the MN activates the "B" flag in
   the MAP registration. When a MAP Registration
   has the "B" flag set, the receiving MAP, which has an existing
   binding for the MN, will add the relevant new binding for the MN  but
   will also maintain any existing binding it had for the MN.

   Two different handoff scenarios are considered in this draft:

      -  A MN having to do a handoff between two different ARs with
         which it can be simultaneously data-connected (eg. Two
         different access technologies). In this case it may not be
         essential to request simultaneous bindings. The MN may simply
         continue using both COAs (on the old and new link) as
         specified in [2].

      -  A MN having to do a handoff between two access routers with
         which it can not be simultaneously data-connected.
         This is the more generic case and _bicasting_ can be used to
         achieve Fast Handofffs.

   When the MN has multiple active bindings with a MAP, it may or may
   not receive multiple copies of the same traffic directed to it.
   The use of simultaneous bindings does not necessarily mean that
   the MN is receiving packets contemporarily from multiple sources.
   This depends on the characteristics of the access (L2) technology.
   The "bicasting" of packets is used to anticipate the MN's movement
   and speed up handoffs by sending a copy of the data to the AR which
   the MN is moving to. Until the MN actually completes the L2 handoff
   to the new AR, the data "copy" reaching this AR may be discarded. In
   this way the total handoff delay is limited to the time needed to
   perform the L2 handoff. Thus, Fast Handoffs coupled to the L2 access
   potentially result in loss-less IP-layer mobility. As described in
   2.1, depending on the L2 characteristics, it is also possible for an
   MN to initiate a Fast Handoff through the "previous" AR without
   having direct access to the "new" AR.





El-Malki, Soliman                                               [Page 4]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


2.1  Initiating Fast Handoffs through the "previous" AR

   In the case in which the wireless L2 technology allows the MN tobe
   data-connected to multiple wireless access points simultaneously,
   the MN may solicit advertisements from ARs before completing
   handoffs. In this case "bicasting" may not be necessary.

   Some existing wireless L2 technologies and their implementations
   do not allow a MN to be data-connected to multiple wireless access
   points simultaneously. Thus, in order to perform a Fast Handoff it is
   necessary for some form of interworking between layers 2 and 3.
   It should be noted that the method by which an AR determines when
   a MN has initiated an L2 handoff is outside the scope of this
   draft and may involve interaction with L2 messaging. Also, the
   interaction between L2 and L3 should allow the Mobile Node to
   perform a L2 handoff only after having performed the L3 Fast
   Handoff described in this draft. That is, the L2 handoff may be
   performed after the MN's Registration with the "new" AR which
   produces a simultaneous binding at the MAP. This Registration
   may be transmitted more than once to reduce the probability that
   it is lost due to errors on the wireless link. Alternatively, the MN
   may choose to send a BU to the MAP with the _A_ flag set.

   A Fast Handoff in this case requires the MN to receive "new" router
   advertisements through the "old" wireless access points, and to
   perform a registration with the "new" FA through the "old"
   wireless access point. Two ways of performing this follow.


   I.   Inter-AR Solicitation

   This solution assumes that the AR with which the MN is currently
   registered is aware of the IP address of the "new" AR which the MN is
   moving to and a physical connection exists between them (ie. they
   have a common link). The method by which the current AR is informed
   of this may depend on interaction with L2 and is outside the scope of
   this draft.

   Once the current AR is aware of the address of the AR which the MN
   will move to, it will send the "new" AR a router solicitation
   message. The "new" AR will reply to the current AR by sending it
   a router advertisement with appropriate extensions. The current AR
   will then send the router advertisement to the MN's address. As a
   consequence, the MN, being eager to perform new registrations,
   will send a registration request to the "new" AR through the
   "old" wireless access point served by the current AR.








El-Malki, Soliman                                               [Page 5]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


   II.  Piggy-backing Advertisements on L2 messaging

   Let us take Figure 1 as an example, where a MN initiates an L2
   handoff from AP/RAN1 to AP/RAN2 (Note that it may not be the MN
   which takes decisions on handoffs). It is assumed that when an L2
   handoff is initiated, AP/RAN1 and AP/RAN2 perform L2 messaging
   procedures to negotiate the L2 handoff. Since the MN is not
   attached to AP/RAN2 yet, AR2 is unaware of the IP address of the
   MN and cannot send an advertisement to it. Therefore it is
   necessary for the L2 procedures to interwork with Mobile IP.

   Once a L2 handoff is initiated, such that AP/RAN2 and AP/RAN1 are
   in communication, it is possible for AP/RAN2 to solicit an
   advertisement from AR2 and transfer it to AP/RAN1. Once this is
   received by the MN, the MN can perform a registration directed to
   AR2 even though the MN has no data-connection to AP/RAN2 yet.

   The precise definition of such L2 procedures is outside the scope
   of Mobile IP.

3. Fast Handoffs in HMIPv6

   HMIPv6 is described in [1]. Fast IP Handoffs can be achieved in a
   very simple and efficient manner.
   When the MN receives a router Advertisement including a MAP option,
   as specified in [1], it should perform actions according to the
   following movement detection mechanisms. In a Hierarchical Mobile IP
   network such as the one described in this draft, the MN MUST be:

      - "Eager" to perform new bindings
      - "Lazy" in releasing existing bindings

   The above means that the MN will perform Regional Registrations
   with any "new" MAP advertised by the AR (Eager).
   The method by which the MN determines whether the MAP is a "new" MAP
   is described in [1]. However the MN should not release existing
   bindings until it no longer receives its MAP option or the lifetime
   of its existing binding expires (Lazy).

   If the MN has at least one existing binding with a MAP, additional
   simultaneous regional registrations will be performed requesting a
   short lifetime. This is done in order to limit the lifetime of
   bindings which the MN only needs temporarily and therefore limit
   bandwidth usage. This is the case when the MN is moving between
   ARs and uses Fast Handoffs to achieve near loss-less IP mobility. The
   lifetime of additional "auxiliary" bindings needed for Fast
   Handoffs is thus limited.

   It should be noted that the method described above is applicable to
   hierarchical and flat architectures. As described in [1], a MAP can
   exist on any level in the hierarchy, including ARs. Hence, a



El-Malki, Soliman                                               [Page 6]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


   bicasting request can also be sent to a MAP located in the AR, in the
   case where no MAPs are located higher in the hierarchy.

4. Extensions to MIPv6

   To allow bicasting from the MAP to take place, a new flag,_B_, is
   added to the BU message. Upon reception of a BU message with the _B_
   flag set, a MAP SHOULD bicast all incoming packets addressed to the
   MN to its current COA as well as the new COA in the BU requesting the
   bicast. The new BU message is shown below.


     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |  Option Type  | Option Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A|H|R|D|M|B|Res| Prefix Length |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Sub-Options...
    +-+-+-+-+-+-+-+-+-+-+-+-

   Description of extensions to the BU option:

   B              If set, it indicates a request for bicasting all
                  traffic received for the MN to its current address
                  as well as the new address in the BU.

   Res            2 bit reserved field


5. Fast Handoffs and DAD

   The use of DAD to verify the uniqueness of a statelessly configured
   IPv6 address may add delays to a MIPv6 handoff. The probability of an
   inteface identifier duplication on the same subnet can be considered
   very low. Hence, to avoid this delay, a MN may choose to continue
   sending and receiving traffic using its newly formed COA while
   performing DAD on the new subnet. In the case where a duplication
   exists, the MN MUST follow the rules in [4].
   This issue is not specific to this proposal and may also be addressed
   in future revisions of [2].

6. Notice Regarding Intellectual Property Rights

   Ericsson may seek patent or other intellectual property protection
   for some or all of the technologies disclosed in this document. If
   any standards arising from this disclosure are or become protected by
   one or more patents assigned to Ericsson, Ericsson intends to



El-Malki, Soliman                                               [Page 7]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


   disclose those patents and license them on reasonable and non-
   discriminatory terms. Future revisions of this draft may contain
   additional information regarding specific intellectual property
   protection sought or received.

7. References

   [1]   H. Soliman, C. Castellucia, K. El Malki and L. Bellier
         "Hierarchical Mobile IPv6 and Fast Handoffs",
         draft-ietf-mobileip-hmipv6-00.txt (work in progress),
         September 2000

   [2]   D. Johnson and C. Perkins, "Mobility Support in IPv6",
         draft-ietf-mobileip-ipv6-12.txt, February 2000.

   [3]   K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4".
         (work in progress)

   [4]   S. Thomson and T. Narten "IPv6 Stateless Address
         Autoconfiguration". RFC 2462.

8. Acknowledgements

   The authors would like to thank the following members of the working
   group (in alphabetical order) for their comments and the interesting
   discussions about this draft: Gopal Dommety (Cisco), Dave Johnson
   (Rice University), Erik Nordmark (Sun), Mohan Parthasarathy (Sun),
   Carl Williams (Sun)and Alper Yegin (Sun).

9. Addresses


   The working group can be contacted via the current chairs:


   Basavaraj Patil               Phil Roberts
   Nokia Corporation             Motorola        M/S M8-540
   6000 Connection Drive         1501 West Shure Drive
   Irving, TX 75039              Arlington Heights, IL 60004
   USA                           USA

   Phone:  +1 972-894-6709       Phone:  +1 847-632-3148
   EMail:  Raj.Patil@nokia.com   EMail:  QA3445@email.mot.com
   Fax :  +1 972-894-5349

   Questions about this memo can be directed to:

   Karim El Malki
   Ericsson Radio Systems AB
   Access Networks Research
   SE-164 80 Stockholm



El-Malki, Soliman                                               [Page 8]


INTERNET-DRAFT           Fast Handoffs in MIPv6           September,2000


   SWEDEN

   Phone:  +46 8 7573561
   Fax:    +46 8 7575720
   E-mail: Karim.El-Malki@era.ericsson.se


   Hesham Soliman
   Ericsson Australia
   61 Rigall St., Broadmeadows
   Melbourne, Victoria 3047
   AUSTRALIA

   Phone:  +61 3 93012049
   Fax:    +61 3 93014280
   E-mail: Hesham.Soliman@ericsson.com.au






































El-Malki, Soliman                                               [Page 9]