Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Standards Track                            K. Chowdhury
Expires: August 29, 2008                                Starent Networks
                                                               R. Koodli
                                                                B. Patil
                                                  Nokia Siemens Networks
                                                                  F. Xia
                                                              Huawei USA
                                                       February 26, 2008


                       Fast Handovers for PMIPv6
                  draft-yokota-mipshop-pfmipv6-02.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 August 29, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).








Yokota, et al.           Expires August 29, 2008                [Page 1]


Internet-Draft          Proxy-based Fast Handover          February 2008


Abstract

   This document specifies the usage of FMIPv6 when Proxy Mobile IPv6 is
   applied for the mobility management protocol.  Necessary amendments
   are shown for FMIPv6 to work under the condition that the mobile node
   does not have IP mobility functionality and it is not involved with
   either MIPv6 or FMIPv6 operations.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . .  7
     4.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Handoff Type Considerations  . . . . . . . . . . . . . . . 13
     4.3.  IPv4 Support Considerations  . . . . . . . . . . . . . . . 14
   5.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . . . 15
     5.2.  Handover Acknowledge (HAck)  . . . . . . . . . . . . . . . 16
     5.3.  Context Request Option . . . . . . . . . . . . . . . . . . 18
     5.4.  Tunnel-ID Option . . . . . . . . . . . . . . . . . . . . . 19
     5.5.  Mobile Node Interface Identifier (MN IID) Option . . . . . 19
     5.6.  New option-code for the IP Address Option  . . . . . . . . 20
     5.7.  IPv4 Address Option  . . . . . . . . . . . . . . . . . . . 20
     5.8.  Vendor Specific Option . . . . . . . . . . . . . . . . . . 21
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26


















Yokota, et al.           Expires August 29, 2008                [Page 2]


Internet-Draft          Proxy-based Fast Handover          February 2008


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, et al.           Expires August 29, 2008                [Page 3]


Internet-Draft          Proxy-based Fast Handover          February 2008


2.  Introduction

   Proxy Mobile IPv6 [2] provides IP mobility to a mobile node that does
   not have Mobile IPv6 [4] functionality.  The proxy agent in the
   network performs the signaling and does the mobility management on
   behalf of the mobile node.  Although the signaling between the mobile
   node and the network can be saved, the basic performance for handover
   such as handover latency is considered to be not different from that
   of Mobile IPv6.

   To improve handover latency due to Mobile IPv6 procedures, fast
   handovers for MIPv6 is specified in FMIPv6[3].  By applying the
   FMIPv6 solution to Proxy MIPv6 as well, it is expected that the
   handover latency due to Proxy MIPv6 procedures will be improved as
   much.  However, Mobile IPv6 and Proxy MIPv6 are intrinsically
   different in the sense that the mobile node is not involved with IP
   mobility and hence does not directly handle the care-of address.
   Hence, there are some issues in directly applying the original
   specifications of FMIPv6 to Proxy MIPv6.  This document identifies
   those differences and specifies amendments to apply FMIPv6 solution
   principles to Proxy MIPv6.






























Yokota, et al.           Expires August 29, 2008                [Page 4]


Internet-Draft          Proxy-based Fast Handover          February 2008


3.  Terminology

   This document refers to [2][3][4] for terminology.  The following
   terms and abbreviations are additionally used in this document.  The
   reference network is illustrated in Figure 1.

   Previous Access Network (P-AN):
        The access network to which the MN is attached before handover.

   New Access Network (N-AN):
        The access network to which the MN is attached after handover.

   Previous Mobile Access Gateway (PMAG):
        The MAG that manages mobility related signaling for the MN
        before handover.  In this document, the MAG and the Access
        Router (AR) are collocated.

   New Mobile Access Gateway (NMAG):
        The MAG that manages mobility related signaling for the MN after
        handover.

   HO-Initiate:
        A generic signaling that indicates the handover of the MN sent
        from the P-AN to the PMAG.  While this signaling is dependent on
        the access technology, it is assumed that HO-Initiate can carry
        the information to specify the MN and to help the PAR resolve
        the NAR (e.g. the new access point or base station to which the
        MN is moving to).























