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

Versions: (draft-yokota-mipshop-pfmipv6) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5949

Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Standards Track                            K. Chowdhury
Expires: November 15, 2010                                     R. Koodli
                                                           Cisco Systems
                                                                B. Patil
                                                                   Nokia
                                                                  F. Xia
                                                              Huawei USA
                                                            May 14, 2010


                  Fast Handovers for Proxy Mobile IPv6
                   draft-ietf-mipshop-pfmipv6-14.txt

Abstract

   Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility
   when it performs a handover from one access router to another and
   fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] are specified to
   enhance the handover performance in terms of latency and packet loss.
   While MIPv6 (and FMIPv6 as well) requires the participation of the
   mobile node in the mobility-related signaling, Proxy Mobile IPv6
   (PMIPv6) [RFC5213] provides IP mobility to nodes that either have or
   do not have MIPv6 functionality without such involvement.
   Nevertheless, the basic performance of PMIPv6 in terms of handover
   latency and packet loss is considered not any different from that of
   MIPv6.

   When the fast handover is considered in such an environment, several
   modifications are needed to FMIPv6 to adapt to the network-based
   mobility management.  This document specifies the usage of Fast
   Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility
   management protocol.  Necessary extensions are specified for FMIPv6
   to support the scenario when the mobile node does not have IP
   mobility functionality and hence is not involved with either MIPv6 or
   FMIPv6 operations.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.




Yokota, et al.          Expires November 15, 2010               [Page 1]

Internet-Draft          Proxy-based Fast Handover               May 2010


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

   This Internet-Draft will expire on November 15, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


















Yokota, et al.          Expires November 15, 2010               [Page 2]

Internet-Draft          Proxy-based Fast Handover               May 2010


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . .  7
     4.1.  Protocol Operation . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Inter-AR Tunneling Operation . . . . . . . . . . . . . . . 15
     4.3.  IPv4 Support Considerations  . . . . . . . . . . . . . . . 17
   5.  PMIPv6-related Fast Handover Issues  . . . . . . . . . . . . . 18
     5.1.  Manageability Considerations . . . . . . . . . . . . . . . 18
     5.2.  Expedited Packet Transmission  . . . . . . . . . . . . . . 18
   6.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 20
     6.1.  Mobility Header  . . . . . . . . . . . . . . . . . . . . . 20
       6.1.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . 20
       6.1.2.  Handover Acknowledge (HAck)  . . . . . . . . . . . . . 22
     6.2.  Mobility Options . . . . . . . . . . . . . . . . . . . . . 24
       6.2.1.  Context Request Option . . . . . . . . . . . . . . . . 24
       6.2.2.  Local Mobility Anchor Address (LMAA) Option  . . . . . 25
       6.2.3.  Mobile Node Link-local Address Interface
               Identifier (MN LLA-IID) Option . . . . . . . . . . . . 26
       6.2.4.  Home Network Prefix Option . . . . . . . . . . . . . . 27
       6.2.5.  Link-local Address Option  . . . . . . . . . . . . . . 27
       6.2.6.  GRE Key Option . . . . . . . . . . . . . . . . . . . . 27
       6.2.7.  IPv4 Address Option  . . . . . . . . . . . . . . . . . 27
       6.2.8.  Vendor-Specific Mobility Option  . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 31
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     10.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Appendix A.  Applicable Use Cases  . . . . . . . . . . . . . . . . 33
     A.1.  PMIPv6 Handoff Indication  . . . . . . . . . . . . . . . . 33
     A.2.  Local Routing  . . . . . . . . . . . . . . . . . . . . . . 33
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41














Yokota, et al.          Expires November 15, 2010               [Page 3]

Internet-Draft          Proxy-based Fast Handover               May 2010


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 [RFC2119].














































Yokota, et al.          Expires November 15, 2010               [Page 4]

Internet-Draft          Proxy-based Fast Handover               May 2010


2.  Introduction

   Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to a mobile
   node that does not support Mobile IPv6 [RFC3775] mobile node
   functionality.  A proxy agent in the network performs the mobility
   management signaling on behalf of the mobile node.  This model
   transparently provides mobility for nodes within a PMIPv6 domain.
   Nevertheless, the basic performance of PMIPv6 in terms of handover
   latency and packet loss is considered not any different from that of
   Mobile IPv6.

   Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes the
   protocol to reduce the handover latency for Mobile IPv6 by allowing a
   mobile node to send packets as soon as it detects a new subnet link
   and by delivering packets to the mobile node as soon as its
   attachment is detected by the new access router.  This document
   extends FMIPv6 for Proxy MIPv6 operation to minimize handover delay
   and packet loss as well as to transfer network-resident context for a
   PMIPv6 handover.  [RFC5568] is normative for this document, except
   where this document specifies new or revised functions and messages.































Yokota, et al.          Expires November 15, 2010               [Page 5]

Internet-Draft          Proxy-based Fast Handover               May 2010


3.  Terminology

   This document reuses terminology from [RFC5213], [RFC5568] and
   [RFC3775].  The following terms and abbreviations are additionally
   used in this document.

   Access Network (AN):
        A network composed of link-layer access devices such as access
        points or base stations providing access to a MAG (Mobile Access
        Gateway) connected to it.

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

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

   Previous Mobile Access Gateway (PMAG):
        The MAG that manages mobility related signaling for the mobile
        node before handover.  In this document, the MAG and the Access
        Router are co-located.

   New Mobile Access Gateway (NMAG):
        The MAG that manages mobility related signaling for the mobile
        node after handover.  In this document, the MAG and the Access
        Router (AR) are co-located.

   Local Mobility Anchor (LMA):
        The topological anchor point for the mobile node's home network
        prefix(es) and the entity that manages the mobile node's binding
        state.  This specification does not alter any capability or
        functionality defined in [RFC5213].

   Handover indication:
        A generic signaling message, sent from the P-AN to the PMAG that
        indicates a mobile node's handover.  While this signaling is
        dependent on the access technology, it is assumed that Handover
        indication can carry the information to identify the mobile node
        and to assist the PMAG to resolve the NMAG and the new access
        point or base station to which the mobile node is moving to.
        The details of this message are outside the scope of this
        document.







Yokota, et al.          Expires November 15, 2010               [Page 6]

Internet-Draft          Proxy-based Fast Handover               May 2010


