[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-yokota-mipshop-3gfh) 00 01 02 03 04 05 06 07 RFC 5271

Network Working Group                                          H. Yokota
Internet-Draft                               KDDI R&D Laboratories, Inc.
Expires: April 26, 2007                                       G. Dommety
                                                     Cisco Systems, Inc.
                                                        October 23, 2006


            Mobile IPv6 Fast Handovers for 3G CDMA Networks
                     draft-ietf-mipshop-3gfh-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on April 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Mobile IPv6 is designed to maintain its connectivity while moving
   from one network to another.  It is adopted in 3G CDMA networks as a
   way to maintain connectivity when the mobile node moves between
   access routers.  However, this handover procedure requires not only
   movement detection, but also the acquisition of a new care-of address
   and the sending of a binding update message to the home agent before
   the traffic begins to direct to the new location.  During this



Yokota & Dommety         Expires April 26, 2007                 [Page 1]

Internet-Draft            3G CDMA Fast Handover             October 2006


   period, packets destined for the mobile node will be lost, which may
   not be acceptable for real-time application such as Voice over IP
   (VoIP) or video telephony.  This document specifies fast handover
   methods and selective bi-casting methods in the 3G context in order
   to reduce latency and packet loss during handover.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Network reference model for Mobile IPv6 over 3G networks . . .  6
   5.  Fast handover procedures . . . . . . . . . . . . . . . . . . . 10
     5.1   Predictive fast handover . . . . . . . . . . . . . . . . . 10
     5.2   Reactive fast handover . . . . . . . . . . . . . . . . . . 14
     5.3   Network-controlled fast handover . . . . . . . . . . . . . 17
   6.  Selective bi-casting . . . . . . . . . . . . . . . . . . . . . 21
     6.1   Bi-casting by the PAR to the MN with multiple
           interfaces (A-1) . . . . . . . . . . . . . . . . . . . . . 23
     6.2   Bi-casting by the HA to the MN with multiple
           interfaces (A-2) . . . . . . . . . . . . . . . . . . . . . 25
     6.3   Bi-casting by the PAR to the MN with a single
           interface (B-1)  . . . . . . . . . . . . . . . . . . . . . 26
     6.4   Bi-casting by the HA to the MN with a single interface
           (B-2)  . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     6.5   Message Format . . . . . . . . . . . . . . . . . . . . . . 29
       6.5.1   Handover Request (HReq)  . . . . . . . . . . . . . . . 30
       6.5.2   Handover Response (HRes) . . . . . . . . . . . . . . . 31
       6.5.3   Simultaneous bindings flag and the HI message
               indication flag extensions to (F)BU message  . . . . . 32
       6.5.4   New mobility option for bi-casting lifetime  . . . . . 33
       6.5.5   New status code for simultaneous bindings  . . . . . . 33
       6.5.6   New Option for access-specific handover information  . 33
       6.5.7   New Option for Vendor/Organization Specific
               Extensions . . . . . . . . . . . . . . . . . . . . . . 34
     6.6   MN and AR/HA operations  . . . . . . . . . . . . . . . . . 34
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 37
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 38
       Intellectual Property and Copyright Statements . . . . . . . . 39










Yokota & Dommety         Expires April 26, 2007                 [Page 2]

Internet-Draft            3G CDMA Fast Handover             October 2006


1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [1].














































Yokota & Dommety         Expires April 26, 2007                 [Page 3]

Internet-Draft            3G CDMA Fast Handover             October 2006


2.  Introduction

   Mobile IPv6 allows mobile nodes (MNs) to maintain persistent IPv6
   addresses while roaming around in IPv6 networks and it is adopted in
   3G CDMA networks for handing off between different access provider
   networks [2].  During handover, however, the mobile node (MN) needs
   to switch the radio networks, to obtain a new Care-of Address (CoA)
   and to re-register with the home agent (HA), which causes a
   communication disruption.  This is not desirable for real-time
   applications such as VoIP and video telephony.  To reduce this
   disruption time or latency, a fast handover protocol for Mobile IPv6
   [3] is proposed.  In this proposal, there are two modes called
   "predictive" fast handover and "reactive" fast handover.  This
   document first specifies how these fast handover modes can be applied
   in the 3G context and shows that several Mobile IPv6 bootstrapping
   procedures can be omitted.  In the case where the lower layer can
   provide necessary information for handover, network-controlled fast
   handover defined in this document can also be applied.  If the MN has
   more than one network interface, even smoother handover can be
   realized by transmitting packets destined for the MN to both
   networks, where the mobile node resides and will move to.  This
   document defines this mechanism as selective bi-casting and shows
   several use cases with their handover procedures.




























Yokota & Dommety         Expires April 26, 2007                 [Page 4]

Internet-Draft            3G CDMA Fast Handover             October 2006


3.  Terminology

   This document refers to [2] for Mobile IPv6 fast handover
   terminology.  Terms that first appear in this document are defined
   below:

   Forward Pilot Channel:
        A portion of the Forward Channel that carries the pilot.  The
        Forward Channel is a portion of the physical layer channels
        transmitted from the access network to the MN.

   Sector:
        A typical cell divides its coverage area into several sectors.
        In 3G CDMA systems, each sector uses a different PN (Pseudo
        Noise) code offset.

   Home Link Prefix (HLP):
        The prefix address assigned to the home link where the MN should
        send the binding update message.  This is one of the bootstrap
        parameters for the MN.

   Packet Data Serving Node (PDSN):
        An entity that routes MN originated or MN terminated packet data
        traffic.  A PDSN establishes, maintains and terminates link-
        layer sessions to MNs [2].  A PDSN can be the access router in
        the visited access provider network.

   Selective bi-casting:
        Short-term bi-casting that is performed during the period of
        handover to reduce delay and packet loss.  Selective bi-casting
        utilizes the timing of the predictive fast handover mode and not
        only the home agent but also the access routers may be involved
        for bi-casting and/or buffering packets.


















Yokota & Dommety         Expires April 26, 2007                 [Page 5]

Internet-Draft            3G CDMA Fast Handover             October 2006


4.  Network reference model for Mobile IPv6 over 3G networks

   Figure 1 shows a simplified reference model of the Mobile IP enabled
   3G networks.  The home agent (HA) of the mobile node (MN) resides in
   the home IP network and the MN roams within or between the access
   provider network(s).  Prior to the Mobile IPv6 registration, the MN
   establishes a link-layer connection with the access router (AR),
   which is also called PDSN (Packet Data Serving Node) in 3G networks,
   of the access provider network to which the MN is attached.  When the
   MN moves from one AR (PDSN) to another, the link-layer connection is
   re-established and a Mobile IPv6 handover is performed.  Those ARs
   reside in either the same or different access provider network(s).
   The figure shows the situation, where the MN moves from the PAR
   (previous access router) to the NAR (new access router) and in the
   case of 3G networks, the PAR and the NAR are equivalent to the oPDSN
   (old PDSN) and the nPDSN (new PDSN).






                                      Home IP Network
                                 +........................+
                                 . +--------+  +--------+ .
                                 . |   HA   |--|  AAA   | .
                                 . +--------+  +--------+ .
                                 +../......\..............+
                                   /        \
                             Access Provider Network(s)
                      +.............+      +.............+
                      . +---------+ .      . +---------+ .
                      . |   PAR   | .      . |   NAR   | .
                      . | (oPDSN) | .      . | (nPDSN) | .
                      . +---------+ .      . +---------+ .
                      .   |    :|   .      .   :|    |   .
                      .   |    :|L2link  L2link:|    |   .
                      .   |    :|   .      .   :|    |   .
                      . +--+  +:--+ .      .  +:--+ +--+ .
                      . |BS|  |:BS| .      .  |:BS| |BS| .
                      . +--+  +:--+ .      .  +:--+ +--+ .
                      .        :|   .      .   :|        .
                      .      +----+ .      .  +----+     .
                      .      | MN |---------> | MN |     .
                      .      +----+ .      .  +----+     .
                      +.............+      +.............+

                  Figure 1: Reference Model for Mobile IP