Yokota, et al.           Expires August 29, 2008                [Page 5]


Internet-Draft          Proxy-based Fast Handover          February 2008


                                  +----------+
                                  |   LMA    |
                                  |          |
                                  +----------+
                                    /      \
                                   /        \
                                  /          \
                      +........../..+      +..\..........+
                      . +-------+-+ .______. +-+-------+ .
                      . |   PAR   |()_______)|   NAR   | .
                      . |  (PMAG) | .      . |  (NMAG) | .
                      . +----+----+ .      . +----+----+ .
                      .      |      .      .      |      .
                      .   ___|___   .      .   ___|___   .
                      .  /       \  .      .  /       \  .
                      . (  P-AN   ) .      . (  N-AN   ) .
                      .  \_______/  .      .  \_______/  .
                      .      |      .      .      |      .
                      .   +----+    .      .   +----+    .
                      .   | MN |  ---------->  | MN |    .
                      .   +----+    .      .   +----+    .
                      +.............+      +.............+

               Figure 1: Reference network for fast handover



























Yokota, et al.           Expires August 29, 2008                [Page 6]


Internet-Draft          Proxy-based Fast Handover          February 2008


4.  Proxy-based FMIPv6 Protocol Overview

   To reduce the handover latency due to signaling between the MAGs
   (Mobile Access Gateways) and the LMA (Local Mobility Anchor), FMIPv6
   in this document specifies a bi-directional tunnel between the
   Previous MAG (PMAG) and the New MAG (NMAG).  To expedite sending the
   Proxy Binding Update (PBU) by the NMAG, FMIPv6 protocol is also used
   for context transfer, whereby the necessary information for sending
   the PBU is transferred from the PMAG.

   In this document, the Previous Access Router (PAR) and New Access
   Router (NAR) are interchangeable with the PMAG and NMAG,
   respectively.

   Since the MN is not directly involved with IP mobility, it is natural
   to think that the MN is not directly involved with fast handover
   procedures, either at least from the IP layer perspective.
   Therefore, among the messages for fast handovers defined in [3],
   those that are initiated by and targeted to the MN are not used when
   PMIPv6 is in use.  Such messages are the Router Solicitation for
   Proxy Advertisement (RtSolPr), Proxy Router Advertisement (PrRtAdv),
   Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and
   Unsolicited Neighbor Advertisement (UNA).

4.1.  Protocol Operation

   FMIPv6 [3] specifies two types of fast handovers; the predictive fast
   handover and the reactive fast handover.  In the predictive fast
   handover, the MN sends the FBU to the PAR before handover, which then
   triggers to establish a bi-directional tunnel between the PAR and NAR
   to transfer packets for the MN.  On the other hand, in the reactive
   fast handover, the FBU is sent by the MN to the NAR after it has
   moved to the new network, which is then transferred to the PAR to
   trigger to send the Handover Initiate (HI) towards the NAR.  Based on
   the above observations, the fast handover procedures for PMIPv6 need
   to work without the involvement of the MN.  Figure 2 illustrates the
   predictive fast handover procedures for PMIPv6, where the bi-
   directional tunnel establishment is initiated by the PAR.













Yokota, et al.           Expires August 29, 2008                [Page 7]