4.  Proxy-based FMIPv6 Protocol Overview

   This specification describes fast handover protocols for the network-
   based mobility management protocol called Proxy Mobile IP (PMIPv6)
   [RFC5213].  The core functional entities defined in PMIPv6 are the
   Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG).  The
   LMA is the topological anchor point for the mobile node's home
   network prefix(es).  The MAG acts as an access router (AR) for the
   mobile node and performs the mobility management procedures on its
   behalf.  The MAG is responsible for detecting the mobile node's
   movements to and from the access link and for initiating binding
   registrations to the mobile node's local mobility anchor.  If the
   MAGs can be informed of the detachment and/or attachment of the
   mobile node in a timely manner via e.g., the lower layer signaling,
   it will become possible to optimize the handover procedure, which
   involves establishing a connection on the new link and signaling
   between mobility agents, compared to the baseline specification of
   PMIPv6.

   In order to further improve the performance during the handover, this
   document specifies a bi-directional tunnel between the Previous MAG
   (PMAG) and the New MAG (NMAG) to tunnel packets meant for the mobile
   node.  In order to enable the NMAG to send the Proxy Binding Update
   (PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck)
   messages in [RFC5568] are extended for context transfer, in which
   parameters such as mobile node's Network Access Identifier (NAI),
   Home Network Prefix (HNP), IPv4 Home Address, are transferred from
   the PMAG.  New flags 'P' and 'F' are defined for the HI and HAck
   messages to distinguish from those in [RFC5568] and to request packet
   forwarding, respectively.

   In this document, the Previous Access Router (PAR) and New Access
   Router (NAR) are interchangeable with the PMAG and NMAG,
   respectively.  The reference network is illustrated in Figure 1.  The
   access networks in the figure (i.e., P-AN and N-AN) are composed of
   Access Points (APs) defined in [RFC5568], which are often referred to
   as base stations in cellular networks.

   Since a mobile node is not directly involved with IP mobility
   protocol operations, it follows that the mobile node is not directly
   involved with fast handover procedures either.  Hence, the messages
   involving the mobile node in [RFC5568] are not used when PMIPv6 is in
   use.  More specifically, the Router Solicitation for Proxy
   Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv),
   Fast Binding Update (FBU), Fast Binding Acknowledgment (FBack) and
   the Unsolicited Neighbor Advertisement (UNA) messages are not
   applicable in the PMIPv6 context.  A MAG that receives a RtSolPr or
   FBU message from a mobile node SHOULD behave as if they do not



Yokota, et al.          Expires November 15, 2010               [Page 7]

Internet-Draft          Proxy-based Fast Handover               May 2010


   implement FMIPv6 as defined in [RFC5568] at all, continuing to
   operate according to this specification within the network, or
   alternatively, start serving that particular mobile node as specified
   in [RFC5568].

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

               Figure 1: Reference network for fast handover

4.1.  Protocol Operation

   There are two modes of operation in FMIPv6 [RFC5568].  In the
   predictive mode of fast handover, a bi-directional tunnel between the
   PMAG (PAR) and NMAG (NAR) is established prior to the mobile node's
   attachment to the NMAG.  In the reactive mode, this tunnel
   establishment takes place after the mobile node attaches to the NMAG.
   In order to alleviate the packet loss during a mobile node's handover
   (especially when the mobile node is detached from both links), the
   downlink packets for the mobile node need to be buffered either at
   the PMAG or NMAG, depending on when the packet forwarding is
   performed.  It is hence REQUIRED that all MAGs have the capability
   and enough resources to buffer packets for the mobile nodes
   accommodated by them.  The buffer size to be prepared and the rate at
   which buffered packets are drained are addressed in Section 5.4 of
   [RFC5568].  Note that the protocol operation specified in the
   document is transparent to the local mobility anchor (LMA), hence
   there is no new functional requirement or change on the LMA.



Yokota, et al.          Expires November 15, 2010               [Page 8]

Internet-Draft          Proxy-based Fast Handover               May 2010


   Unlike MIPv6, the mobile node in the PMIPv6 domain is not involved
   with IP mobility signaling; therefore, in order for the predictive
   fast handover to work effectively, it is REQUIRED that the mobile
   node is capable of reporting lower-layer information to the AN at a
   short enough interval, and the AN is capable of sending the Handover
   indication to the PMAG at an appropriate timing.  The sequence of
   events for the predictive fast handover are illustrated in Figure 2.

                                            PMAG        NMAG
          MN         P-AN       N-AN        (PAR)       (NAR)     LMA
          |           |          |            |           |        |
     (a)  |--Report-->|          |            |           |        |
          |           |          |            |           |        |
          |           |       Handover        |           |        |
     (b)  |           |------indication------>|           |        |
          |           |          |            |           |        |
          |           |          |            |           |        |
     (c)  |           |          |            |----HI---->|        |
          |           |          |            |           |        |
          |           |          |            |           |        |
     (d)  |           |          |            |<---HAck---|        |
          |           |          |            |           |        |
          |           |          |            |           |        |
          |           |          |            |HI/HAck(optional)   |
     (e)  |           |          |            |<- - - - ->|        |
          |           |          |          #=|<===================|
     (f)  |           |          |          #====DL data=>|        |
          |  Handover |       Handover        |           |        |
     (g)  |<-command--|<------command---------|           |        |
         ~~~          |          |            |           |        |
         ~~~          |          |            |           |        |
          |   MN-AN connection   |    AN-MAG connection   |        |
     (h)  |<---establishment---->|<----establishment----->|        |
          |           |          |  (substitute for UNA)  |        |
          |           |          |            |           |        |
     (i)  |<==================DL data=====================|        |
          |           |          |            |           |        |
     (j)  |===================UL data====================>|=#      |
          |           |          |          #=|<============#      |
          |           |          |          #=====================>|
     /    |           |          |            |           |        | \
     |(k) |           |          |            |           |--PBU-->| |
     |    |           |          |            |           |        | |
     |(l) |           |          |            |           |<--PBA--| |
     |    |<==================DL data=====================|<=======| |
     |    |           |          |            |           |        | |
     \    |===================UL data====================>|=======>| /




Yokota, et al.          Expires November 15, 2010               [Page 9]

Internet-Draft          Proxy-based Fast Handover               May 2010


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

   The detailed descriptions are as follows:

   (a)  The mobile node detects that a handover is imminent and reports
        the identifier of itself (MN ID) and the New Access Point
        Identifier (New AP ID) [RFC5568] to which the mobile node is
        most likely to move.  The MN ID could be the NAI, Link-layer
        address, or any other suitable identifier, but the MAG SHOULD be
        able to map any access specific identifier to the NAI as the MN
        ID.  In some cases, the previous access network (P-AN) will
        determine the New AP ID for the mobile node.  This step is
        access technology specific and details are outside the scope of
        this document.

   (b)  The previous access network, to which the mobile node is
        currently attached, indicates the handover of the mobile node to
        the previous mobile access gateway (PMAG), with the MN ID and
        New AP ID.  Detailed definition and specification of this
        message are outside the scope of this document.

   (c)  The previous MAG derives the new mobile access gateway (NMAG)
        from the New AP ID, which is a similar process to that of
        constructing an [AP ID, AR-Info] tuple in [RFC5568].  The
        previous MAG then sends the Handover Initiate (HI) message to
        the new MAG.  The HI message MUST have the P flag set and
        include the MN ID, the HNP(s) and the address of the local
        mobility anchor that is currently serving the mobile node.  If
        there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID),
        that information MUST also be included.  With some link layers,
        the MN Link-local Address IID (MN LLA-IID) can also be included
        (see Section 6.2.3).

   (d)  The new MAG sends the Handover Acknowledge (HAck) message back
        to the previous MAG with the P flag set.

   (e)  If it is preferred that the timing of buffering or forwarding
        should be later than step (c), the new MAG MAY optionally
        request the previous MAG at a later and appropriate time to
        buffer or forward packets by setting U flag [RFC5568] or F flag
        in the HI message, respectively.

   (f)  If the F flag is set in the previous step, a bi-directional
        tunnel is established between the previous MAG and new MAG and
        packets destined for the mobile node are forwarded from the
        previous MAG to the new MAG over this tunnel.  After
        decapsulation, those packets MAY be buffered at the new MAG.  If
        the connection between the new access network and new MAG has



Yokota, et al.          Expires November 15, 2010              [Page 10]

