Internet DRAFT - draft-han-netlmm-fast-pmipv6

draft-han-netlmm-fast-pmipv6






NETLMM WG                                                         Y. Han
Internet-Draft                                                       KUT
Intended status: Informational                                   B. Park
Expires: February 4, 2009                                             KT
                                                           July 03, 2008


              A Fast Handover Scheme in Proxy Mobile IPv6
                    draft-han-netlmm-fast-pmipv6-00

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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

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

   This Internet-Draft will expire on January 1, 2009.

Abstract

   This memo proposes a scheme that supports a fast handover effectively
   in Proxy Mobile IPv6 by optimizing the associated data and signaling
   flows during the handover.  New signaling messages, Fast PBU and
   Reverse PBU, are defined and utilized to expedite the handover
   procedure.









Han & Park               Expires January 1, 2009                [Page 1]

Internet-Draft                 Fast PMIPv6                     June 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Handoff Type Considerations . . . . . . . . . . . . . . . . . . 6
   5.  Message Format  . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9






































Han & Park               Expires January 1, 2009                [Page 2]

Internet-Draft                 Fast PMIPv6                     June 2008


1.  Introduction

   The PMIPv6 (Proxy Mobile IPv6) protocol provides local mobility
   management to a mobile node without requiring any modification of the
   mobile node.  But, PMIPv6's handover could cause undesirable delay to
   the mobile nodes running real time applications like VoIP.  This memo
   proposes a scheme that supports a fast handover effectively in PMIPv6
   by optimizing the associated data and signaling flows during the
   handover.

   FMIPv6 (Fast Handover for Mobile IPv6) [RFC5268] is a well-known fast
   handover scheme for the host-based Mobile IPv6.  It may be harnessed
   to enhance PMIPv6's handover performance.  Actually, some schemes
   have been proposed based on the FMIPv6's strategy (see [I-D.xia-
   netlmm-fmip-mnagno] and [I-D.yokota-mipshop-pfmipv6]).  However, they
   induce unnecessary processing overhead for re-tunneling at the MAGs,
   as well as inefficient usage of network bandwidth if there are no
   direct secure links between them.  The main reason for this is that
   the data transport of PMIPv6 is based on the tunneling from the LMA
   to the MAG, not between MAGs, while the FMIPv6 and the existing
   schemes use the tunneling between the previous AR (PAR) and new AR
   (NAR) for fast handover.

   We propose a new PMIPv6's fast handover scheme to overcome such
   ineffectiveness by defining the signaling messages between LAM and
   MAG.  The proposed scheme utilizes only pre-established bi-
   directional tunnels between LMA and MAGs, and does not create and
   utilize a bi-directional tunnel between MAGs.


2.  Terminology

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

   The terminology in this document is based on the definitions in
   [I-D.ietf-netlmm-proxymip6], in addition to the ones specified in
   this section:

   o  Previous Mobile Access Gateway (PMAG): The MAG that manages
      mobility related signaling for the MN before handover.

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

   o  Previous Point of Attachment (P-PoA): The access network device to
      which the MN is attached before handover.



Han & Park               Expires January 1, 2009                [Page 3]

Internet-Draft                 Fast PMIPv6                     June 2008


   o  New Point of Attachment (N-PoA): The access network device to
      which the MN is attached after handover.

   o  Fast Proxy Binding Update (Fast PBU): A request message sent by an
      MAG to a mobile node's LMA for expediting the handover procedure.

   o  Fast Proxy Binding Acknowledgement (Fast PBA): A reply message
      sent by an LMA in response to a Fast PBU message that it received
      from a MAG.

   o  Reverse Proxy Binding Update (Reverse PBU): A request message sent
      by LMA to a mobile node's new MAG after establishing a binding
      between the home network prefix assigned to the mobile node and
      its new care-of address (Proxy-CoA).

   o  Reverse Proxy Binding Acknowledgement (Reverse PBA): A reply
      message sent by a MAG in response to a Reverse PBU message that it
      received from an LMA.


3.  Protocol Operation

   Because a mobile node is not directly involved with IPv6 mobility
   management, it is also unaware of fast handover procedure defined in
   this memo.  All new signaling messages defined in this memo are
   exchanged by the MAG and the LMA.  The proposed scheme is not based
   on the fast handover strategy defined in [RFC5268].

   To reduce the handover latency due to signaling between the MAGs and
   the LMA, this memo only utilizes the bi-directional tunnels between
   the LMA and the PMAG/NMAG.  That is, no tunnel creation between MAGs
   is required.  The bi-directional tunnel between the LMA and the PMAG
   has been always established to provide a visited mobile node with the
   packet delivery service.  The bi-directional tunnel between the LMA
   and the NMAG may be also already established because the tunnels are
   shared for multiple mobile nodes in PMIPv6.















Han & Park               Expires January 1, 2009                [Page 4]