Internet-Draft          Proxy-based Fast Handover          February 2008


                                            PMAG        NMAG
          MN         P-AN       N-AN        (PAR)       (NAR)     LMA
          |           |          |            |           |        |
          |  Report   |          |            |           |        |
     (a)  |-(MN ID,-->|          |            |           |        |
          | New AP ID)|          |            |           |        |
          |           |     HO Initiate       |           |        |
     (b)  |           |--(MN ID, New AP ID)-->|           |        |
          |           |          |            |           |        |
          |           |          |            |    HI     |        |
     (c)  |           |          |            |-(MN ID, ->|        |
          |           |          |          MN-HoA,MN IID,LMA)     |
          |           |          |            |           |        |
     (d)  |           |          |            |<---HAck---|        |
          |           |          |            |  (MN ID)  |        |
          |           |          |            |           |        |
          |           |          |            |  HI/HAck  |        |
     (e)  |           |          |            |<--------->|        |
     (f)  |           |          |            |==DL data=>|        |
          |           |          |            |           |        |
     (g) ~~~          |          |            |           |        |
         ~~~          |          |            |           |        |
          |   MN-AN connection   |    AN-MAG connection   |        |
     (h)  |<---establishment---->|<----establishment----->|        |
          |           |          |  (substitute for UNA)  |        |
          |           |          |            |           |        |
     (i)  |<==================DL data=====================|        |
          |           |          |            |           |        |
     (j)  |===================UL data====================>|#       |
          |           |          |           #|<==========|#       |
          |           |          |           #|===================>|
          |           |          |            |  HI/HAck  |        |
     (k)  |           |          |            |<--------->|        |
     /    |           |          |            |           |        | \
     |(l) |           |          |            |           |--PBU-->| |
     |    |           |          |            |           |        | |
     |(m) |           |          |            |           |<--PBA--| |
     \    |           |          |            |           |        | /

       Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)

   The detailed descriptions are as follows:

   (a)  The MN detects that a handover is imminent and reports the
        identifications of itself (MN ID) and the access point (New AP
        ID) to which the MN is most likely to move.  These IDs can be
        Link-Layer Addresses (LLAs) or any other types of IDs.  This
        step is access technology specific.  In some cases, the P-AN



Yokota, et al.           Expires August 29, 2008                [Page 8]


Internet-Draft          Proxy-based Fast Handover          February 2008


        will figure out which AP ID the MN is moving to.

   (b)  The previous access network (P-AN), to which the MN is currently
        attached, indicates the handover of the MN to the PAR (PMAG).

   (c)  The PAR sends the HI to the NAR.  The HI message MUST include
        the MN ID and SHOULD include the MN-HoA, the MN-IID and the
        address of the LMA that is currently serving the MN.

   (d)  The NAR sends back the Hack to the PAR.

   (e)  The NAR requests the PAR to buffer or forward packets by setting
        U or F flags in the HI message, respectively.

   (f)  If F flag is set in the HI at the previous step, a bi-
        directional tunnel is established between the PAR and NAR and
        packets destined for the MN are forwarded from the PAR to the
        NAR over this tunnel.  After detunneling, those packets may be
        buffered at the NAR.  If the connection between the N-AN and NAR
        has already been established, those packet may reach the N-AN
        (access technology specific).

   (g)  The MN hands over to the New Access Network (N-AN).

   (h)  The MN establishes a connection (e.g. radio channel) with the
        N-AN, which in turn triggers the establishment of the connection
        between the N-AN and NAR if it has not been established, yet
        (access technology specific).  This can be regarded as a
        substitute for the UNA.

   (i)  The NAR starts to transfer packets destined for the MN via the
        N-AN.

   (j)  The uplink packets from the MN are sent to the NAR via the N-AN
        and the NAR forwards them to the PAR.  The PAR then sends the
        packets to the LMA that is currently serving the MN.

   (k)  The PAR MAY send the HI message to indicate that the packet
        forwarding is completed.

   (l)  The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
        whose address can be obtained in (c).  Steps (l) and (m) are not
        part of the fast handover procedure, but shown for reference.

   (m)  The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
        NAR (NMAG).  From this time on, the packets to/from the MN go
        through the NAR instead of the PAR.




Yokota, et al.           Expires August 29, 2008                [Page 9]