Internet-Draft          Proxy-based Fast Handover               May 2010


        already been established, those packets MAY be forwarded towards
        the new access network, which then becomes responsible for them
        (e.g., buffering or delivering depending on the condition of the
        mobile node's attachment); this is access technology specific.

   (g)  When handover is ready on the network side, the mobile node is
        triggered to perform handover to the new access network.  This
        step is access technology specific and details are outside the
        scope of this document.

   (h)  The mobile node establishes a physical link connection with the
        new access network (e.g., radio channel assignment), which in
        turn triggers the establishment of a link-layer connection
        between the new access network and new MAG if not yet
        established.  An IP layer connection setup may be performed at
        this time (e.g., PPP IPv6CP) or at a later time (e.g., stateful
        or stateless auto address configuration).  This step can be a
        substitute for the Unsolicited Neighbor Advertisement (UNA) in
        [RFC5568].  If the new MAG acquires a valid new MN LL-ID via the
        new access network and a valid old MN LL-ID from the previous
        MAG at step (c), these IDs SHOULD be compared to determine
        whether the same interface is used before and after handover.
        When the connection between the mobile node and new MAG is PPP
        and the same interface is used for the handover, the new MAG
        SHOULD confirm that the same interface identifier is used for
        the mobile node's link-local address (this is transferred from
        previous MAG using the MN LLA-IID option at step (c), and sent
        to the mobile node during the Configure-Request/Ack exchange).

   (i)  The new MAG starts to forward packets destined for the mobile
        node via the new access network.

   (j)  The uplink packets from the mobile node are sent to the new MAG
        via the new access network and the new MAG forwards them to the
        previous MAG.  The previous MAG then sends the packets to the
        local mobility anchor that is currently serving the mobile node.

   (k)  The new MAG sends the Proxy Binding Update (PBU) to the local
        mobility anchor, whose address is provided in (c).  Steps (k)
        and (l) are not part of the fast handover procedure, but shown
        for reference.

   (l)  The local mobility anchor sends back the Proxy Binding
        Acknowledgment (PBA) to the new MAG.  From this time on, the
        packets to/from the mobile node go through the new MAG instead
        of the previous MAG.

   According to Section 4 of [RFC5568], the previous MAG establishes a



Yokota, et al.          Expires November 15, 2010              [Page 11]

