Network Working Group                                          H. Yokota
Internet-Draft                               KDDI R&D Laboratories, Inc.
Expires: January 11, 2006                                     G. Dommety
                                                     Cisco Systems, Inc.
                                                           July 10, 2005


            Mobile IPv6 Fast Handovers for 3G CDMA Networks
                    draft-yokota-mipshop-3gfh-00.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 January 11, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 provider networks.  However, this handover procedure requires
   not only movement detection, but also the acqusition 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 January 11, 2006                [Page 1]


Internet-Draft            3G CDMA Fast Handover                July 2005


   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 . . . . . . . . . . . . . . . . . . 12
     5.3   Impact on 3G network entities  . . . . . . . . . . . . . . 14
   6.  Selective bi-casting . . . . . . . . . . . . . . . . . . . . . 15
     6.1   Message Format . . . . . . . . . . . . . . . . . . . . . . 17
       6.1.1   Simultaneous bindings flag extension to (Fast)
               Binding update message . . . . . . . . . . . . . . . . 17
       6.1.2   New mobility option for bi-casting lifetime  . . . . . 17
       6.1.3   New status code for simultaneous bindings  . . . . . . 17
     6.2   MN and AR/HA operations  . . . . . . . . . . . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
       Intellectual Property and Copyright Statements . . . . . . . . 22























Yokota & Dommety        Expires January 11, 2006                [Page 2]


Internet-Draft            3G CDMA Fast Handover                July 2005


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 January 11, 2006                [Page 3]


Internet-Draft            3G CDMA Fast Handover                July 2005


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.  If the MN has more than two network
   interfaces, 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 defines a protocol for it.































Yokota & Dommety        Expires January 11, 2006                [Page 4]


Internet-Draft            3G CDMA Fast Handover                July 2005


3.  Terminology

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

   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.





































Yokota & Dommety        Expires January 11, 2006                [Page 5]


Internet-Draft            3G CDMA Fast Handover                July 2005


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 around the access provider
   networks.  The home network and the access provider networks are
   managed by either the same or different operator(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 access provider
   network to another, a Mobile IPv6 handover is performed.  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 oPSDN (old PDSN)
   and the nPDSN (new PDSN).






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

                  Figure 1: Reference Model for Mobile IP



Yokota & Dommety        Expires January 11, 2006                [Page 6]


Internet-Draft            3G CDMA Fast Handover                July 2005


   In 3G networks, pilot signals from BSs allow the MN to obtain a rapid
   and accurate C/I (carrier to interference) estimate.  The MN measures
   the channel C/I from all the measurable pilot channels and requests a
   connection to the BS with the strongest pilot channel.  If this
   physical layer information such as the channel C/I can be used as a
   trigger for the handover of access routers when the MN is about to
   move to a new access provider network, faster and smoother handover
   of Mobile IPv6 can be realized.

   Figure 2 shows the protocol sequence from the attachment to the
   network to th Mobile IPv6 registration.  The MN first establishes a
   link-layer connection between itself and the access router.  As the
   link-layer protocol, PPP or RLP (Radio Link Protocol) 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 [5],
   where the bootstrapping information is obtained during the link-layer
   establishment phase.





























Yokota & Dommety        Expires January 11, 2006                [Page 7]


Internet-Draft            3G CDMA Fast Handover                July 2005


                 MN                     AR             HA            AAA
        +--      |                    (PDSN)           |              |
        |        |         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) | 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 authentication for instance is conducted.

      (a-3) The bootstrapping parameters are conveyed from the HA and
      stored in the AR (PDSN).

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




Yokota & Dommety        Expires January 11, 2006                [Page 8]