Internet-Draft          Proxy-based Fast Handover          February 2008


   According to Section 4 of [3], the PAR establishes a binding between
   the PCoA and NCoA to forward packets for the MN to the NAR, and the
   NAR creates a proxy NCE to receive those packets for the NCoA before
   the MN arrives.  In the case of PMIPv6, however, the only address
   that is used by the MN is MN-HoA, so the PAR transfers the packets
   for the MN to the NAR instead of the NCoA.  The NAR then simply
   detunnels (decapsulates) those packets and delivers them to the MN.
   If the NAR obtains the LLA (=MN ID) and MN-HoA by the HI, it can
   create the NCE for the MN and deliver packets to it before the MN
   performs the ND.  For the uplink packets from the MN after handover
   in (j), the NAR forwards the packets to the PAR through the tunnel
   established in step (f).  The PAR then decapsulates and sends them to
   the LMA.

   The timing of the context transfer and that of packet forwarding may
   be different.  Thus, a new flag 'F' and the Option Code values for it
   in the HI message are defined to request forwarding.  To request
   buffering, 'U' flag has already been defined in [3].  If the PAR
   receives the HI message with F flag set and the Option Code value
   being 2, it starts forwarding packets for the MN.  The HI message
   with U flag set may be sent earlier if the timing of buffering is
   different from that of forwarding.  If packet forwarding is
   completed, the PAR MAY send the HI message with F flag set and the
   Option Code value being 3.  By this message, the ARs on both ends can
   tear down the forwarding tunnel synchronously.

   The IP addresses in the headers of those user packets are summarized
   below:

   In (f),

        Inner source address: IP address of the CN

        Inner destination address: MN-HoA

        Outer source address: IP address of the PAR (PMAG)

        Outer destination address: IP address of the NAR (NMAG)

   In (i),

        Source address: MN-HoA

        Destination address: IP address of the CN

   In (j),

   - from the MN to the NMAG,



Yokota, et al.           Expires August 29, 2008               [Page 10]


Internet-Draft          Proxy-based Fast Handover          February 2008


        Source address: MN-HoA

        Destination address: IP address of the CN

   - from the NMAG to the PMAG,

        Inner source address: MN-HoA

        Inner destination address: IP address of the CN

        Outer source address: IP address of the NAR (NMAG)

        Outer destination address: IP address of the LMA

   - from the PMAG to the LMA,

        Inner source address: MN-HoA

        Inner destination address: IP address of the CN

        Outer source address: IP address of the PAR (PMAG)

        Outer destination address: IP address of the LMA

   If the network that the MN has moved in does not support PMIPv6 but
   only MIPv6 (i.e. there exists a MIPv6 HA) and the MN supports MIPv6
   at the same time, the MN and HA can exchange BU/BA instead of PBU/PBA
   in steps (j) and (k).  If this is the case, the LMA and HA will most
   likely be collocated and the LMA (HA) address should be maintained in
   the new network for communication continuity.  Since the LMA (HA)
   address is transferred to the NAR in step (c), the MN can retrieve it
   at or after step (g) by e.g. the authentication or DHCP procedure
   (not shown in the figure).

   In the case of the reactive handover for PMIPv6, since the MN does
   not send either the FBU or UNA, it would be more natural that the NAR
   sends the HI to the PAR after the MN has moved to the new network.
   Figure 3 illustrates the reactive fast handover procedures for
   PMIPv6, where the bi-directional tunnel establishment is initiated by
   the NAR.











Yokota, et al.           Expires August 29, 2008               [Page 11]