Internet-Draft          Proxy-based Fast Handover               May 2010


   binding between the Previous Care-of Address (PCoA) and New Care-of
   Address (NCoA) to forward packets for the mobile node to the new MAG,
   and the new MAG creates a proxy neighbor cache entry to receive those
   packets for the NCoA before the mobile node arrives.  In the case of
   PMIPv6, however, the only address that is used by the mobile node is
   MN-HoA (Mobile Node's Home Address), so the PMAG forwards mobile
   node's packets to the NMAG instead of the NCoA.  The NMAG then simply
   decapsulates those packets and delivers them to the mobile node.
   FMIPv4 [RFC4988] specifies forwarding when the mobile node uses the
   home address as its on-link address rather than the care-of address.
   The usage in PMIPv6 is similar to that in FMIPv4, where the
   address(es) used by the mobile node is/are based on its HNP(s).
   Since the NMAG can obtain the Link-layer address (MN LL-ID) and
   HNP(s) via the HI message (also the interface identifier of the
   mobile node's link-local address (MN LLA-ID) if available), it can
   create a neighbor cache entry for the Link-local Address and the
   routes for the whole HNP(s) even before the mobile node performs
   Neighbor Discovery.  For the uplink packets from the mobile node
   after handover in (j), the NMAG forwards the packets to the PMAG
   through the tunnel established in step (f).  The PMAG then
   decapsulates and sends them to the local mobility anchor.

   The timing of the context transfer and that of packet forwarding may
   be different.  Thus, a new flag 'F' and Option Code values for it in
   the HI and HAck messages are defined to request forwarding.  To
   request buffering, 'U' flag has already been defined in [RFC5568].
   If the PMAG receives the HI message with the F flag set, it starts
   forwarding packets for the mobile node.  The HI message with the U
   flag set MAY be sent earlier if the timing of buffering is different
   from that of forwarding.  If packet forwarding is completed, the PMAG
   MAY send the HI message with the F flag set and the Option Code value
   being 2.  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 Step (f),

        Inner source address: IP address of the correspondent node

        Inner destination address: HNP or Mobile Node's IPv4 Home
        Address (IPv4-MN-HoA)

        Outer source address: IP address of the PMAG






Yokota, et al.          Expires November 15, 2010              [Page 12]

Internet-Draft          Proxy-based Fast Handover               May 2010


        Outer destination address: IP address of the NMAG

   In Step (i),

        Source address: IP address of the correspondent node

        Destination address: HNP or IPv4-MN-HoA

   In Step (j),

   - from the mobile node to the NMAG,

        Source address: HNP or IPv4-MN-HoA

        Destination address: IP address of the correspondent node

   - from the NMAG to the PMAG,

        Inner source address: HNP or IPv4-MN-HoA

        Inner destination address: IP address of the correspondent node

        Outer source address: IP address of the NMAG

        Outer destination address: IP address of the PMAG

   - from the PMAG to the LMA,

        Inner source address: HNP or IPv4-MN-HoA

        Inner destination address: IP address of the correspondent node

        Outer source address: IP address of the PMAG

        Outer destination address: IP address of the LMA






   In the case of the reactive handover for PMIPv6, since the mobile
   node does not send either the FBU or UNA, it would be more natural
   that the NMAG sends the HI to the PMAG after the mobile node has
   moved to the new link.  The NMAG then needs to obtain the information
   of the PMAG beforehand.  Such information could be provided, for
   example, by the mobile node sending the AP-ID on the old link and/or
   by the lower-layer procedures between the P-AN and N-AN.  The exact



Yokota, et al.          Expires November 15, 2010              [Page 13]

Internet-Draft          Proxy-based Fast Handover               May 2010


   method is not specified in this document.  Figure 3 illustrates the
   reactive fast handover procedures for PMIPv6, where the bi-
   directional tunnel establishment is initiated by the NMAG.

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

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

   The detailed descriptions are as follows:

   (a)  The mobile node undergoes handover from the previous access
        network to the new access network.

   (b)  The mobile node establishes a connection (e.g., radio channel)
        with the new access network, which triggers the establishment of
        the connection between the new access network and new MAG.  The
        MN ID is transferred to the new MAG at this step for the
        subsequent procedures.  The AP-ID on the old link (Old AP ID),



Yokota, et al.          Expires November 15, 2010              [Page 14]

Internet-Draft          Proxy-based Fast Handover               May 2010


        which will be provided by either the mobile node or the new
        access network, is also transferred to the new MAG to help
        identify the previous MAG on the new link.  This can be regarded
        as a substitute for the UNA and FBU.

   (c)  The new MAG sends the HI to the previous MAG.  The HI message
        MUST have the P flag set and include the MN ID.  The Context
        Request Option MAY be included to request additional context
        information on the mobile node to the previous MAG.

   (d)  The previous MAG sends the HAck back to the new MAG with the P
        flag set.  The HAck message MUST include the HNP(s) and/or IPv4-
        MN-HoA that is corresponding to the MN ID in the HI message and
        SHOULD include the MN LL-ID, only if it is valid (non zero), and
        the local mobility anchor address that is currently serving the
        mobile node.  The context information requested by the new MAG
        MUST be included.  If the requested context is not available for
        some reason, the previous MAG MUST return the HAck with the Code
        value 131.  If the F flag is set in the HI at step (c) and
        forwarding is nevertheless not executable for some reason, the
        previous MAG MUST return the HAck with the Code value 132.

   (e)  If the F flag in the HI is set at step (c), a bi-directional
        tunnel is established between the previous MAG and new MAG and
        packets destined for the mobile node are forwarded from the
        previous MAG to the new MAG over this tunnel.  After
        decapsulation, those packets are delivered to the mobile node
        via the new access network.

   (f)  The uplink packets from the mobile node are sent to the new MAG
        via the new access network and the new MAG forwards them to the
        previous MAG.  The previous MAG then sends the packets to the
        local mobility anchor that is currently serving the mobile node.

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

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

4.2.  Inter-AR Tunneling Operation

   When the PMAG (PAR) or NMAG (NAR), depending on the fast handover
   mode, receives the HI message with the F flag set, it prepares to
   send/receive the mobile node's packets to/from the other MAG and
   returns the HAck message with the same sequence number.  The both
   MAGs SHOULD support the following encapsulation modes for the user



Yokota, et al.          Expires November 15, 2010              [Page 15]

Internet-Draft          Proxy-based Fast Handover               May 2010


   packets, which are also defined for the tunnel between the local
   mobility anchor and MAG:

   o  IPv4-or-IPv6-over-IPv6 [IPv4PMIPv6]

   o  IPv4-or-IPv6-over-IPv4 [IPv4PMIPv6]

   o  IPv4-or-IPv6-over-IPv4-UDP [IPv4PMIPv6]

   o  TLV-header UDP tunneling [GREKEY]

   o  GRE tunneling with or without GRE key(s) [GREKEY]

   The PMAG and the NMAG MUST use the same tunneling mechanism for the
   data traffic tunneled between them.  The encapsulation mode to be
   employed SHOULD be configurable.  It is RECOMMENDED that:

   1.  As the default behavior, the inter-MAG tunnel uses the same
       encapsulation mechanism as that for the PMIPv6 tunnel between the
       local mobility anchor and the MAGs.  The PMAG and NMAG
       automatically start using the same encapsulation mechanism
       without a need for a special configuration on the MAGs or a
       dynamic tunneling mechanism negotiation between them.

   2.  Configuration on the MAGs can override the default mechanism
       specified in #1 above.  The PMAG and NMAG MUST be configured with
       the same mechanism and this configuration is most likely to be
       uniform throughout the PMIPv6 domain.  If the packets on the
       PMIPv6 tunnel cannot be uniquely mapped on to the configured
       inter-MAG tunnel, this scenario is not applicable and scenario #3
       below SHOULD directly be applied.

   3.  An implicit or explicit tunnel negotiation mechanism between the
       MAGs can override the default mechanism specified in #1 above.
       The employed tunnel negotiation mechanism is outside the scope of
       this document.

   The necessary information MUST be transferred in the HI/HAck messages
   to distinguish mobile node's packets for forwarding in advance or at
   this time.  Such information includes the HNP(s) (or IPv4-MN-HoA)
   and/or GRE key(s).  In the case of GRE tunneling with GRE keys being
   used, for each mobility session, the NMAG selects the GRE key for the
   downlink packets and the PMAG selects the GRE key for the uplink
   packets.  These GRE keys are exchanged between the PMAG and the NMAG
   using the GRE Key option as described in [GREKEY], e.g., In the case
   of the reactive mode as shown in Figure 3, the DL GRE key is
   communicated in the HI message while the UL GRE key is sent in the
   HAck message.  For the downlink packets, the PMAG redirects mobile



Yokota, et al.          Expires November 15, 2010              [Page 16]

Internet-Draft          Proxy-based Fast Handover               May 2010


   node's packets from the local mobility anchor towards the NMAG and if
   the mobile node is ready to receive those packets or the N-AN can
   handle them regardless of the state of the mobile node, the NMAG
   SHOULD immediately send them towards the N-AN; otherwise it SHOULD
   buffer them until the mobile node is ready.  For the uplink packets,
   the NMAG SHOULD reverse-tunnel them from the mobile node towards the
   PMAG and the PMAG sends them to the local mobility anchor.

   When the PMAG or NMAG receives the HI message with the U flag set, it
   prepares to buffer the mobile node's packets and returns the HAck
   message with the same sequence number.  It MUST be followed by
   another HI message with the F flag set at an appropriate time to
   forward the buffered packets.

   If the MAG that received the HI message encounters an erroneous
   situation (e.g., insufficient buffer space), it SHOULD immediately
   send the HAck message with the cause of the error and cancel all
   tunneling operation.

4.3.  IPv4 Support Considerations

   The motivation and usage scenarios of IPv4 protocol support by PMIPv6
   are described in [IPv4PMIPv6].  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 mobile node acquires
   IPv4 Home Address (IPv4-MN-HoA) and in the case of handover, the PMAG
   needs to transfer IPv4-MN-HoA to the NMAG, which is the inner
   destination address of the packets forwarded on the downlink.  For
   this purpose, IPv4 Address Option described in Section 6.2.7 is used.
   In order to provide IPv4 Transport Support, the NMAG needs to know
   the IPv4 address of the local mobility anchor (IPv4-LMAA) to send
   PMIPv6 signaling messages to the local mobility anchor in the IPv4
   transport network.  For this purpose, a new option called LMA Address
   (LMAA) Option is defined in Section 6.2.2 so as to convey IPv4-LMAA
   from the PMAG to NMAG.











Yokota, et al.          Expires November 15, 2010              [Page 17]

Internet-Draft          Proxy-based Fast Handover               May 2010


5.  PMIPv6-related Fast Handover Issues

5.1.  Manageability Considerations

   This specification does not require any additional IP-level
   functionality on the local mobility anchor and the mobile node
   running in the PMIPv6 domain.  A typical network interface that the
   mobile node could be assumed to have is one with the cellular
   network, where the network controls the movement of the mobile node.
   Different types of interfaces could be involved such as different
   generations (3G and 3.9G) or different radio access systems.  This
   specification supports a mobile node with the single radio mode,
   where only one interface is active at any given time.  The assigned
   IP address is preserved whether the physical interface changes or not
   and the mobile node can identify which interface should be used if
   there are multiple ones.

5.2.  Expedited Packet Transmission

   The protocol specified in this document enables the NMAG to obtain
   parameters which would otherwise be available only by communicating
   with the local mobility anchor.  For instance, the HNP(s) and/or
   IPv4-MN-HoA of a mobile node are made available to the NMAG through
   context transfer.  This allows the NMAG to perform some procedures
   that may be beneficial.  The NMAG, for example, SHOULD send a Router
   Advertisement (RA) with prefix information to the mobile node as soon
   as its link attachment is detected (e.g., via receipt of a Router
   Solicitation message).  Such an RA is recommended, for example, in
   scenarios where the mobile node uses a new radio interface while
   attaching to the NMAG; since the mobile node does not have
   information regarding the new interface, it will not be able to
   immediately send packets without first receiving an RA with HNP(s).
   Especially, in the reactive fast handover, the NMAG gets to know the
   HNP(s) assigned to the mobile node on the previous link at step (d)
   in Figure 3.  In order to reduce the communication disruption time,
   the NMAG SHOULD expect the mobile node to keep using the same HNP and
   to send uplink packets before that step upon the mobile node's
   request.  However, if the HAck from the PMAG returns a different HNP
   or the subsequent PMIPv6 binding registration for the HNP fails for
   some reason, then the NMAG MUST withdraw the advertised HNP by
   sending another RA with zero prefix lifetime for the HNP in question.
   This operation is the same as described in Section 6.12 of [RFC5213].

   The protocol specified in this document is applicable regardless of
   whether link-layer addresses are used between a mobile node and its
   MAG.  A mobile node should be able to continue sending packets on the
   uplink even when it changes link.  When link-layer addresses are
   used, the mobile node performs Neighbor Unreachability Detection



Yokota, et al.          Expires November 15, 2010              [Page 18]

Internet-Draft          Proxy-based Fast Handover               May 2010


   (NUD) [RFC4861], after attaching to a new link, probing the
   reachability of its default router.  The new router should respond to
   the NUD probe, providing its link-layer address in the solicited
   Neighbor Advertisement, which is common in the PMIPv6 domain.
   Implementations should allow the mobile node to continue to send
   uplink packets while it is performing NUD.













































Yokota, et al.          Expires November 15, 2010              [Page 19]

Internet-Draft          Proxy-based Fast Handover               May 2010


6.  Message Formats

   This document defines new Mobility Header messages for the extended
   HI and Hack and new mobility options for conveying context
   information.

6.1.  Mobility Header

6.1.1.  Handover Initiate (HI)

   This section defines extensions to the HI message in [RFC5568].  The
   format of the Message Data field in the Mobility Header is as
   follows:

      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
                                     +-------------------------------+
                                     |           Sequence #          |
     +-+-+-+-+-------+---------------+-------------------------------+
     |S|U|P|F|Resv'd |      Code     |                               |
     +-+-+-+-+-------+---------------+                               |
     |                                                               |
     .                                                               .
     .                       Mobility options                        .
     .                                                               .
     |                                                               |
     +---------------------------------------------------------------+
     (Note:P=1)

   IP Fields:

   Source Address

                       The IP address of PMAG or NMAG

   Destination Address

                       The IP address of the peer MAG

   Message Data:

   Sequence #  Same as [RFC5568].

   S flag      Defined in [RFC5568] and MUST be set to zero in this
               specification.






Yokota, et al.          Expires November 15, 2010              [Page 20]

Internet-Draft          Proxy-based Fast Handover               May 2010


   U flag      Buffer flag.  Same as [RFC5568].

   P flag      Proxy flag.  Used to distinguish the message from that
               defined in [RFC5568] and MUST be set in all new message
               formats defined in this document when using this protocol
               extension.

   F flag      Forwarding flag.  Used to request to forward the packets
               for the mobile node.

   Reserved    Same as [RFC5568].

   Code        [RFC5568] defines this field and its values 0 and 1.  In
               this specification, with the P flag set, this field can
               be set to zero by default or the following values:

                         2: Indicate the completion of forwarding

                         3: All available context transferred

               Code value 3 is set when the transfer of all necessary
               context information is completed with this message.  This
               Code value is used in both cases where the context
               information is fragmented into several pieces and the
               last fragment is contained in this message and where the
               whole information is transferred in one piece.

   Mobility options:

   This field contains one or more mobility options, whose encoding and
   formats are defined in [RFC3775].

   Required option
             In order to uniquely identify the target mobile node, the
             mobile node Identifier MUST be contained in the Mobile Node
             Identifier Option.

   The transferred context MUST be for one mobile node per message.  In
   addition, the NMAG can request necessary mobility options by the
   Context Request Option defined in this document.

   Context Request Option

            This option MAY be present to request context information
            typically by the NMAG to the PMAG in the NMAG-initiated fast
            handover.





Yokota, et al.          Expires November 15, 2010              [Page 21]

Internet-Draft          Proxy-based Fast Handover               May 2010


6.1.2.  Handover Acknowledge (HAck)

   This section defines extensions to the HAck message in[RFC5568].  The
   format of the Message Data field in the Mobility Header is as
   follows:

      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
                                     +-------------------------------+
                                     |           Sequence #          |
     +-+-+-+---------+---------------+-------------------------------+
     |U|P|F|Reserved |      Code     |                               |
     +-+-+-+---------+---------------+                               |
     |                                                               |
     .                                                               .
     .                       Mobility options                        .
     .                                                               .
     |                                                               |
     +---------------------------------------------------------------+
     (Note:P=1)

   IP Fields:

   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.

   Message Data:

   The usages of Sequence # and Reserved fields are exactly the same as
   those in [RFC5568].

   U flag      Same as defined in Section 6.1.1.

   P flag      Used to distinguish the message from that defined in
               [RFC5568] and MUST be set in all new message formats
               defined in this document when using this protocol
               extension.





Yokota, et al.          Expires November 15, 2010              [Page 22]

Internet-Draft          Proxy-based Fast Handover               May 2010


   F flag      Same as defined in Section 6.1.1.

   Code
               Code values 0 through 4 and 128 through 130 are defined
               in [RFC5568].  When the P flag is set, the meaning of
               Code value 0 is as defined in this specification, 128
               through 130 are reused, and 5, 6, 131 and 132 are newly
               defined.

                       0: Handover Accepted or Successful

                       5: Context Transfer Accepted or Successful

                       6: All available Context Transferred

                       128: Handover Not Accepted, reason unspecified

                       129: Administratively prohibited

                       130: Insufficient resources

                       131: Requested Context Not Available

                       132: Forwarding Not Available

   Mobility options:

   This field contains one or more mobility options, whose encoding and
   formats are defined in [RFC3775].  The mobility option that uniquely
   identifies the target mobile node MUST be copied from the
   corresponding HI message and the transferred context MUST be for one
   mobile node per message.

   Required option(s)  All the context information requested by the
             Context Request Option in the HI message SHOULD be present
             in the HAck message.  The other cases are described below.

   In the case of the PMAG-initiated fast handover, when the PMAG sends
   the HI message to the NMAG with the context information and the NMAG
   successfully receives it, the NMAG returns the HAck message with Code
   value 5.  In the case of the NMAG-initiated fast handover, when the
   NMAG sends the HI message to the PMAG with or without Context Request
   Option, the PMAG returns the HAck message with the requested or
   default context information (if any).  If all available context
   information is transferred, the PMAG sets the Code value in the HAck
   message to 6.  If more context information is available, the PMAG
   sets the Code value in the HAck to 5 and the NMAG MAY send new HI
   message(s) to retrieve the rest of the available context information.



Yokota, et al.          Expires November 15, 2010              [Page 23]

Internet-Draft          Proxy-based Fast Handover               May 2010


   If none of the requested context information is available, the PMAG
   returns the HAck message with Code value 131 without any context
   information.

6.2.  Mobility Options

6.2.1.  Context Request Option

   This option is sent in the HI message to request context information
   on the mobile node.  If a default set of context information is
   defined and always sufficient, this option is not used.  This option
   is more useful to retrieve additional or dynamically selected context
   information.

   Context Request Option is typically used for the reactive (NMAG-
   initiated) fast handover mode to retrieve the context information
   from the PMAG.  When this option is included in the HI message, all
   the requested context information SHOULD be included in the HAck
   message in the corresponding mobility option(s) (e.g., HNP, LMAA or
   MN LL-ID mobility options).

   The default context information to request is the Home Network Prefix
   Option.  If the Mobile Node link-layer is available and used, the
   Mobile Node Link-layer Identifier Option MUST also be requested.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +---------------+---------------+---------------+---------------+
     |  Option-Type  | Option-Length |           Reserved            |
     +---------------+---------------+-------------------------------+
     |  Req-type-1   | Req-length-1  |  Req-type-2   | Req-length-2  |
     +---------------------------------------------------------------+
     |  Req-type-3   | Req-length-3  |          Req-option-3         |
     +---------------------------------------------------------------+
     |                              ...                              |

   Option-Type    TBD1

   Option-Length  The length in octets of this option, not including the
                  Option Type and Option Length fields.

   Reserved       This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.

   Req-type-n     The type value for the n'th requested option.






Yokota, et al.          Expires November 15, 2010              [Page 24]

Internet-Draft          Proxy-based Fast Handover               May 2010


   Req-length-n   The length of the n'th requested option excluding the
                  Req-type-n and Req-length-n fields.

   Req-option-n   The optional data to uniquely identify the requested
                  context for the n'th requested option.

   In the case where there are only Req-type-n and Req-length-n fields,
   the value of the Req-length-n is set to zero.  If additional
   information besides the Req-type-n is necessary to uniquely specify
   the requested context, such information follows after the
   Req-length-n.  For example, when the requested contexts start with
   the HNP Option (type=22), the MN Link-layer ID Option (type=25) and
   the Vendor-Specific Option (type=19), the required option format
   looks as follows:

     |                              ...                              |
     +---------------+---------------+---------------+---------------+
     |Option-Type=CRO| Option-Length |           Reserved            |
     +---------------+---------------+---------------+---------------+
     | Req-type-N=22 | Req-length-N=0| Req-type-N=25 | Req-length-N=0|
     +---------------+---------------+-------------------------------+
     | Req-type-N=19 | Req-length-N=5|           Vendor-ID           |
     +-------------------------------+---------------+---------------+
     |           Vendor-ID           |   Sub-Type    |               |
     +-----------------------------------------------+               |
     |                              ...                              |

   The first two options can uniquely identify the requested contexts
   (i.e., the HNP and MN Link-layer ID) by the Req-type, so the Req-
   length is set to zero; however, the subsequent Vendor-Specific Option
   further needs the Vendor-ID and Sub-type to identify the requested
   context, so these parameters follow and the Req-length is set to 5.
   Note that the exact values in the Vendor-ID and Sub-Type follow
   [RFC5094].

6.2.2.  Local Mobility Anchor Address (LMAA) Option

   This option is used to transfer the Local Mobility Anchor IPv6
   Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the mobile
   node is currently registered.  The detailed definition of the LMAA is
   described in [RFC5213].

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option-Type  | Option-Length |  Option-Code  |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Local Mobility Anchor Address ...                |



Yokota, et al.          Expires November 15, 2010              [Page 25]

Internet-Draft          Proxy-based Fast Handover               May 2010


   Option-Type    TBD2

   Option-Length  18 or 6

   Option-Code

                  0  Reserved

                  1  IPv6 address of the local mobility anchor (LMAA)

                  2  IPv4 address of the local mobility anchor (IPv4-
                     LMAA)

   Reserved       This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.

   Local Mobility Anchor Address
                  If Option-Code is 1, the LMA IPv6 address (LMAA) is
                  inserted.  If Option-Code is 2, the LMA IPv4 address
                  (IPv4-LMA) is inserted.

6.2.3.  Mobile Node Link-local Address Interface Identifier (MN LLA-IID)
        Option

   This option is used to transfer the interface identifier of the
   mobile node's IPv6 Link-local Address that is used in the P-AN.  In
   deployments where the interface identifier is assigned by the
   network, or it is known to the network, this option is used to
   transfer this identifier from the PMAG to NMAG.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Option-Type   | Option-Length |            Reserved           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                      Interface Identifier                     +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option-Type    TBD3

   Option-Length  10

   Reserved       This field is unused.  It MUST be initialized to zero
                  by the sender and MUST be ignored by the receiver.





Yokota, et al.          Expires November 15, 2010              [Page 26]

Internet-Draft          Proxy-based Fast Handover               May 2010


   Interface Identifier
                  The Interface Identifier value used for the mobile
                  node's IPv6 Link-local address in the P-AN.

6.2.4.  Home Network Prefix Option

   This option is used to transfer the home network prefix that is
   assigned to the mobile node in the P-AN.  The Home Network Prefix
   Option defined in [RFC5213] is used for this.

6.2.5.  Link-local Address Option

   This option is used to transfer the link-local address of the PMAG
   (PMAG).  The Link-local Address Option defined in [RFC5213] is used
   for this.

6.2.6.  GRE Key Option

   This option is used to transfer the GRE Key for the mobile node's
   data flow over the bi-directional tunnel between the PMAG and NMAG.
   The message format of this option follows the GRE Key Option defined
   in [GREKEY].  The GRE Key value uniquely identifies each flow and the
   sender of this option expects to receive packets of the flow from the
   peer AR with this value.

6.2.7.  IPv4 Address Option

   As described in Section 4.3, if the mobile node runs in IPv4-only
   mode or dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA).
   This option is used to transfer the IPv4 home address if assigned on
   the previous link.  The format of this option follows the IPv4 Home
   Address Request Option defined in [IPv4PMIPv6].

6.2.8.  Vendor-Specific Mobility Option

   This option is used to transfer any other information defined in this
   document.  The format and used values of this option follow the
   Vendor-Specific Mobility Option defined in [RFC5094].













Yokota, et al.          Expires November 15, 2010              [Page 27]

Internet-Draft          Proxy-based Fast Handover               May 2010


7.  Security Considerations

   Security issues for this document follow those for PMIPv6 [RFC5213]
   and FMIPv6 [RFC5568].  In PMIPv6, the MAG and local mobility anchor
   are assumed to share security associations.  In FMIPv6, the access
   routers (i.e., the PMAG and NMAG in this document) are assumed to
   share security associations.

   The Handover Initiate (HI) and Handover Acknowledge (HAck) messages
   exchanged between the PMAG and NMAG MUST be protected using end-to-
   end security association(s) offering integrity and data origin
   authentication.  The PMAG and the NMAG MUST implement IPsec [RFC4301]
   for protecting the HI and HAck messages.  IPsec Encapsulating
   Security Payload (ESP) [RFC4303] in transport mode with mandatory
   integrity protection SHOULD be used for protecting the signaling
   messages.  Confidentiality protection SHOULD be used if sensitive
   context related to the mobile node is transferred.

   IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the
   mobile node's packets at the time of forwarding if the link between
   the PMAG and NMAG exposes the mobile node's packets to more threats
   than if they had followed their normal routed path.





























Yokota, et al.          Expires November 15, 2010              [Page 28]

Internet-Draft          Proxy-based Fast Handover               May 2010


8.  IANA Considerations

   This document defines new flags and status codes in the HI and HAck
   messages as well as three new mobility options.  The Type values for
   these mobility options are assigned from the same numbering space as
   allocated for the other mobility options defined in [RFC3775].  Those
   for the flags and status codes are assigned from the corresponding
   numbering space defined in [RFC5568] and requested to be created as
   new tables in the IANA registry (marked with asterisks).  New values
   for these registries can be allocated by Standards Action or IESG
   approval [RFC5226].

    Mobility Options
    Value  Description                                Reference
    -----  -------------------------------------      -------------
    TBD1   Context Request Option                     Section 6.2.1
    TBD2   Local Mobility Anchor Address Option       Section 6.2.2
    TBD3   Mobile Node Link-local Address
                    Interface Identifier Option       Section 6.2.3


    Handover Initiate Flags (*)
    Registration Procedures: Standards Action or IESG Approval
    Flag  Value  Description                          Reference
    ----  -----  -----------------------------------  -------------
      S   0x80   Assigned Address Configuration flag  [RFC5568]
      U   0x40   Buffer flag                          [RFC5568]
      P   0x20   Proxy flag                           Section 6.1.1
      F   0x10   Forwarding flag                      Section 6.1.1


    Handover Acknowledge Flags (*)
    Registration Procedures: Standards Action or IESG Approval
    Flag  Value  Description                          Reference
    ----  -----  -------------------------------      -------------
      U   0x80   Buffer flag                          Section 6.1.2
      P   0x40   Proxy flag                           Section 6.1.2
      F   0x20   Forwarding flag                      Section 6.1.2


    Handover Initiate Status Codes (*)
    Registration Procedures: Standards Action or IESG Approval
    Code  Description                                 Reference
    ----  --------------------------------------      -------------
      0   FBU with the PCoA as source IP address      [RFC5568]
      1   FBU whose source IP address is not PCoA     [RFC5568]
      2   Indicate the completion of forwarding       Section 6.1.1
      3   All available context transferred           Section 6.1.1



Yokota, et al.          Expires November 15, 2010              [Page 29]

Internet-Draft          Proxy-based Fast Handover               May 2010


    4-255 Unassigned


    Handover Acknowledge Status Codes (*)
    Registration Procedures: Standards Action or IESG Approval
    Code    Description                                 Reference
    ----    ---------------------------------------     -------------
      0     Handover Accepted or Successful             Section 6.1.2
                             (with NCoA valid)          [RFC5568]
      1     Handover Accepted, NCoA not valid           [RFC5568]
      2     Handover Accepted, NCoA assigned            [RFC5568]
      3     Handover Accepted, use PCoA                 [RFC5568]
      4     Message sent unsolicited                    [RFC5568]
      5     Context Transfer Accepted or Successful     Section 6.1.2
      6     All available Context Transferred           Section 6.1.2
    7-127   Unassigned
    128     Handover Not Accepted, reason unspecified   [RFC5568]
    129     Administratively prohibited                 [RFC5568]
    130     Insufficient resources                      [RFC5568]
    131     Requested Context Not Available             Section 6.1.2
    132     Forwarding Not Available                    Section 6.1.2
   133-255 Unassigned





























Yokota, et al.          Expires November 15, 2010              [Page 30]

Internet-Draft          Proxy-based Fast Handover               May 2010


9.  Acknowledgments

   The authors would like to specially thank Vijay Devarapalli and Sri
   Gundavelli for their thorough reviews of this document.

   The authors would also like to thank Charlie Perkins, Desire Oulai,
   Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan
   Zhao, Julien Laganier and Pierrick Seite for their passionate
   discussions in the working group mailing list.










































Yokota, et al.          Expires November 15, 2010              [Page 31]

Internet-Draft          Proxy-based Fast Handover               May 2010


10.  References

10.1.  Normative References

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

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

   [RFC5568]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
              July 2009.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5094]  Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
              Vendor Specific Option", RFC 5094, December 2007.

   [IPv4PMIPv6]
              Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for
              Proxy Mobile IPv6",
               draft-ietf-netlmm-pmip6-ipv4-support-18.txt,
              February 2010.

   [GREKEY]   Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6",
               draft-ietf-netlmm-grekey-option-09.txt, May 2009.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