Internet-Draft                 Fast PMIPv6                     June 2008


         MN        P-PoA      N-PoA       PMAG        NMAG          LMA
         |           |          |          |           |             |
         |Link-specific         |          |           |             |
    (a)  |Pre-handover          |          |           |             |
         |procedure  |          |          |           |             |
         |<--------->|     HO Initiate     |           |             |
    (b)  |           |-(MN ID, New AP ID)->|           |             |
         |           |          |          |        Fast PBU         |
    (c)  |           |          |          |----(MN ID, New PCoA)--->|
         |           |          |          |           |             |
         |           |          |          |        Fast PBA         |
    (d)  |           |          |          |<------------------------|
         |           |          |          |           |             |
         |           |          |          |           | Reverse PBU |
    (e)  |           |          |          |           |<--(MN ID,---|
         |           |          |          |           |     HNP)    |
         |           |          |          |           |             |
    (f)  |           |          |          |           | Reverse PBA |
         |           |          |          |           |------------>|
    (g)  |           |          |          |           |<==DL data===|
        ~~~          |          |          |           |\            |
    (h)              |          |          |           | |buffering  |
        ~~~          |          |          |           | |           |
         |  MN:N-PoA connection |  N-PoA:MAG connection| |           |
    (h)  |<---establishment---->|<---establishment---->| |           |
         |           |          |          |           |/            |
    (i)  |<=================DL data====================|             |
         |           |          |          |           |             |
    (j)  |==================UL data===================>|             |
         |           |          |          |           |===UL data==>|
         |           |          |          |           |             |


                     The proposed handover procedure.

                                 Figure 1

   The procedure is as follows (see Figure 1):

   (a)     A handover is imminent and a link-specific pre-handover
           procedure is performed.  The pre-handover procedure can be
           host-initiated or network-initiated.  The exact procedure is
           out of scope.

   (b)     P-PoA, to which the MN is currently attached, indicates the
           handover of the mobile node to the PMAG.  The exact procedure
           of this indication is also out of scope.




Han & Park               Expires January 1, 2009                [Page 5]

Internet-Draft                 Fast PMIPv6                     June 2008


   (c)     The PMAG sends the Fast PBU to the LMA.  The Fast PBU message
           MUST include the MN ID and the new PCoA, the address of NMAG,
           which is resolved by the New AP ID.

   (d)     The LMA sends back the Fast PBA to the PMAG.

   (e)     The LMA establishes a binding between the home network prefix
           (HNP) assigned to the mobile node and its new PCoA.  The LMA
           sends the Reverse PBU to the NMAG.  The Reverse PBU message
           MUST include the MN ID and the HNP of the mobile node.

   (f)     The NMAG sends back the Reverse PBA to the LMA.

   (g)     If the bi-directional tunnel is not established between the
           NMAG and the LMA, a new tunnel is established.  The LMA
           starts to transfer packets destined for the mobile node via
           the NMAG.  If the mobile node has not established a
           connection with NMAG at this time, the NMAG starts to buffer
           the packets.

   (h)     The mobile node hands over to the New Access Network.

   (i)     The mobile node establishes a connection (e.g. radio channel)
           with the N-PoA, which in turn triggers the establishment of
           the connection between the N-PoA and NMAG.  The exact
           procedure of this procedure is also out of scope.

   (j)     The NMAG starts to transfer packets destined for the mobile
           node via the N-PoA.

   (k)     The uplink packets from the mobile node are sent to the NMAG
           via the N-PoA and the NMAG forwards them to the LMA.

   It is noted that the Reverse PBU and PBA are the alternates of the
   original PBU and PBU of PMIPv6.  That is, the proposed scheme
   incorporates the main part of PMIPv6 procedure in the fast handover
   procedure, and thus any subsequent PMIPv6 procedure is not necessary.


4.  Handoff Type Considerations

   TBD


5.  Message Format

   TBD




Han & Park               Expires January 1, 2009                [Page 6]

Internet-Draft                 Fast PMIPv6                     June 2008


6.  Security Considerations

   TBD


7.  References

7.1.  Normative References

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-18 (work in progress),
              May 2008.

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

   [RFC5268]  Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268,
              June 2008.

7.2.  Informative References

   [I-D.xia-netlmm-fmip-mnagno]
              Xia, F. and B. Sarikaya, "Mobile Node Agnostic Fast
              Handovers for Proxy Mobile IPv6",
              draft-xia-netlmm-fmip-mnagno-02 (work in progress),
              November 2007.

   [I-D.yokota-mipshop-pfmipv6]
              Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
              Xia, "Fast Handovers for PMIPv6",
              draft-yokota-mipshop-pfmipv6-02 (work in progress),
              February 2008.


Authors' Addresses

   Youn-Hee Han
   KUT
   Gajeon-Ri, 307, Byeongcheon-Myeon
   Cheonan, Chungnam
   Korea

   Phone: +82 41 560 1486
   Email: yhhan@kut.ac.kr





Han & Park               Expires January 1, 2009                [Page 7]

Internet-Draft                 Fast PMIPv6                     June 2008


   Byungjoo Park
   KT
   Jeonmin-Dong, Yusung-Go
   Deajoen, Chungnam
   Korea

   Email: bjpark@kt.co.kr












































Han & Park               Expires January 1, 2009                [Page 8]

Internet-Draft                 Fast PMIPv6                     June 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.











Han & Park               Expires January 1, 2009                [Page 9]