Internet-Draft          Proxy-based Fast Handover          February 2008


                                         PMAG            NMAG
          MN       P-AN      N-AN        (PAR)           (NAR)     LMA
          |         |         |            |               |        |
     (a) ~~~        |         |            |               |        |
         ~~~        |         |            |               |        |
          |  MN-AN connection |       AN-MAG connection    |        |
     (b)  |<--establishment-->|<-------establishment------>|        |
          |      (MN ID)      |           (MN ID)          |        |
          |         |         |(substitute for UNA and FBU)|        |
          |         |         |            |               |        |
          |         |         |            |      HI       |        |
     (c)  |         |         |            |<---(MN ID) ---|        |
          |         |         |            |               |        |
          |         |         |            |     HAck      |        |
     (d)  |         |         |            |---(MN ID, --->|        |
          |         |         |            MN-HoA,MN IID,LMA)       |
          |         |         |            |               |        |
     (e)  |         |         |            |===DL data====>|#       |
          |<====================DL data====================|#       |
          |         |         |            |               |        |
     (f)  |=====================UL data===================>|#       |
          |         |         |          #=|<==============|#       |
          |         |         |          #=|=======================>|
     (g)  |         |         |            |<---HI/HAck--->|        |
          |         |         |            |               |        |
     /    |         |         |            |               |        | \
     |(h) |         |         |            |               |--PBU-->| |
     |    |         |         |            |               |        | |
     |(i) |         |         |            |               |<--PBA--| |
     \    |         |         |            |               |        | /



        Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)

   The detailed descriptions are as follows:

   (a)  The MN hands over from the P-AN to the N-AN.

   (b)  The MN establishes a connection (e.g. radio channel) with the
        N-AN, which triggers the establishment of the connection between
        the N-AN and NAR.  The MN ID is transferred to the NAR for the
        subsequent procedures.  This can be regarded as a substitute for
        the UNA and FBU.







Yokota, et al.           Expires August 29, 2008               [Page 12]


Internet-Draft          Proxy-based Fast Handover          February 2008


   (c)  The NAR sends the HI to the PAR.  The HI message MUST include
        the MN ID.  The Context Request Option MAY be included to
        request additional context information on the MN to the PAR.

   (d)  The PAR sends back the HAck to the NAR.  The HAck message MUST
        include the MN-HoA that is corresponding to the MN ID in the HI
        message and SHOULD include the MN-IID and the LMA address that
        is currently serving the MN.  The context information requested
        by the NAR MUST be included.

   (e)  If F flag in the HI is set, a bi-directional tunnel is
        established between the PAR and NAR and packets destined for the
        MN are transferred from the PAR to the NAR over this tunnel.
        After detunneling, those packets are delivered to the MN via the
        N-AN.

   (f)  The uplink packets from the MN are sent to the NAR via the N-AN
        and the NAR forwards them to the PAR.  The PAR then sends the
        packets to the LMA that is currently serving the MN.

   (g)  The PAR MAY send the HI message to indicate that the packet
        forwarding is completed.

   Steps (h)-(i) are the same as (l)-(m) in the predictive fast handover
   procedures.

   In step (c), The IP address of the PAR needs to be resolved by the
   NAR to send the HI to the PAR.  This information may come from the
   N-AN or some database that the NAR can access.

   Also, in step (c), the NAR could send an unsolicited HAck message to
   the PAR, which then triggers the HI message from the PAR.  By doing
   so, the directions of HI/HAck messages are aligned with the
   predictive (PAR-initiated) fast handover.  Further study is needed if
   this call flow is more appropriate than the current one.

4.2.  Handoff Type Considerations

   PMIPv6 [2] defines the Handoff Indicator Option and describes the
   type of the handoff and the values to set to the option.  This
   document proposes one approach to determining the handoff type.

   According to [2], the following handoff types are defined:

      0) Reserved

      1) Attachment over a new interface




Yokota, et al.           Expires August 29, 2008               [Page 13]