10.2.  Informative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4988]  Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
              RFC 4988, October 2007.





Yokota, et al.          Expires November 15, 2010              [Page 32]

Internet-Draft          Proxy-based Fast Handover               May 2010


Appendix A.  Applicable Use Cases

A.1.  PMIPv6 Handoff Indication

   PMIPv6 [RFC5213] 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 by the
   NMAG when the handoff of the mobile node is executed.

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

      0) Reserved

      1) Attachment over a new interface

      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)

   Assuming that there is a valid MN Link-layer Identifier (MN LL-ID),
   the following solution can be considered.  When the NMAG receives the
   MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck
   message, the NMAG compares it with the new MN LL-ID that is obtained
   from the mobile node in the N-AN.  If these two MN LL-IDs are the
   same, the handoff type falls into 3) and the Handoff Indicator value
   is set to 3.  If these two MN LL-IDs are different, the handoff is
   likely to be 2) since the HI/HAck message exchange implies that this
   is a handoff 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 mobile node in the N-AN, 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 mobile node 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 or there is
   no valid MN LL-ID available, the NMAG may set the value to 4.

A.2.  Local Routing

   Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting
   flag is set, when two mobile nodes are attached to one MAG, the
   traffic between them may be locally routed.  If one mobile node moves
   from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not
   detect the mobile node's detachment, it will continue to forward