Yokota & Dommety         Expires April 26, 2007                 [Page 6]

Internet-Draft            3G CDMA Fast Handover             October 2006


   In 3G CDMA networks, pilot channels transmitted by base stations
   allow the MN to obtain a rapid and accurate C/I (carrier to
   interference) estimate.  This estimate is based on measuring the
   strength of the Forward Pilot Channel or the pilot, which is
   associated with a sector of a base station (BS).  The MN searches for
   the pilots and maintains those with sufficient signal strength in the
   pilot sets.  The MN sends measurement results, which include the
   offsets of the PN code in use and the C/Is in the pilot sets, to
   provide the access network (AN) with the estimate of sectors in its
   neighborhood.  There are several triggers for the MN to send those
   estimates, e.g. when the strength of a pilot in the pilot sets is
   higher enough than that of the current pilot, the MN sends the
   estimates to the access network.  If the serving access network finds
   that the sector associated with the highest pilot strength belongs to
   a different AR, it attempts to close the connection with the MN.  The
   MN then attempts to get a new traffic channel assigned in the new
   access network, which is followed by establishing a new connection
   with the new AR.  The MN can continually search for pilots without
   disrupting the data communication and a timely handover is assisted
   by the network.  If the air interface information can be used as a
   trigger for the handover between access routers, fast and smooth
   handover of Mobile IPv6 can be realized in 3G CDMA networks.

   To assist the handover of the MN to the new AR, various types of
   information can be considered: the pilot sets, which include the
   candidates of the target sectors or BSs, the cell information where
   the MN resides, the serving nodes in the radio access network and the
   location of the MN if available.  To identify the access network that
   the MN moves to or from, the Access Network Identifiers (ANID), which
   is composed of the System ID (SID), Network ID (NID) and Packet Zone
   ID (PZID) can be used [4].  In this document, a collection of such
   information is called "handover assist information".  In 3G networks,
   the link-layer address of the new access point defined in [3] may not
   be available.  If this is the case, the handover assist information
   SHOULD be used instead.

   Figure 2 shows the protocol sequence from the attachment to the
   network to the Mobile IPv6 registration.  After the traffic channel
   is assigned, the MN first establishes a link-layer connection between
   itself and the access router.  As the link-layer protocol, PPP can be
   considered and in this figure, a PPP handshake is depicted as an
   example.  Then the MN registers with the HA by sending a Binding
   Update message.  There are several parameters for using Mobile IPv6
   such as the home address (HoA), the care-of address (CoA), the home
   agent address (HA) and the home link prefix (HLP).  These addresses
   are required prior to sending a Binding Update and obtaining these
   values is called bootstrapping.  One such method is proposed in [6],
   where the bootstrapping information is obtained during the link-layer



Yokota & Dommety         Expires April 26, 2007                 [Page 7]

Internet-Draft            3G CDMA Fast Handover             October 2006


   establishment phase.

                 MN                     AR             HA            AAA
        +--      |                    (PDSN)           |              |
        |        |         LCP          |              |              |
        |(1)     |<-------------------->|              |              |
        |        |     CHAP or PAP      | Access-Request/Accept       |
        |(2)     |<-------------------->|<---------|----------------->|
        |        |                +------------+   |   |              |
        |(3)     |                | HA,HLP,HoA |<--+   |              |
        |        |                +------------+       |              |
        |        |    IPv6CP(IF-ID)     |              |              |
        |(4)     |<--------|----------->|              |              |
    (a)<     +---------+   |            |              |              |
        |(5) | LL-addr |<--+            |              |              |
        |    +---------+                |              |              |
        |        |     RA(prefix)       |              |              |
        |(6)     |<-----|---------------|              |              |
        |     +-----+   |               |              |              |
        |(7)  | CoA |<--+               |              |              |
        |     +-----+                   |              |              |
        |        |   DHCPv6(HA,HLP,HoA) |              |              |
        |(8)     |<-----------|-------->|              |              |
        |    +------------+   |         |              |              |
        |(9) | HA,HLP,HoA |<--+         |              |              |
        |    +------------+             |              |              |
        *--      |                      | BU           |              |
    (b)          |------------------------------------>|Authentication|
                 |                      |              |  query/reply |
    (c)          |                      |              |<------------>|
                 |                      | BA           |              |
    (d)          |<------------------------------------|              |
                 |                      |              |              |

                  Figure 2: MIPv6 operation in 3G network

   The procedure for the initial registration is as follows:

      (a) The link-layer connection establishment and the bootstrapping
      phase

      (a-1) The LCP configure-request/response messages are exchanged.

      (a-2) CHAP or PAP authentication is conducted.

      (a-3) The bootstrapping parameters (e.g.  HA, HLP or HoA) are
      conveyed from the AAA and stored in the AR (PDSN).




Yokota & Dommety         Expires April 26, 2007                 [Page 8]

Internet-Draft            3G CDMA Fast Handover             October 2006


      (a-4) Unique interface IDs are negotiated in IPv6CP.

      (a-5) The MN configures its link-local address based on the
      obtained interface ID.

      (a-6) A router advertisement containing the prefix is received by
      the MN.

      (a-7) The MN configures its CoA based on the obtained prefix.

      (a-8) DHCPv6 is used to obtain the bootstrap parameters such as
      the HA, HLP or HoA.

      (a-9) The MN configures its HoA based on the obtained parameters.
      If a new HoA is provided at (a-8), the MN adopts it (stateful
      auto-configuration); otherwise, the MN generates the HoA based on
      the HLP and its Interface ID (stateless auto-configuration).

      (b) A binding update is sent to the HA.

      (c) The HA asks the AAA to authenticate the MN for the initial
      registration.

      (d) The binding acknowledgment is sent back to the MN.

   As is shown in Figure 2, it takes a considerable amount of time to
   establish a link-layer connection and all of the above sequences run
   every time the MN attaches to a new access network.  It is therefore
   beneficial if packets on the fly to the MN are saved not only during
   the time period where the MN switches to the new radio channel but
   also during the time period where the MN establishes the link-layer
   connection.



















Yokota & Dommety         Expires April 26, 2007                 [Page 9]

Internet-Draft            3G CDMA Fast Handover             October 2006


5.  Fast handover procedures

   There are two modes defined in [3] according to the timing of sending
   FBU (Fast Binding Update); one is called "predictive mode," where the
   MN sends FBU and receives FBAck (Fast Binding Ack) on PAR (Previous
   Access Router)'s link and the other is called "reactive mode," where
   the MN sends FBU from NAR (New Access Router)'s link.  In the
   predictive mode, the time and place the MN hands off must be
   indicated sufficiently before the time it actually happens.  In
   cellular systems, since handovers are controlled by the network, the
   predictive mode is well applied.  However, if the network is not
   configured to be able to identify the new AR, to which the MN is
   moving next, in a timely manner, the reactive mode is better applied.