Internet-Draft          Proxy-based Fast Handover          February 2008


      2) Handoff between two different interfaces of the mobile node

      3) Handoff between mobile access gateways for the same interface

      4) Handoff state unknown

      5) Handoff state not changed (Re-registration)

   By using the MN Interface Identification (MN IID) option, which is
   defined in this document, the following solution can be considered.
   When the NMAG receives the MN IID used in the P-AN from the PMAG via
   the HI or HAck messages, the NMAG compares it with the new MN IID
   that is obtained from the MN in the N-AN.  If these two MN IIDs are
   the same, the handover type falls into 3) and the Handoff Indicator
   value is set to 3.  If these two MN IIDs are different, the handover
   is likely to be 2) since the HI/HAck message exchange implies that
   this is a handover not a multi-homing, therefore the Handoff
   Indicator value can be set to 2.  If there is no HI/Hack exchange
   performed prior to the network attachment of the MN in the new
   network, the NMAG may infer that this is a multi-homing case and set
   the Handoff Indicator value to 1.  In the case of re-registration,
   the MAG, to which the MN is attached, can determine if the handoff
   state is not changed, so the MAG can set the HI value to 5 without
   any additional information.  If none of them can be assumed, the NMAG
   may set the value to 4.

4.3.  IPv4 Support Considerations

   The motivation and usage scenarios of IPv4 protocol support by PMIPv6
   are described in [5].  The scope of IPv4 support covers the following
   two features:

   o  IPv4 Home Address Mobility Support, and

   o  IPv4 Transport Support.

   As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
   Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
   transfer IPv4-MH-HoA to the NMAG, which is the inner destination
   address of the downlink forwarded packets.  To this end, a new option
   called IPv4 Address Option is defined in this document.  As for IPv4
   Transport Support, the NMAG needs to know the IPv4 address of the LMA
   (IPv4-LMAA) to send PMIPv6 signaling messages to the LMA in the IPv4
   transport network.  The above IPv4 Address Option is defined so as to
   be able to convey IPv4-LMAA.  The details of this option are
   described in Section 5.7.





Yokota, et al.           Expires August 29, 2008               [Page 14]


Internet-Draft          Proxy-based Fast Handover          February 2008


5.  Message Format

   This document extends the HI and HAck to work with PMIPv6 and further
   defines new options and option-codes for the IP Address option to
   convey context information.

5.1.  Handover Initiate (HI)


      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    |S|U|P|F|Resv'd |           Identifier          |
     +---------------+-+-+-+-+-------+-------------------------------+
     |    Options ...
     +-------------------------

   IP Fields:

   Source Address

                       The IP address of PAR or NAR

   Destination Address

                       The IP address of the peer AR

             All the other fields follow [3].

   ICMP Fields:

   Code      If P flag is not set, the Code value follows [3].  If P
             flag is set but F flag is not set, the Code MUST be set to
             zero.  If both P flag and F flag are set, the Code value
             has the following meaning:

                       0, 1: See [3].

                       2: Request forwarding

                       3: Indicate the completion of forwarding








Yokota, et al.           Expires August 29, 2008               [Page 15]


Internet-Draft          Proxy-based Fast Handover          February 2008


   S flag    not used when P flag is set and MUST be set to zero.

   U flag    Buffer flag.  Same as [3].

   P flag    Proxy flag.  When set, PMIPv6 instead of MIPv6 is assumed
             for the mobility management protocol.  All the involved
             nodes MUST perform based on this document for fast handover
             procedures.

   F flag    Forwarding flag.  Used to request to forward the packets
             for the MN.

   All the other fields follow [3].

   Valid options:

   MN ID     This identifier can be the link-layer address of the MN or
             any other type of information that can uniquely identify
             the MN.  If the link-layer address is used as the MN ID,
             the Link-Layer Address (LLA) option defined in [3] MUST be
             used.

   MN-HoA    This information is stored in the IP Address option.

   MN-IID    This information is stored in the MN Interface Identifier
             option.

   Context Request Option  Context Request Option This option is used to
             request context information typically by the NAR to the PAR
             in the NAR-initiated fast handover.

5.2.  Handover Acknowledge (HAck)


      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    |P|  Reserved  |            Identifier          |
      +--------------+-+------------+--------------------------------+
      |    Options ...
      +------------------------

   IP Fields:






Yokota, et al.           Expires August 29, 2008               [Page 16]