Yokota, et al.          Expires November 15, 2010              [Page 33]

Internet-Draft          Proxy-based Fast Handover               May 2010


   packets locally forever.  This situation is more likely to happen in
   the reactive fast handover with WLAN access, which does not have the
   capability to detect the detachment of the mobile node in a timely
   manner.  This specification can be applied to handle this case.  When
   the mobile node attaches to the NMAG, the NMAG sends the HI message
   to the PMAG with the 'F' flag set, which makes the PMAG realize the
   detachment of the mobile node and establish the inter-MAG tunnel.
   The PMAG immediately stops the local routing and sends the packets
   for the mobile node to the NMAG via that tunnel, which are then
   delivered to the mobile node on the new link.









































Yokota, et al.          Expires November 15, 2010              [Page 34]

Internet-Draft          Proxy-based Fast Handover               May 2010


Appendix B.  Change Log

   Changes at -00

      *  Added separate sections for MH and ICMP.

      *  Clarified usage of HNP and IPv4-MN-HoA throughout the document.

      *  Added IANA Considerations.

      *  Added section on Other Considerations, including operation of
         uplink packets when using link-layer addresses, multiple
         interface usage and transmission of RA to withdraw HNP in the
         event of failure of PMIP6 registration.

      *  Revised Security Considerations.

   Changes from -00 to -01

      *  Removed ICMPv6-based message format.

      *  Clarified HI/HAck exchange in the predictive mode (step (e) in
         Figure 2).

      *  Clarified information retrieval about the PMAG in the reactive
         mode.

      *  Removed the extension to the GRE Key Option.

      *  Clarified the handoff type considerations in Appendix A.

      *  Home Network Prefix Option, Link-local Address Option and
         Vendor-Specific Mobility Option are added.

   Changes from -01 to -02

      *  Aligned HI/HAck message formats with
         draft-ietf-mipshop-rfc5268bis-00.txt.

      *  Revised Section 8 removing the request for the type assignment
         of HI/HAck Mobility Headers.

   Changes from -02 to -03

      *  Updated HI/HAck message formats according to
         draft-ietf-mipshop-rfc5268bis-01.txt.