5.1  Predictive fast handover

   Figure 3 shows the predictive mode of MIPv6 fast handover operation.
   When the MN finds a sector or a BS whose pilot signal is sufficiently
   strong, it initiates handover according to the following sequence:

      (a) A router solicitation for proxy router advertisement is sent
      to the PAR.

      (b) A proxy router advertisement containing the prefix in the NAR
      is sent back to the MN.

      (c) The MN creates an NCoA (new CoA) and sends the Fast Binding
      Update (FBU) storing the NCoA to the PAR, which in turn sends the
      Handover Initiate (HI) to the NAR.

      (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR,
      which in turn sends the FBU acknowledgment (FBAck) to the MN.

      (e) The PAR starts forwarding packets toward the NCoA and the NAR
      captures and buffers them.

      (f) The link-layer connection associated with the PAR (e.g.  PPP
      connection) is closed and a new traffic channel is assigned in the
      new access network.

      (g) The MN establishes the link-layer connection with or without
      authentication.

      (h) The MN sends the Fast Neighbor Advertisement (FNA).

      (i) The NAR starts delivering packets to the MN.





Yokota & Dommety         Expires April 26, 2007                [Page 10]

Internet-Draft            3G CDMA Fast Handover             October 2006


      (j) The MN sends the BU to the HA.

      (k) The HA sends the BA back to the MN.

      (l) The HA starts delivering packets to the MN via the NAR.


         MN            PAR             NAR            HA             AAA
         |    RtSolPr   |               |              |              |
    (a)  |------------->|               |              |              |
         |    PrRtAdv   |               |              |              |
    (b)  |<-------------|               |              |              |
         |      FBU     |      Hl       |              |              |
    (c)  |------------->|-------------->|              |              |
         |     FBack    |     HAck      |              |              |
    (d)  |<-------------|<--------------|              |              |
         |              |forward packets|              |              |
    (e)  |              |==============>|              |              |
         |              |         +-----------+        |              |
         | link-layer   |         | buffering |        |              |
         | connection close       +-----------+        |              |
    (f)  |/-----X------\|               |              |              |
         |\-----X------/|               |              |              |
        handover        |               |              |              |
         |           link-layer connection establishment              |
    (g)  |/----------------------------\|/...........................\|
         |\----------------------------/|\.........................../|
         |             FNA              |              |              |
    (h)  |----------------------------->|              |              |
         |       deliver packets        |              |              |
    (i)  |<=============================|              |              |
         |              |    BU         |              |              |
    (j)  |-------------------------------------------->|              |
         |              |    BA         |              |              |
    (k)  |<--------------------------------------------|              |
         |       deliver packets        |              |              |
    (l)  |<=============================|<=============|              |


         Figure 3: MIPv6 Fast handover operation (predictive mode)

   It is assumed that the NAR can be identified by the PAR leveraging
   the handover assist information from the MN.  To perform the
   predictive mode, the MN MUST send the FBU before the connection with
   the current access network is closed.  If the MN fails to send the
   FBU before handover, it SHOULD fall back to the reactive mode.  Even
   if the MN successfully sends the FBU, its reception by the PAR may be
   delayed for various reasons such as congestion.  If the NAR receives



Yokota & Dommety         Expires April 26, 2007                [Page 11]

Internet-Draft            3G CDMA Fast Handover             October 2006


   the HI triggered by the delayed FBU after the reception of the FNA
   ((c) comes after (h)), then the NAR SHOULD send the HAck with
   handover not accepted and behave as the reactive mode.

   In (a), RtSolPr MUST include the MN and the New Access Point Link-
   Layer Address (LLA) options according to [3].  As for the MN-LLA
   option, the only available identifier is the interface ID, so it
   SHOULD be used for the MN-LLA.  As for the New AP-LLA, the handover
   assist information may be applied.  Since the LLA is assumed to be an
   IEEE identifier, even if the length field of the LLA option is in
   units of 8 octets, the actual length can be obtained by knowing that
   the length of an IEEE identifier is 6 octets.  If the interface ID of
   the MN is generated in the EUI-64-based format, the MN-LLA can be
   constructed from it.  However, if the LLA is not well-known, the
   length of the LLA becomes ambiguous.  If this is the case, it is
   necessary to use a new option defined in Section 6.5.6 and the
   corresponding length in it.

   In (b), PrRtAdv MUST include options for the LLA, IP address and
   prefix of the NAR.  The PAR SHOULD be able to identify the NAR from
   the handover assist information provided by the MN.

   There are several ways to configure a unique IP address for the MN.
   If a globally unique prefix is assigned per each link as introduced
   in [6], the MN can use any interface ID except that of the other peer
   to create a unique IP address.  If this is the case, however, the PAR
   cannot provide the MN with a correct prefix for the new network since
   such a prefix is selected by the NAR and provided in the router
   advertisement ((a-6) in Figure 2).  Still, the NCoA MUST be included
   in the FBU for the PAR to resolve the IP address of the NAR, so that
   the MN configures a temporary NCoA with the prefix of the NAR and the
   correct NCoA MUST be assigned by the NAR.  Therefore, in (c), the PAR
   MUST send the HI with the S flag set when it receives the FBU from
   the MN.  On the other hand, if more than one MN connected to an AR
   share the same prefix, each MN MUST have a unique interface ID.
   Unless it is guaranteed that each MN connected to the network
   including a roaming case is preconfigured with a unique interface ID,
   it MUST be agreed or provided by the NAR via the HI/Hack exchange.

   In [3], the FNA MUST include the LLA of the MN, but the point-to-
   point link-layer connection makes it unnecessary.  The only required
   information is the NCoA to check if there is a corresponding buffer,
   thus in (h), the function of the FNA can be realized in several ways.

   o  Since the establishment of the link-layer connection in (g)
      indicates readiness of data communication on the MN side, the NAR
      immediately checks if there is a buffer that has packets destined
      for the NCoA and starts delivering if any. (elimination of FNA)



Yokota & Dommety         Expires April 26, 2007                [Page 12]

Internet-Draft            3G CDMA Fast Handover             October 2006


   o  The FNA equivalent information can be conveyed in the phase of the
      link-layer connection, e.g. by conveying the NCoA in a PPP IPCP
      with vendor specific extension as defined in [7].  Only when this
      message is received by the NAR, it checks if there is a buffer for
      the NCoA.  (L2 implementation of FNA)

   o  The MN sends the FNA as defined in [3] with the LLA of the MN,
      which may be derived from the EUI-64 based interface ID. (standard
      implementation of FNA)

   When PPP IPCP option is used as the means for the L2 implementation
   of FNA, it SHOULD be confirmed that the NAR supports this option,
   otherwise it may cause a longer delay by the Configure-Reject
   message.

   The primary benefit of this mode is that the packets destined for the
   MN can be buffered at the NAR, and packet loss due to handover will
   be much lower than that of the normal MIPv6 operation.  Regarding the
   bootstrapping, the following benefits can be obtained, too:

   o  Since the HA, HLP and HoA are not changed during the fast
      handover, bootstrapping information is not required.

   o  Since the NCoA including the interface ID can be obtained or
      configured via the fast handover procedures, a router
      advertisement is not required.

   Therefore, as shown in Figure 4, bootstrapping procedures (a-3) to
   (a-9) can be omitted from the standard MIPv6 operation in Figure 2.
   Also, if the security policy permits, the NAR can know the MN by the
   NAI in the PPP link setup and the authentication in (2) may be
   omitted.  Note that another authentication is conducted in the MIPv6
   registration phase and presumably the same AAA is referred to.


















Yokota & Dommety         Expires April 26, 2007                [Page 13]

Internet-Draft            3G CDMA Fast Handover             October 2006


                  MN          oPDSN       nPDSN        HA          AAA
          +--     |           (PAR)       (NAR)         |           |
          |       |        LCP  |           |           |           |
          | (1)   |<----------------------->|           |           |
          |       |        CHAP |           | Access-Request/Accept |
          | (2)   |<----------------------->|<-------|------------->|
          |+...................................+     |  |           |
          |.      |       +------------+    |  .     |  |           |
          |.(3)*  |       | HA,HLP,HoA |<------------+  |           |
          |.      |       +------------+    |  .        |           |
          |.      |                         |  .        |           |
          |.      |    IPv6CP(IF-ID)        |  .        |           |
          |.(4)*  |<---------|------------->|  .        |           |
      (a)< .    +---------+  |  |           |  .        |           |
          |.(5)*| LL-addr |<-+  |           |  .        |           |
          |.    +---------+     |           |  .        |           |
          |.      |                         |  .        |           |
          |.      |       RA(prefix)        |  .        |           |
          |.(6)*  |<---------|--------------|  .        |           |
          |.    +-----+      |  |           |  .        |           |
          |.(7)*| CoA |<-----+  |           |  .        |           |
          |.    +-----+         |           |  .        |           |
          |.      |                         |  .        |           |
          |.      |   DHCPv6(HA,HLP,HoA)    |  .        |           |
          |.(8)*  |<---------|------------->|  .        |           |
          |.    +-----+      |  |           |  .        |           |
          |.(9)*| HoA |<-----+  |           |  .        |           |
          |.    +-----+         |           |  .        |           |
          |+...................................+        |           |
          *--     |             |           |           |           |

   Figure 4: Procedures that can be omitted in the link-layer connection


5.2  Reactive fast handover

   When the MN cannot receive the FBAck on the PAR's link or the network
   does not support the predictive fast handover, the reactive fast
   handover can be applied.  To support the predictive fast handover,
   the PAR must accurately resolve the address of the NAR from the lower
   layer information such as the link-layer address of the new access
   point or the base station, which is not always feasible in some
   cases.  To minimize packet loss in this situation, the PAR instead of
   the NAR can buffer packets for the MN until the MN regains
   connectivity with the NAR.  The NAR obtains the information of the
   PAR from the MN on the NAR's link and receives packets buffered at
   the PAR.  In this case, the PAR does not need to know the IP address
   of the NAR or the NCoA and just waits for the NAR to contact the PAR.



Yokota & Dommety         Expires April 26, 2007                [Page 14]

Internet-Draft            3G CDMA Fast Handover             October 2006


   However, since the PAR needs to know when to buffer packets for the
   MN, the PAR obtains the timing of buffering from the MN via the FBU
   or the lower layer signaling, e.g. an indication of the release of
   the connection with the MN.  Details of the procedure are as follows:

      (a) A router solicitation for proxy router advertisement MAY be
      sent to the PAR.

      (b) The proxy router advertisement MAY be sent to the MN, but the
      prefix of the NAR MAY not be included.

      (c) The MN sends the FBU or the access network indicates the close
      of the connection with the MN by the lower layer signaling.  The
      PAR MAY start buffering packets destined for the PCoA.

      (d) The link-layer connection associated with the PAR (e.g.  PPP
      connection) is closed and a new traffic channel is assigned in the
      new access network.

      (e) The MN establishes the link-layer connection.  Since the IP
      address of the MN is guaranteed to be unique, the MN SHOULD not
      perform DAD

      (f) The MN sends the Fast Binding Update (FBU) to the NAR either
      or not being encapsulated by the Fast Neighbor Advertisement
      (FNA).

      (g) The NAR decapsulates the FBU if encapsulated and sends it to
      the PAR.

      (h) The PAR sends the Handover Initiate (HI) to the NAR with the
      Code set to 1.

      (i) The NAR sends the Handover Acknowledge (HAck) back to the PAR.

      (j) The PAR sends the FBAck to the NAR.

      (k) If the PAR buffers packets destined for the PCoA, it starts
      forwarding them as well as newly arriving ones to the NAR.

      (l) The NAR delivers the packets to the MN.

      (m) The MN sends the BU to the HA.

      (n) The HA sends the BA back to the MN.

      (o) The HA starts delivering packets to the MN via the NAR.




Yokota & Dommety         Expires April 26, 2007                [Page 15]

Internet-Draft            3G CDMA Fast Handover             October 2006


         MN           oPDSN           nPDSN            HA            AAA
         |            (PAR)           (NAR)            |              |
         |   RtSolPr    |               |              |              |
    (a)  |------------->|               |              |              |
         |   PrRtAdv    |               |              |              |
    (b)  |<-------------|               |              |              |
         | FBU/lower-layer sig.         |              |              |
    (c)  | . . . . . . >|               |              |              |
         |        +-----------+         |              |              |
         |        | buffering |         |              |              |
         |        +-----------+         |              |              |
         |link-layer connection close   |              |              |
    (d)  |/-----X------\|               |              |              |
         |\-----X------/|               |              |              |
        handover        |               |              |              |
         |           link-layer connection establishment              |
    (e)  |/----------------------------\|/...........................\|
         |\----------------------------/|\.........................../|
         |        FNA[FBU]/FBU          |              |              |
    (f)  |----------------------------->|              |              |
         |              |     FBU       |              |              |
    (g)  |              |<--------------|              |              |
         |              |      HI       |              |              |
    (h)  |              |-------------->|              |              |
         |              |     HAck      |              |              |
    (i)  |              |<--------------|              |              |
         |              |     FBack     |              |              |
    (j)  |              |-------------->|              |              |
         |              |forward packets|              |              |
    (k)  |              |==============>|              |              |
         |        deliver packets       |              |              |
    (l)  |<=============================|              |              |
         |              |     BU        |              |              |
    (m)  |-------------------------------------------->|              |
         |              |     BA        |              |              |
    (n)  |<--------------------------------------------|              |
         |        deliver packets       |              |              |
    (o)  |<=============================|<=============|              |

          Figure 5: MIPv6 Fast handover operation (reactive mode)

   To indicate the PAR to buffer packets destined for the PCoA, in (c),
   the MN SHOULD not include information on the NCoA in the FBU and the
   PAR SHOULD accept it.  Or, when the PAR is indicated that the session
   with the MN has been closed by the lower layer signaling when the PAR
   attempts to send the FBAck, the PAR MAY start buffering.

   An L2-based fast handover is possible as defined in [8] by extending



Yokota & Dommety         Expires April 26, 2007                [Page 16]

Internet-Draft            3G CDMA Fast Handover             October 2006


   the L2 link from the previous access network to the new access
   network via the PAR and the NAR.  The timing of the fast handover
   trigger is the same as the reactive fast handover method (without
   buffering) in this section.  In the case of the L2-based fast
   handover, however, once the L2 link is extended to the new location,
   it is maintained until the MN becomes inactive (dormant) and the link
   is released.  As long as the L2 link is extended, the path, on which
   packets are conveyed, is not optimal in length.  In the case of
   Mobile IPv6 fast handover, when the new location is registered with
   the HA, the packets are directed to the NAR.

5.3  Network-controlled fast handover

   If the lower layer can provide necessary information for handover and
   support handover triggering, then the FBU and the FNA, which are
   initiated by the MN, MAY be replaced by such lower layer protocols
   and the fast handover can be performed without explicit involvement
   of the MN.  This type of fast handover is proposed, for example, in
   [9] and called the network-controlled fast handover in this document.
   The detailed sequence is shown in Figure 6.

      (a) The P-AN (Previous Access Network) determines the need for
      handoff and initiates handoff towards the N-AN (New Access
      Network).  The P-AN sends the identifier of the PAR to the N-AN.

      (b) The N-AN and the NAR establish a connection and the N-AN sends
      the identifier of the PAR.

      (c) The NAR sends the Handover Request (HReq) to the PAR.  If the
      NAR needs information on the MN such as the mobility state of the
      MN or security information, the NAR attaches those requests to
      this message.

      (d) The PAR sends back the Handover Response (HRes) to the NAR.
      If the NAR requested information on the MN, the PAR attaches such
      information to this message.

      (e) The NAR MAY send the Handover Acknowledge (HAck) to the PAR
      when the NAR is ready to update the binding cache in the HA with a
      binding update message.

      (f) The PAR starts forwarding packets to the NAR and the NAR
      buffers them.

      (g) A new traffic channel for the MN is assigned in the N-AN and
      the connection between the N-AN and the NAR, which has been
      established in (b), is associated with this traffic channel and
      activated.



Yokota & Dommety         Expires April 26, 2007                [Page 17]

Internet-Draft            3G CDMA Fast Handover             October 2006


      (h) The NAR starts delivering packets to the MN.

      (i) The NAR MAY send a BU with the CoA being the NAR's address to
      the HA.

      (j) When the HA receives the BU from the NAR, the BU MUST be
      authenticated by the AAA.

      (k) If the BU is successfully authenticated, the HA sends back the
      BA to the NAR.

      (l) The HA starts sending packets for the MN to the NAR and the
      NAR delivers them to the MN.

      (m) At some point later, the MN MAY obtain a new CoA (NCoA) by
      e.g.  PPP IPv6CP and the RA ((a-4) to (a-7) in Figure 2).

      (n) The MN sends the BU with the CoA being the NCoA to the HA and
      the HA sends back the BA to the MN after successful authentication
      of the BU.  From this time on, the HA starts sending packets
      directly to the MN via the NAR.






























Yokota & Dommety         Expires April 26, 2007                [Page 18]

Internet-Draft            3G CDMA Fast Handover             October 2006


         MN       P-AN       N-AN       PAR       NAR       HA       AAA
         |         |HO initiation        |         |        |         |
    (a)  |         |.........>|          |         |        |         |
         |         |          |AN-AR connection establishment         |
    (b)  |         |          |/------------------\|        |         |
         |         |          |\------------------/|        |         |
         |         |          |          |   HReq  |        |         |
    (c)  |         |          |          |<--------|        |         |
         |         |          |          |   HRes  |        |         |
    (d)  |         |          |          |-------->|        |         |
         |         |          |          |   HAck  |        |         |
    (e)  |         |          |          |<- - - - |        |         |
         |         |          |          |forward packets   |         |
    (f)  |         |          |          |========>|        |         |
         |         |          |          |   +-----------+  |         |
         |         |          |          |   | buffering |  |         |
         |         |          |          |   +-----------+  |         |
        handover   |          |          |         |        |         |
         |radio-link conn. est. & AN-AR conn. activation    |         |
    (g)  |/------------------\|/------------------\|        |         |
         |\------------------/|\------------------/|        |         |
         |         | deliver packets     |         |        |         |
    (h)  |<========================================|        |         |
         |         |          |          |         |   BU   |         |
    (i)  |         |          |          |         |------->|         |
         |         |          |          |         |        |  Auth.  |
    (j)  |         |          |          |         |        |<------->|
         |         |          |          |         |   BA   |         |
    (k)  |         |          |          |         |<-------|         |
         |         | deliver packets     |         |        |         |
    (l)  |<========================================|<=======|         |
         |         |   IPv6CP + RA       |         |        |         |
    (m)  |<--------------------------------------->|        |         |
         |         |          |  BU/BA   |         |        |  Auth.  |
    (n)  |<------------------------------------------------>|<------->|
         |         |          |          |         |        |         |

           Figure 6: Network-controlled fast handover operation

   Since the RtSolPr and PrRtAdv are not exchanged between the MN and
   PAR, the NCoA is not assigned to the MN before handoff; therefore, if
   the PAR needs to send packets for the MN to its new location, the PAR
   forwards them to the NAR.  The NAR is responsible for delivering
   packets whose destination address is the PCoA to the MN in the new
   network.  As far as the PAR is involved, however, the path from the
   HA to the MN is not optimal.  In order to optimize the path towards
   the MN, the binding cache in the HA needs to be updated.  If the
   link-layer connection establishment between the MN and the NAR causes



Yokota & Dommety         Expires April 26, 2007                [Page 19]

Internet-Draft            3G CDMA Fast Handover             October 2006


   a noticeable delay as described in Section 4, the updating of the
   binding cache in the HA MAY be performed so that packets for the MN
   are forwarded to the NAR's address instead of the NCoA.  The NAR
   continues to deliver packets, whose destination address is the PCoA,
   to the MN.  At some point later, the NAR assigns the NCoA to the MN
   in the new network and the MN sends the BU to the HA in order to
   update the binding cache in the HA from the NAR's address to the
   NCoA.

   If the BU is authenticated by the AAA with the security information
   that is shared between the MN and HA, the NAR also needs that
   information when it sends the BU to the HA in lieu of the MN.  Such
   security information MUST be sent to the AR in a secure manner (e.g.
   by the AAA) when the MN is attached to the network and that
   information MUST be securely transferred to the new AR when the fast
   handover is performed.  The BU originated by the AR MUST be
   authenticated by the AAA before the HA returns the BA.


































Yokota & Dommety         Expires April 26, 2007                [Page 20]

Internet-Draft            3G CDMA Fast Handover             October 2006


6.  Selective bi-casting

   If the MN has the capability to receive more than one radio signal,
   even smoother handover can be realized.  This situation happens when,
   for instance, the MN can receive multiple channels of the same radio
   system at the same time, or the MN has multiple interfaces of
   different radio systems.  Especially, when the MN is running a real-
   time and interactive application, long-time buffering at the PAR or
   NAR is not always beneficial for the MN.  If this is the case, it
   will be helpful to deliver packets destined for the MN via both the
   old and new points of attachment at the same time during handover.
   Even if the MN has only a single interface, the above function has
   some benefits when the timing of handover cannot be acquired
   precisely in advance.  This type of use case was originally proposed
   in [11].  Mobile IPv4 allows simultaneous bindings [10] and bi-
   casting is realized by retaining the old care-of address in the
   binding cache and sending packets destined for the MN towards both
   the old and new care-of addresses.  Since bi-casting consumes double
   the network resources, it must be limited to smooth handover.  In
   this document, bi-casting used for a short period of time for smooth
   handover is called "selective bi-casting."  Figure 7 shows that the
   simultaneous bindings and bi-casting are performed at the PAR, which
   copies packets destined for the MN and transmits them not only to the
   old point of attachment but also to the new point of attachment via
   the NAR.  The above operation is more effective when the predictive
   fast handover is applied because in the case of the reactive fast
   handover, all the actions are taken after the MN has moved to the new
   location.  By that time, it is not necessary to deliver packets to
   the old point of attachment.  As another scenario, Figure 8 shows
   that simultaneous bindings are performed at the HA.  This scenario is
   likely to happen when the MN is connected to multiple different
   networks at the same time.  Also, if the access networks in Figure 1
   are operated by different providers, it may be difficult for the ARs
   in these networks to cooperate with each other.  In this case as
   well, the HA must handle simultaneous bindings and bi-casting.
















Yokota & Dommety         Expires April 26, 2007                [Page 21]

Internet-Draft            3G CDMA Fast Handover             October 2006


                                +----------+
                                |    HA    |
                                +----------+
                                  /
                                 /
                         +------/-+      +--------+
                         |  PAR --|------|-- NAR  |
                         +------|-+      +-|------+
                                |          |
                                |          |
                           +----|+        +|----+
                           | BS ||        || BS |
                           +----|+        +|----+
                                \         /
                                 \     | /
                                  >    |<
                                  +------+
                                  |  MN  |-->
                                  +------+


                 Figure 7: Selective bi-casting scenario 1



                                +----------+
                                |    HA    |
                                +----------+
                                  /      \
                                 /        \
                         +------/-+      +-\------+
                         |  PAR | |      | | NAR  |
                         +------|-+      +-|------+
                                |          |
                                |          |
                           +----|+        +|----+
                           | BS ||        || BS |
                           +----|+        +|----+
                                \         /
                                 \     | /
                                  >    |<
                                  +------+
                                  |  MN  |-->
                                  +------+


                 Figure 8: Selective bi-casting scenario 2




Yokota & Dommety         Expires April 26, 2007                [Page 22]

Internet-Draft            3G CDMA Fast Handover             October 2006


   From the above observations, selective bi-casting can be categorized
   from the following viewpoints:

   [No. of interfaces on the MN]
      (A) multiple interfaces
      (B) single interface

   [the node where bi-casting is performed]
      (1) at the PAR
      (2) at the HA

   The goal of selective bi-casting is to reduce packet loss and the
   following design principles are considered:

   o  if the MN has multiple interfaces, there is no need for buffering
      in the network and,

   o  buffering should be done at the node that is as close to the MN as
      possible (the PAR or NAR rather than the HA).

   According to the above principles, the procedures for each
   combination are described below.

6.1  Bi-casting by the PAR to the MN with multiple interfaces (A-1)

   As shown in Figure 9, the MN has two interfaces with the link-layer
   addresses: LLA1 and LLA2.  This case is typical of handover between
   different radio transmission technologies.  Details of the sequence
   are as follows:

      (a) The interface with LLA1 acquires the global IP address PCoA.

      (b) The MN sends the BU to the HA from the link with PCoA with S=0
      and N=0 (the default behavior), which are defined in
      Section 6.5.3, and receives the BA from the HA.

      (c) The MN receives packets destined for PCoA from the link with
      LLA1 via the PAR.

      (d) When the MN detects that handover is imminent, it opens the
      interface with LLA2 and acquires the global IP address NCoA.

      (e) The MN inserts NCoA into the FBU and sends it with S=1 and N=0
      from the link with PCoA to the PAR.

      (f) The MN receives the FBack from the PAR.





Yokota & Dommety         Expires April 26, 2007                [Page 23]

Internet-Draft            3G CDMA Fast Handover             October 2006


      (g) The PAR sends packets destined for PCoA directly to the link
      with LLA1 and also forwards them to the NAR.  The forwarded
      packets are received by the MN on the link with NCoA.

      (h) When the MN is ready to use the link with LLA2 as the primary
      one, it sends the BU to the HA with S=0 and N=0.

      (i) The HA starts sending packets to NCoA.

   As shown in this example, since the NCoA is assigned on the link with
   LLA2 and the NAR has the neighbor cache entry (NCE) for the NCoA,
   there is no need to send the HI from the PAR.  To suppress sending
   the HI, a new flag 'N' is defined in the FBU.  Also, to indicate the
   PAR to bi-cast packets, a new flag 'S' is defined in the FBU.  If the
   MN requests selective bi-casting and the valid NCoA has been
   assigned, the MN SHOULD send the FBU to the PAR with the S flag set
   and the N flag unset requesting bi-casting but not sending the HI.
   If the PAR receives this FBU, it SHOULD not send the HI to the NAR.

        +..MN..+
       LLA1   LLA2            PAR                NAR                 HA
        |      |               |                  |                  |
        |link-layer connection |                  |                  |
   (a)  |/--------------------\|                  |                  |
        |\--------------------/|                  |                  |
        |      |               BU(S=0,N=0)/BA                        |
   (b)  |<---------------------------------------------------------->|
        |      |               |                  |                  |
   (c)  |<=====================|<====================================|
        |      |       link-layer connection      |                  |
   (d)  |      |/--------------------------------\|                  |
        |      |\--------------------------------/|                  |
        |     FBU(S=1,N=0)     |                  |                  |
   (e)  |--------------------->|                  |                  |
        |      | FBack         |                  |                  |
   (f)  |<---------------------|                  |                  |
        |      |               |                  |                  |
   (g)  |<====================#|<====================================|
        |      |              #=================>#|                  |
        |      |<================================#|                  |
        |      |               |                  |                  |
        |      |               BU(S=0,N=0)/BA     |                  |
   (h)  |      |<--------------------------------------------------->|
        :      |               |                  |                  |
   (i)  :      |<=================================|<=================|

                        Figure 9: Combination (A-1)




Yokota & Dommety         Expires April 26, 2007                [Page 24]

Internet-Draft            3G CDMA Fast Handover             October 2006


6.2  Bi-casting by the HA to the MN with multiple interfaces (A-2)

   This case happens when the access network where the PAR belongs and
   the one where the NAR belongs are administrated by different
   providers or are different access systems.  The cellular network is
   typically a closed network and the ARs can access external nodes only
   via the HA.  If this is the case, the PAR and the NAR cannot directly
   communicate with each other.  Details of the sequence of this case
   are shown in Figure 10 and below:

      (a) through (d) are the same as those in the case (A-1).

      (e) The MN sends the BU to the HA from the link with NCoA with S=1
      and N=0, which means that the MN requests the HA to bi-cast but
      not to send the HI.

      (f) The HA forwards packets destined for the MN to both the PAR
      and the NAR.  Those packets can be received by the MN on either
      one or both of the links.

      (g) When the bi-casting lifetime, which is defined in
      Section 6.5.4, is expired, packets are forwarded only to the NAR.


        +..MN..+
       LLA1   LLA2            PAR                NAR                 HA
        |      |               |                  |                  |
        |link-layer connection |                  |                  |
   (a)  |/--------------------\|                  |                  |
        |\--------------------/|                  |                  |
        |      |               BU(S=0,N=0)/BA     |                  |
   (b)  |<---------------------------------------------------------->|
        |      |               |                  |                  |
   (c)  |<=====================|<====================================|
        |      |       link-layer connection      |                  |
   (d)  |      |/--------------------------------\|                  |
        |      |\--------------------------------/|                  |
        |      |               |                  |                  |
        |      |                   BU(S=1,N=0)/BA                    |
   (e)  |      |<--------------------------------------------------->|
        |      |               |                  |                  |
   (f)  |<=====================|<====================================|
        |      |<=================================|<=================|
        :      |               |                  |                  |
   (g)  :      |<=================================|<=================|

                       Figure 10: Combination (A-2)




Yokota & Dommety         Expires April 26, 2007                [Page 25]

Internet-Draft            3G CDMA Fast Handover             October 2006


6.3  Bi-casting by the PAR to the MN with a single interface (B-1)

   This case is typical of handover with the same access system within
   the same provider network.  Details of the sequence of this case are
   shown in Figure 11 and below:

      (a) through (c) are the same as those in the case (A-1).

      (d) The MN sends the RtSolPr to the PAR.

      (e) The MN receives the PrRtAdv with a valid NCoA from the PAR.

      (f) The MN sends the FBU with S=1 and N=1 to the PAR.

      (g) The PAR sends the HI to the NAR.  The U flag in the HI MUST be
      set when requesting buffering at the NAR.

      (h) The PAR receives the HAck with a valid NCoA from the NAR.

      (i) The PAR sends the FBack both to the MN and the NAR.

      (j) The PAR sends packets destined for PCoA directly to the MN and
      also forwards them to the NAR.  The NAR buffers the received
      packets when the U flag in the HI is accepted.

      (k) The MN moves to the new access network and configures NCoA by
      establishing the link-layer connection.  At this point, the MN can
      receive the forwarded packets from the NAR.

      (l) The MN sends the FNA to the NAR.

      (m) The NAR starts sending the buffered packets to the MN.

      (n) The MN sends the BU with S=0 and N=0 to the HA.  The HA then
      returns the BA to the MN.

      (o) The MN starts receiving packets only via the NAR.

   In (g), it is necessary that the PAR sends the HI to the NAR to
   create the neighbor cache entry (NCE) for the NCoA on the NAR.  Also,
   by setting the U flag in the HI, the PAR requests buffering to the
   NAR.









Yokota & Dommety         Expires April 26, 2007                [Page 26]

Internet-Draft            3G CDMA Fast Handover             October 2006


       MN                     PAR                NAR                 HA
        |                      |                  |                  |
        |link-layer connection |                  |                  |
   (a)  |/--------------------\|                  |                  |
        |\--------------------/|                  |                  |
        |                      BU(S=0,N=0)/BA                        |
   (b)  |<---------------------------------------------------------->|
        |                      |                  |                  |
   (c)  |<=====================|<====================================|
        |       RtSoIPr        |                  |                  |
   (d)  |--------------------->|                  |                  |
        |       PrRtAdv        |                  |                  |
   (e)  |<---------------------|                  |                  |
        |     FBU(S=1,N=1)     |                  |                  |
   (f)  |--------------------->|                  |                  |
        |                      |      HI(U=1)     |                  |
   (g)  |                      |----------------->|                  |
        |  (new link)          |       HAck       |                  |
   (h)  |      |               |<-----------------|                  |
        |      |  FBAck        |       FBack      |                  |
   (i)  |<---------------------|----------------->|                  |
        |      |               |                  |                  |
   (j)  |<====================#|<====================================|
        |.....>|              #==================>|[buffering]       |
        :      |               |                  |                  |
        :      |       link-layer connection      |                  |
   (k)  :      |/--------------------------------\|                  |
        :      |\--------------------------------/|                  |
        :      |               FNA                |                  |
   (l)  :      |--------------------------------->|                  |
        :      |                                  |                  |
   (m)  :      |<=================================|                  |
        :      |               |  BU(S=0,N=0)/BA  |                  |
   (n)  :      |<--------------------------------------------------->|
        :      |               |                  |                  |
   (o)  :      |<=================================|<=================|

                       Figure 11: Combination (B-1)


6.4  Bi-casting by the HA to the MN with a single interface (B-2)

   This case is typical of handover with the same access system between
   different provider networks.  Details of the sequence of this case
   are shown in Figure 12 and below:

      (a) through (d) are the same as those in the case (B-1).




Yokota & Dommety         Expires April 26, 2007                [Page 27]

Internet-Draft            3G CDMA Fast Handover             October 2006


      (e) The MN receives the PrRtAdv without a valid NCoA from the PAR.

      (f) The MN sends the BU with S=1 and N=1 to the HA.  The BU MUST
      contain an alternate CoA set to the NCoA.

      (g) The HA sends the HI with U=1 to the NAR.  The MN's LLA may not
      be included in the HI if such information is not available at the
      HA.  If this is the case, the U flag in the HI MUST be set.

      (h) The HA receives the HAck from the NAR.

      (i) The HA sends the BA to the MN.

      (j) The HA sends packets destined for the MN to both the PAR and
      the NAR.  The NAR buffers them if the U flag in the HI is
      accepted.

      (k) The MN moves to the new access network and configures NCoA by
      establishing the link-layer connection.  At this point, the MN can
      receive the forwarded packets from the NAR.

      (l) The MN sends the FNA to the NAR.  If the NCE for NCoA is
      incomplete on the NAR, the NAR extracts the MN's LLA from the FNA
      and completes it.

      (m) The NAR starts sending the buffered packets to the MN.

      (n) The MN sends the BU to the HA with S=0 and N=0.  The HA then
      returns the BA to the MN.

      (o) The MN starts receiving packets only via the NAR.

   In (e), by receiving the PrRtAdv without a valid NCoA (the Code is
   typically 2), the MN judges that the PAR does not have information on
   the NAR or can not send the HI directly to the NAR.  Then the MN
   sends the BU to the HA.

   In (g), it is necessary that the HA sends the HI to the NAR to make
   the NCE for the NCoA on the NAR.












Yokota & Dommety         Expires April 26, 2007                [Page 28]

Internet-Draft            3G CDMA Fast Handover             October 2006


       MN                     PAR                NAR                 HA
        |                      |                  |                  |
        |link-layer connection |                  |                  |
   (a)  |/--------------------\|                  |                  |
        |\--------------------/|                  |                  |
        |                      BU(S=0,N=0)/BA                        |
   (b)  |<---------------------------------------------------------->|
        |                      |                  |                  |
   (c)  |<=====================|<====================================|
        |       RtSoIPr        |                  |                  |
   (d)  |--------------------->|                  |                  |
        |       PrRtAdv        |                  |                  |
   (e)  |<---------------------|                  |                  |
        |                      |  BU(S=1,N=1)     |                  |
   (f)  |----------------------------------------------------------->|
        |                      |                  |      HI(U=1)     |
   (g)  |                      |                  |<-----------------|
        |                      |                  |       HAck       |
   (h)  |  (new link)          |                  |----------------->|
        |      |               |      BA          |                  |
   (i)  |<-----------------------------------------------------------|
        |      |               |                  |                  |
   (j)  |<=====================|<====================================|
        |      |                       [buffering]|<=================|
        |.....>|       link-layer connection      |                  |
   (k)  :      |/--------------------------------\|                  |
        :      |\--------------------------------/|                  |
        :      |               FNA                |                  |
   (l)  :      |--------------------------------->|                  |
        :      |                                  |                  |
   (m)  :      |<=================================|                  |
        :      |               |  BU(S=0,N=0)/BA  |                  |
   (n)  :      |<--------------------------------------------------->|
        :      |               |                  |                  |
   (o)  :      |<=================================|<=================|

                       Figure 12: Combination (B-2)


6.5  Message Format

   New messages for handover are defined to support the network-
   controlled fast handover, where the NAR requests handover to the PAR
   by the assistance of the lower layer protocol.  Their parameter
   usages follow [3].  Also, new flags and option are defined to support
   selective bi-casting.





Yokota & Dommety         Expires April 26, 2007                [Page 29]

Internet-Draft            3G CDMA Fast Handover             October 2006


6.5.1  Handover Request (HReq)

   The Handover Request (HReq) is an ICMPv6 message sent by the NAR to
   the PAR to initiate the process of a MN's handover.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Subtype     |    Reserved   |          Identifier           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Options ...
       +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     The IP address of the NAR.

      Destination Address
                     The IP address of the PAR.

      Hop Limit      255.

      Authentication Header
                     The authentication header MUST be used when this
                     message is sent.

   ICMP Fields:

      Type           The Experimental Mobility Protocol Type.

      Code           0 (currently unused)

      Checksum       The ICMPv6 checksum.

      Subtype        6

      Reserved       MUST be set to zero by the sender and ignored by
                     the receiver.

      Identifier     MUST be set by the sender so replies can be matched
                     to this message.







Yokota & Dommety         Expires April 26, 2007                [Page 30]

Internet-Draft            3G CDMA Fast Handover             October 2006


   Valid Options:

      NVSE           A list of identifier(s) that the NAR requests to
                     the PAR during handover.  The detail format is
                     defined later (Section 6.5.7).


6.5.2  Handover Response (HRes)

   The Handover Response (HRes) is an ICMPv6 message sent by the PAR to
   the NAR as a reply to the Handover Request message.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Type      |     Code      |          Checksum             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Subtype     |I|  Reserved   |          Identifier           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Options ...
       +-+-+-+-+-+-+-+-+-+-+-+-

   IP Fields:

      Source Address
                     The IP address of the PAR.

      Destination Address
                     The IP address of the NAR.

      Hop Limit      255.

   ICMP Fields:

      Type           The Experimental Mobility Protocol Type.

      Code           0 (currently unused)

      Checksum       The ICMPv6 checksum.

      Subtype        7

      I flag         Indicates an immediate handover (1) or delayed
                     handover (0).  If this flag is set, the NAR MUST
                     immediately sends the BU to the HA when the NAR
                     receives an MN attachment indication from the N-AN.
                     If this flag is not set, the NAR MAY sends the BU
                     to the HA at any time after the NAR has sent the



Yokota & Dommety         Expires April 26, 2007                [Page 31]

Internet-Draft            3G CDMA Fast Handover             October 2006


                     Hack to the PAR.

      Reserved       MUST be set to zero by the sender and ignored by
                     the receiver.

      Identifier     MUST be set by the sender so replies can be matched
                     to this message.

   Valid Options:

      NVSE           A list of information that the NAR requested to the
                     PAR.  The detail format is defined later
                     (Section 6.5.7).


6.5.3  Simultaneous bindings flag and the HI message indication flag
       extensions to (F)BU message

   When the MN requests simultaneous bindings and bi-casting to the HA
   or the PAR, the MN sets the newly defined simultaneous bindings flag
   in the Binding Update (BU) [12] or FBU, respectively.  To suppress
   sending the HI when it is unnecessary, the HI message indication flag
   is defined in the (F)BU as well.

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|H|L|K|S|N|    Reserved       |            Lifetime           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   S:        Simultaneous bindings.  If the 'S' bit is set, the mobile
             node is requesting that the HA or the PAR retain its prior
             mobility bindings and bi-cast packets destined for the MN.

   N:        Indication to send the HI.  On the condition that the 'S'
             bit is set, if the 'N' bit is set, the receiver (the PAR or
             the HA) SHOULD send the HI to the NAR, otherwise the
             receiver SHOULD not send the HI.  If the 'S' bit is not
             set, the 'N' bit MUST be ignored.

   If the 'S' bit is supported, the 'N' MUST also be supported.  When
   S=0 and N=0, the AR and the HA perform according to [3] and [12],



Yokota & Dommety         Expires April 26, 2007                [Page 32]

Internet-Draft            3G CDMA Fast Handover             October 2006


   respectively (the default behavior).

6.5.4  New mobility option for bi-casting lifetime

   The MN may request how long the HA or the PAR should retain the
   simultaneous bindings (and therefore bi-casting) by attaching the
   following mobility option in the binding update message:

      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
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Type = T.B.D |   Length = 2  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Bi-casting Lifetime     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Bi-casting Lifetime:
             The time period when the PAR or the HA retains the previous
             CoA (PCoA).


6.5.5  New status code for simultaneous bindings

   If the AR or the HA receives more (fast) binding update messages with
   different CoAs for the same HoA than it can support, it should send a
   binding acknowledgement message with the following status code:

   Status   T.B.D.
        too many simultaneous mobility bindings


6.5.6  New Option for access-specific handover information

   If the lower layer information of the new point of attachment is not
   represented as the Link-Layer Address, the following option SHOULD be
   used.  The primary purpose of this option is to convey the handover
   assist information described in Section 4.

     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Type       |    Length     |  Option-Code  |   AS-Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           AS-Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Yokota & Dommety         Expires April 26, 2007                [Page 33]

Internet-Draft            3G CDMA Fast Handover             October 2006


   Type           T.B.D.

   Length         The size of this option in 8 octets including the
                  Type, Length, Option-Code and AS-Length fields.

   Option-Code    Indicates the particular type of access-specific
                  information.  This value is administrated by the
                  vendor or organization that uses this option.

   AS-Length      The size of the AS-Value field in octets.

   AS-Value       Zero or more octets of access-specific information
                  data.

   This option MUST be understood by the sender (typically the MN) and
   the receiver (typically the AR or the HA).  If nodes in between do
   not support this option, they SHOULD treat this option as opaque and
   MUST not drop it.

   Depending on the size of the AS-Value field, appropriate padding MUST
   be used to ensure that the entire option size is a multiple of 8
   octets.  The AS-Length is used to disambiguate the size of the AS-
   Value.

6.5.7  New Option for Vendor/Organization Specific Extensions

   This option is to convey vendor/organization specific information and
   its format follows [13].  Two Vendor/Organization Specific Extensions
   are described, Critical (CVSE) and Normal (NVSE) Vendor/Organization
   Specific Extensions.  This option is overlaid on the option format
   defined in Section 6.4 of RFC4068.  To distinguish two different
   formats, if the Type = 38 (CVSE-TYPE-NUMBER) or 124 (NVSE-TYPE-
   NUMBER), then the option format follows CVSE or NVSE, respectively in
   [13].

6.6  MN and AR/HA operations

   In order to enable bi-casting, the MN sends a BU or FBU by setting
   the 'S' flag to the HA or the PAR, respectively.  When the PAR/HA
   allows bi-casting, a successful (F)Back is returned and bi-casting is
   started.  The MN can request a desirable bi-casting lifetime to the
   PAR/HA with the bi-casting lifetime option in the (F)BU.  If the
   requested lifetime is acceptable, the PAR/HA sends an (F)Back with
   the accepted bi-casting lifetime, which is determined by the policies
   of the PAR/HA.  When bi-casting is performed at the HA, the MN is
   likely to receive duplicate packets from multiple interfaces.  In the
   case of audio or video applications, it may be necessary to
   synchronize the bi-cast flows coming from different access networks



Yokota & Dommety         Expires April 26, 2007                [Page 34]

Internet-Draft            3G CDMA Fast Handover             October 2006


   so that the user does not have to experience a communication
   disruption.  This may take longer than just the time for a handover.
   If this is the case, the MN may request a longer bi-cast lifetime.
   After the flows are synchronized and successfully switched on the
   application level, the MN may explicitly de-register the PCoA by
   sending an (F)BU with the lifetime field being zero.  On the side of
   the PAR/HA, the maximum value of the bi-casting lifetime must be
   configured and even if the MN does not request a bi-casting lifetime
   or does not successfully de-register the PCoA, it is deleted after
   the maximum value of the bi-casting lifetime elapses.









































Yokota & Dommety         Expires April 26, 2007                [Page 35]

Internet-Draft            3G CDMA Fast Handover             October 2006


7.  Security Considerations

   The security considerations for Mobile IPv6 fast handover are
   described in [3].  When a 3G network is considered, the PAR and the
   NAR have a trusting relationship and the links between them and those
   between the ARs and the MN are usually secured.  When the MN is
   authenticated at the phase of the link-layer connection, the AR can
   distinguish the authenticated users from the others.  This may not be
   the case, however, if the access networks are operated by different
   providers.

   When the network-controlled fast handover is applied, the HA and the
   ARs to which the MN is attached MUST have a trust relationship and
   the security information that is needed for the HA to authenticate
   the BU originated by the ARs MUST be transferred to those ARs in a
   secure manner.



































Yokota & Dommety         Expires April 26, 2007                [Page 36]

Internet-Draft            3G CDMA Fast Handover             October 2006


8.  Conclusions

   The handover performance of the standard Mobile IPv6 is not
   sufficient for real-time communications that are not resilient to
   packet loss.  The Mobile IPv6 fast handover methods are effective for
   these applications.  This document specifies how these methods can be
   applied to 3G networks.  By introducing fast handover, not only are
   more packets saved which otherwise would be dropped, but also some of
   the bootstrapping parameters can be omitted at the link establishment
   phase, which can expedite the handover process.  For interactive
   real-time applications, in which excessive buffering is
   inappropriate, selective bi-casting is also proposed.  By retaining
   the PCoA and the NCoA in the binding cache, packets destined for the
   MN are transmitted to both the old and new points of attachment at
   the same time, whereby the applications on the MN can choose which
   flow to adopt considering the media continuity.

9.  References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   3GPP2 TSG-A, "Interoperability Specification (IOS) for cdma2000
         Access Network Interfaces Part 1 Overview", A.S0011-C v.1.0,
         February 2005.

   [3]   Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068,
         July 2005.

   [4]   3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability
         Specification", A.S0001-A v.2.0, June 2001.

   [5]   3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
         Introduction", X.S0011-001-D v.1.0, February 2006.

   [6]   3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
         and Mobile IP services", X.S0011-002-D v.1.0, February 2006.

   [7]   Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.

   [8]   3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet
         Data Mobility and Resource Management", X.S0011-003-D v.1.0,
         February 2006.

   [9]   3GPP2 TSG-X, "Fast Handoff for HRPD", X.P0043 v.0.3, 2006.

   [10]  Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
         August 2002.



Yokota & Dommety         Expires April 26, 2007                [Page 37]

Internet-Draft            3G CDMA Fast Handover             October 2006


   [11]  Malki, K., "Simultaneous Bindings for Mobile IPv6 Fast
         Handovers",  draft-elmalki-mobileip-bicasting-v6-05.txt,
         October 2003.

   [12]  Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004.

   [13]  Dommety, G. and K. Leung, "Mobile IP Vendor/
         Organization-Specific Extensions", RFC 3775, April 2001.


Authors' Addresses

   Hidetoshi Yokota
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   JP

   Phone: +81 49 278 7894
   Fax:   +81 49 278 7510
   Email: yokota@kddilabs.jp


   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Phone: +1 408 525 1404
   Email: gdommety@cisco.com




















Yokota & Dommety         Expires April 26, 2007                [Page 38]

Internet-Draft            3G CDMA Fast Handover             October 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Yokota & Dommety         Expires April 26, 2007                [Page 39]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/