Internet-Draft          Proxy-based Fast Handover          February 2008


   Source Address

                       Copied from the destination address of the
                       Handover Initiate message to which this message
                       is a response.

   Destination Address

                       Copied from the source address of the Handover
                       Initiate message to which this message is a
                       response.

             All the other fields follow [3].

   ICMP Fields:

   Code:

                       0: Handover Accepted

                       5: Context Transferred successfully, more context
                       available

                       6: Context Transferred successfully, no more
                       context available

                       128: Handover Not Accepted

                       129: Administratively prohibited

                       130: Insufficient resources

                       131: No context available

                       132: Forwarding Not Available

   P flag    Proxy flag.  When set, PMIPv6 instead of MIPv6 is assumed
             for the mobility management protocol.  All the involved
             nodes MUST perform based on this document for fast handover
             procedures.

   Valid options:

   MN ID     Copied from the corresponding HI message.







Yokota, et al.           Expires August 29, 2008               [Page 17]


Internet-Draft          Proxy-based Fast Handover          February 2008


   MN-HoA    Stored in the IP Address option so that the NAR can use
             this address for the PBU.

   MN-IID    This information is stored in the MN Interface Identifier
             option.

   LMA       Stored in the IP Address option so that the NAR can use
             this address for the PBU.

   Requested option(s)  All the other context information requested by
             the Context Request Option in the HI message.

5.3.  Context Request Option

   This option is sent in the HI message to request context information
   on the MN.

      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  |    Reserved   |
     +---------------------------------------------------------------+
     |                           Reserved                            |
     +---------------+---------------+-------------------------------+
     |  Req-type-1   |  Req-option-1 |            Padding            |
     +---------------------------------------------------------------+
     |                             Padding                           |
     +---------------------------------------------------------------+
     |                              ...                              |
     +---------------+---------------+-------------------------------+
     |  Req-type-N   |  Req-option-N |         Vendor/Org-ID         |
     +-------------------------------+-------------------------------+
     |         Vendor/Org-ID         |            VS-Type            |
     +---------------------------------------------------------------+
     |                              ...                              |

   Context Request Option is typically used for the reactive (NAR-
   initiated) fast handover mode to retrieve the context information
   from the PAR.  When this option is included in the HI message, the
   requested option(s) MUST be included in the HAck message.

   Type           TBD

   Length         Number of requested context(s)+1.







Yokota, et al.           Expires August 29, 2008               [Page 18]


Internet-Draft          Proxy-based Fast Handover          February 2008


   Option-Code    0

   Req-type-n     The Type value for the requested option.

   Req-option-n   The Option-Code for the requested option.

   Padding        6 octets of padding are added if the requested type is
                  not the Vendor-Specific Option.  MUST be set to zero.

   Vendor/Org-ID  When the Vendor Specific Option is requested, the 3rd
                  to 6th octets are used for the Vendor/Org-ID defined
                  in Section 5.8.

   VS-Type        When the Vendor Specific Option is requested, the 7th
                  to 8th octets are used for the VS-Type defined in
                  Section 5.8.

5.4.  Tunnel-ID Option

   This option is used to transfer additional information that
   associates the MN with the tunnel used by the MN.  The exact format
   of the Tunnel-ID is outside the scope of this document.

      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 |   TID-Length  |
     +---------------------------------------------------------------+
     |        Tunnel-ID ...
     +------------------------------

   Type           TBD

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

   Option-Code    0

   TID-Length     The length of the Tunnel-ID in octets

   Tunnel-ID      The Tunnel-ID value.

5.5.  Mobile Node Interface Identifier (MN IID) Option

   This option is used to transfer the interface identifier of the MN
   that is used in the P-AN.  The format of the interface identifier
   follows the Mobile Node Interface Identifier Option defined in [2].




Yokota, et al.           Expires August 29, 2008               [Page 19]


Internet-Draft          Proxy-based Fast Handover          February 2008


      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  | MN IID-Length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                       Interface Identifier                    +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           TBD

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

   Option-Code    0

   MN IID-Length  The length of the MN IID in octets

   Interface Identifier
                  The Interface Identifier value of the MN that is used
                  in the P-AN.