Yokota, et al.          Expires November 15, 2010              [Page 35]

Internet-Draft          Proxy-based Fast Handover               May 2010


      *  Cleaned up Figure 2 and Figure 3.

      *  Moved PMIP domain boundary crossing situation in Section 4.1 to
         Appendix A.3.

      *  Removed the alternative protocol operation with an unsolicited
         HAck from Section 4.1.

      *  Modified Code values in the HAck message in order to avoid
         collision with those in draft-ietf-mipshop-rfc5268bis-01.txt.

      *  Clarified the usage scenarios of Context Request Option.

      *  Modified the description of Code values in the HAck message.

      *  Changed the container for the IPv4-LMAA from IPv4 Address
         option to the LMAA option.

      *  Made Confidentiality protection "SHOULD" for context transfer.

   Changes from -03 to -04

      *  Added more explanations about MIPv6, FMIPv6 and PMIPv6 in
         Abstract.

      *  Moved Figure 1 to Section 4.

      *  More clearly indicated the FMIPv6 messages that are not
         applicable in the PMIPv6 context.

      *  Mandated the support of IP Sec on the PMAG and NMAG in order to
         protect signaling and user packets and the context information.

      *  Added a new section for the inter-AR tunneling operation
         (Section 4.2).

      *  Added descriptions about the encapsulation type in Sections 4.1
         and 4.3.

      *  Added a description about buffering requirements on the MAG in
         Section 4.1.

      *  Added a description about the timing of L2 and L3 connection
         establishments in Section 4.1.

      *  Added a new section for PMIPv6-related fast handover issues
         (Section 5) and a description about preferable behaviors of the
         mobile node and MAG to reduce packet loss.