Internet-Draft            3G CDMA Fast Handover                July 2005


      (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 home agent address, the home link prefix and the home address.

      (a-9) The MN configures its HoA based on the obtained parameters.

      (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 January 11, 2006                [Page 9]


Internet-Draft            3G CDMA Fast Handover                July 2005


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 is indicated
   sufficiently before the time it actually happens.  In cellular
   systems, handovers are controlled by the network and the predictive
   mode is well applied although the reactive mode is possible as well.
   On the other hand, in wireless LAN networks, for example, the MN
   controls its handover and it does not know where it moves to until it
   starts to scan the channels.  In this case, only the reactive mode is
   applied.

5.1  Predictive fast handover

   Figure 3 shows the predictive mode of MIPv6 fast handover operation.
   The MN knows the NAR before movement and has the PAR transfer the
   packets destined for the MN to the NAR.  Details of the sequence are
   as follows:

      (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 to the NAR and the NAR
      buffers them.

      (f) The MN hands over to the NAR.

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

      (h) The MN sends the fast neighbor advertisement.

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




Yokota & Dommety        Expires January 11, 2006               [Page 10]


Internet-Draft            3G CDMA Fast Handover                July 2005


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

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

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


         MN            PAR             NAR            HA             AAA
         |    RtSolPr   |               |              |              |
    (a)  |------------->|               |              |              |
         |    PrRtAdv   |               |              |              |
    (b)  |<-------------|               |              |              |
         |      FBU     |      Hl       |              |              |
    (c)  |------------->|-------------->|              |              |
         |     FBack    |     HAck      |              |              |
    (d)  |<-------------|<--------------|              |              |
         |              |forward packets|              |              |
    (e)  |              |==============>|              |              |
         |              |         +-----------+        |              |
         |              |         | buffering |        |              |
         |              |         +-----------+        |              |
    (f) handover        |               |              |              |
         |              | link layer connection        |              |
    (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 address can be resolved before handover by
   the BS-ID, which is obtained from the air link information.  The
   tunnel between the PAR and the NAR will be released after a
   preconfigured time.

   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 the reactive mode.  Regarding the bootstrapping,
   the following benefits can be obtained, too:



Yokota & Dommety        Expires January 11, 2006               [Page 11]


Internet-Draft            3G CDMA Fast Handover                July 2005


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

   o  Since the NCoA 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) and
   (a-6) 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.

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

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


5.2  Reactive fast handover




Yokota & Dommety        Expires January 11, 2006               [Page 12]


Internet-Draft            3G CDMA Fast Handover                July 2005


   In the reactive mode, packets on the fly destined for the MN are not
   saved by buffering at the NAR, but those within the period from the
   time when the MN becomes IP reachable on the new access network to
   the time when the MN finishes registering the new location with the
   HA are saved.  Details of the procedure are as follows:

      (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 hands over to the NAR.

      (d) The MN establishes the link layer connection with/without
      authentication.

      (e) The MN sends the Fast Neighbor Advertisement (FNA) with the
      Fast Binding Update (FBU) to the PAN.

      (f) The NAR extracts the FBU and sends it to the PAR.

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

      (h) The PAR starts forwarding packets to the NAR.

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

      (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.


















Yokota & Dommety        Expires January 11, 2006               [Page 13]


Internet-Draft            3G CDMA Fast Handover                July 2005


         MN           oPDSN           nPDSN            HA            AAA
         |            (PAR)           (NAR)            |              |
         |   RtSolPr    |               |              |              |
    (a)  |------------->|               |              |              |
         |   PrRtAdv    |               |              |              |
    (b)  |<-------------|               |              |              |
         |              |               |              |              |
    (c) handover        |               |              |              |
         |              | link layer connection        |              |
    (d)  |/----------------------------\|/...........................\|
         |\----------------------------/|\.........................../|
         |          FNA [FBU]           |              |              |
    (e)  |----------------------------->|              |              |
         |              |      FBU      |              |              |
    (f)  |              |<--------------|              |              |
         |              |     FBack     |              |              |
    (g)  |              |-------------->|              |              |
         |              |forward packets|              |              |
    (h)  |              |==============>|              |              |
         |        deliver packets       |              |              |
    (i)  |<=============================|              |              |
         |              |    BU         |              |              |
    (j)  |-------------------------------------------->|              |
         |              |    BA         |              |              |
    (k)  |<--------------------------------------------|              |
         |        deliver packets       |              |              |
    (l)  |<=============================|<=============|              |

          Figure 5: MIPv6 Fast handover operation (reactive mode)

   An L2-based fast handover is possible as defined in [6] by extending
   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 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  Impact on 3G network entities

   Amongst existing 3G network entities, the MN and PDSNs are required
   to support fast handover procedures.  The MN is also required to
   leverage the channel C/I to estimate the timing of handover in the
   predictive fast handover mode.



Yokota & Dommety        Expires January 11, 2006               [Page 14]


Internet-Draft            3G CDMA Fast Handover                July 2005


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 such as 3G and WiFi.  Especially, when the MN
   is running a real-time and interactive application, long-time
   buffering at the 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.  Mobile IPv4 allows simultaneous bindings [7] 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 6 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.  This type of scenario was originally proposed in [8].  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.  Note that even if this is the case, it may be effective
   when the MN moves back and forth between the old and new points of
   attachment, the so-called "ping-pong" situation.  The timing when the
   selective bi-casting is conducted is shown in Figure 3 (e) or
   Figure 5 (h) without buffering in the proactive or reactive fast
   handover, respectively.  As another scenario, Figure 7 shows that
   simultaneous bindings are performed at the HA.  This scenario is
   likely to happen when the MN are connected to multiple different
   networks such as 3G and WiFi 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 January 11, 2006               [Page 15]


Internet-Draft            3G CDMA Fast Handover                July 2005


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

                 Figure 6: Selective bi-casting scenario 1


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

                 Figure 7: Selective bi-casting scenario 2







Yokota & Dommety        Expires January 11, 2006               [Page 16]


Internet-Draft            3G CDMA Fast Handover                July 2005


6.1  Message Format

6.1.1  Simultaneous bindings flag extension to (Fast) Binding update
       message

   When the MN requests simultaneous bindings to the HA or the PAR, the
   MN sets the newly defined simultaneous bindings flag in the Binding
   Update (BU) [9] or FBU, respectively.

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |A|H|L|K|S|      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, as described below.


6.1.2  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.1.3  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



Yokota & Dommety        Expires January 11, 2006               [Page 17]


Internet-Draft            3G CDMA Fast Handover                July 2005


   binding acknowledgement message with the following status code:

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


6.2  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
   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 January 11, 2006               [Page 18]


Internet-Draft            3G CDMA Fast Handover                July 2005


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 be not
   the case, however, if the access networks are operated by different
   providers.









































Yokota & Dommety        Expires January 11, 2006               [Page 19]


Internet-Draft            3G CDMA Fast Handover                July 2005


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",
         draft-ietf-mipshop-fast-mipv6-02.txt, July 2004.

   [4]  3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
        Introduction", X.P0011-001-D v.0.5, November 2004.

   [5]  3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
        and Mobile IP services", X.P0011-002-D v.0.5, November 2004.

   [6]  3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet Data
        Mobility and Resource Management", X.P0011-003-D v.0.5,
        November 2004.

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

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

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




Yokota & Dommety        Expires January 11, 2006               [Page 20]


Internet-Draft            3G CDMA Fast Handover                July 2005


Authors' Addresses

   Yokota Hidetoshi
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara, Kamifukuoka
   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 January 11, 2006               [Page 21]


Internet-Draft            3G CDMA Fast Handover                July 2005


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 (2005).  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 January 11, 2006               [Page 22]