5.6.  New option-code for the IP Address Option

   To convey the MN-HoA and LMA in the HI or HAck message, new Option-
   Codes for the IP Address Option[3] are defined:

   Option-Code

                  4  MN-HoA

                  5  LMA

5.7.  IPv4 Address Option

   As described in Section 4.3, if the MN is IPv4-only mode or dual-
   stack mode, the MN requires IPv4 home address (IPv4-MN-HoA).  The
   IPv4 address of the LMA (IPv4-LMAA) is also needed to send PMIP
   signaling messages when the ARs and LMA are in an IPv4 transport
   network.

      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  |    Reserved   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      IPv4 Address                             |



Yokota, et al.           Expires August 29, 2008               [Page 20]


Internet-Draft          Proxy-based Fast Handover          February 2008


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           TBD

   Length         1

   Option-Code

                  0  IPv4-MN-HoA

                  1  IPv4-LMAA

   IPv4 Address   IPv4 address specified in Option-Code

5.8.  Vendor Specific Option

   This option is to send other information than defined in this
   document.  Many of the context information can be vendor specific
   (access technology specific).  This option is used for such
   information.

      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 |    Reserved   |
     +---------------------------------------------------------------+
     |                         Vendor/Org-ID                         |
     +-------------------------------+-------------------------------+
     |            VS-Type            |           VS-Length           |
     +---------------------------------------------------------------+
     |           VS-Value ...
     +------------------------------

   Type           TBD

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

   Option-Code    0

   Vendor/Org-ID  The SMI Network Management Private Enterprise Code of
                  the Vendor/Organization as defined by IANA.

   VS-Type        The type of the Vendor-Specific information carried in
                  this option.  The type value is defined by the vendor
                  or organization specified by Vendor/Org-ID.





Yokota, et al.           Expires August 29, 2008               [Page 21]


Internet-Draft          Proxy-based Fast Handover          February 2008


   VS-Length      The length of the Vendor-Specific information carried
                  in this option.

   VS-Value       The value of the Vendor-Specific information carried
                  in this option.














































Yokota, et al.           Expires August 29, 2008               [Page 22]


Internet-Draft          Proxy-based Fast Handover          February 2008


6.  Security Considerations

   Security issues for this document follow those for PMIPv6[2] and
   FMIPv6[3].  In this document, it is assumed that the PAR (PMAG), NAR
   (NMAG) and LMA have trust relationship with each other and the
   connection between any pair is securely protected.













































Yokota, et al.           Expires August 29, 2008               [Page 23]


Internet-Draft          Proxy-based Fast Handover          February 2008


7.  References

7.1.  Normative References

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

   [2]  Gundave, S., Ed., "Proxy Mobile IPv6",
         draft-ietf-netlmm-proxymip6-10.txt, February 2008.

   [3]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers",
         draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt, October 2007.

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

7.2.  Informative References

   [5]  Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for Proxy
        Mobile IPv6",  draft-ietf-netlmm-pmip6-ipv4-support-02.txt,
        November 2007.































Yokota, et al.           Expires August 29, 2008               [Page 24]


Internet-Draft          Proxy-based Fast Handover          February 2008


Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   JP

   Email: yokota@kddilabs.jp


   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA  01876
   US

   Email: kchowdhury@starentnetworks.com


   Rajeev Koodli
   Nokia Siemens Networks
   313 Fairchild Drive
   Mountain View, CA  94043
   US

   Email: rajeev.koodli@nsn.com


   Basavaraj Patil
   Nokia Siemens Networks
   6000 Connection Drive
   Irving, TX  75039
   US

   Email: basavaraj.patil@nsn.com


   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075
   US

   Email: xiayangsong@huawei.com






Yokota, et al.           Expires August 29, 2008               [Page 25]


Internet-Draft          Proxy-based Fast Handover          February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Yokota, et al.           Expires August 29, 2008               [Page 26]