Yokota, et al.          Expires November 15, 2010              [Page 36]

Internet-Draft          Proxy-based Fast Handover               May 2010


      *  Added Acknowledgments section (Section 9).

      *  Added a new section for local routing in Appendix (A.2).

   Changes from -04 to -05

      *  Fixed Figure 2 (step (i)).

      *  Defined the Mobile Network Interface Identifier (MN-IID)
         mobility option in Section 6.2.4 (swapped with old Section
         6.2.5), and added it to IANA considerations (Section 8).

      *  Changed from SHOULD to MUST regarding the inclusion of the
         MN-ID, MN-HNP, MN-IID and the LMAA options in the HI message
         (step (c) in Section 4.1).

      *  The optional behavior of the NMAG that allows it to send uplink
         packets directly to the local mobility anchor before the PBU/
         PBA exchange was removed from section 4.2 (as out of scope).

      *  In Section A.3, the description about the HA address assignment
         from the NAR to the mobile node was removed (as out of scope).

   Changes from -05 to -06

      *  Added 'P' flag in the HI and Hack messages to distinguish them
         from those in FMIPv6.

      *  Made editorial corrections in Section 2 (Introduction), Section
         3 (Terminology), Section 4 (Protocol Overview) and Section 4.2
         (Inter-AR Tunneling Operation).

      *  Added a description on how forwarded packets should be handled
         in the access network at step (f) in Section 4.1.

      *  Added all types of encapsulation methods that should be
         supported in Section 4.1.

      *  Revised the Code values for the HI message in Section 6.1.1.

      *  Revised the Code values for the HAck message in Section 6.1.2
         and added a description of its usage at step (d) of the
         reactive handover mode in Section 4.1.

      *  Removed the definition of the IP Address Option in Section
         6.2.3 and moved to Section 6.2.7, which currently refers to the
         IPv4 Home Address Option defined by RFC5555.  Revised the IANA
         Consideration section accordingly.



Yokota, et al.          Expires November 15, 2010              [Page 37]

Internet-Draft          Proxy-based Fast Handover               May 2010


      *  Removed the Option-Code from the Mobile Node Identifier (MN
         IID) Option.

      *  Removed Appendix A.3 (Handling of PMIPv6/MIPv6 switching).

   Changes from -06 to -07

      *  Added explanations about defining and setting the 'P' flag for
         the HI and Hack messages in Sections 4 and 4.1.

      *  Corrected the references for the encapsulation types in Section
         4.1.

      *  Modified the Code values for the HI message in Section 6.1.1 to
         avoid overlapping with those in
         draft-ietf-mipshop-rfc5268bis-01.txt.

      *  Modified the reference for the IPv4 Address Option from RFC5555
         to [IPv4PMIPv6] in Section 6.2.7.

   Changes from -07 to -08

      *  Corrected the reference for the TLV-header UDP encapsulation in
         Section 4.1.

      *  Updated the version number of the reference document
         [IPv4PMIPv6] and the option name defined by that document in
         Section 6.2.7.

   Changes from -08 to -09

      *  Added a paragraph at the beginning of Section 4 describing the
         assumption related to the lower layer signaling.

      *  Added a new section on the manageability considerations in
         Section 5 describing the configurations on the network and the
         mobile node assumed in this document.

      *  Modified the assumed configuration of the MAG regarding its
         link-layer address in Section 5 (Section 5.2 in version -09).

      *  Specified the requested option to identify the target MN for
         the inter-AR tunneling in Section 6.1.1.

      *  Specified the default context information in the Context
         Request Option in Section 6.2.1.





Yokota, et al.          Expires November 15, 2010              [Page 38]

Internet-Draft          Proxy-based Fast Handover               May 2010


   Changes from -09 to -10

      *  Revised the document based on the comments from TSV-DIR, SEC-
         DIR, OPS-DIR and GEN-ART.

         +  Split the abstract section in half for readability.

         +  Added the definition of Localized Mobility Anchor (local
            mobility anchor) in Section 3.

         +  Added the purpose of this document at the beginning of
            Section 4 to make the paragraph more complete.

         +  Revised the third paragraph of the Security Consideration
            section for more precise expression.

         +  Moved the description about the requirement to set the 'P'
            flag in HI/HAck to Sections 6.1.1 and 6.1.2.  Also, noted
            the 'P' flag setting below the message formats.

         +  Described the both 'P' and 'F' flags as newly defined ones
            in Section 4.

         +  Clarified the usage of the Context Request Option if a
            default set of context information is defined in Section
            6.2.1 (changed from "not mandatory" to "not used").

         +  Modified the identifier for the interface on the MN to the
            MN's link-layer ID (MN LL-ID).

         +  Corrected the local routing operation of the PMAG in
            Appendix A.2.

      *  Revised the descriptions about the encapsulation mechanism for
         the inter-MAG tunnel in Section 4.2 and other related parts for
         clarification.

      *  Also listed the new flags and status codes for the HI/HAck
         messages in the IANA Considerations section.

      *  Elaborated on the example use of the Context Request Option in
         Section 6.2.1.

   Changes from -10 to -11

      *  Changed the term "MN Interface Identifier (MN-IID) option" to
         "MN Link-local Address Interface Identifier (MN LLA-IID)
         option" in Section 6.2.3.  Its usage is valid only when the



Yokota, et al.          Expires November 15, 2010              [Page 39]

Internet-Draft          Proxy-based Fast Handover               May 2010


         network assigns the interface identifier.

      *  Revised the description of the neighbor cache entry in Section
         4.1 to include the MN LLA-IID.

   Changes from -11 to -12

      *  Changed the term "HO-Initiate" to "Handover indication".

      *  Added the handover trigger from the PMAG to the mobile node
         ("Handover command") to clarify the timing of handover in
         Figure 2.

      *  Revised IANA Considerations to include all values that are
         defined in RFC5568, but not in the IANA Registry yet.

   Changes from -12 to -13

      *  Editorial corrections.

   Changes from -13 to -14

      *  Corrections related to [RFC2119].




























Yokota, et al.          Expires November 15, 2010              [Page 40]

Internet-Draft          Proxy-based Fast Handover               May 2010


Authors' Addresses

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

   Email: yokota@kddilabs.jp


   Kuntal Chowdhury
   Cisco Systems
   30 International Place
   Tewksbury, MA  01876
   USA

   Email: kchowdhury@cisco.com


   Rajeev Koodli
   Cisco Systems
   30 International Place
   Tewksbury, MA  01876
   USA

   Email: rkoodli@cisco.com


   Basavaraj Patil
   Nokia
   6000 Connection Drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nokia.com


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

   Email: xiayangsong@huawei.com






Yokota, et al.          Expires November 15, 2010              [Page 41]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/