Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Expires: August 11, 2007                                      Huawei USA
                                                        February 7, 2007


       Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6
                    draft-xia-netlmm-fmip-mnagno-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 August 11, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Xia & Sarikaya           Expires August 11, 2007                [Page 1]

Internet-Draft              MN Agnostic FMIP               February 2007


Abstract

   In the current Proxy Mobile IPv6 (PMIPv6) proposals, the mobile nodes
   do not implement any mobility management protocol.  This document
   proposes an enhancement to PMIPv6 protocol in order to improve Layer
   3 handover performance through borrowing some ideas from FMIPv6
   protocol and using IEEE 802.21 triggers.  It proposes to use FMIP
   PAR-NAR signaling to establish a tunnel and PAR uses this tunnel to
   send MN's packets to NAR during handover.  FMIP PAR-NAR signaling
   depends on the predictive and reactive modes of handover.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Predictive Mode  . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  IPv4 Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   5.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . . .  7
     5.2.  Handover Acknowledge (HAck)  . . . . . . . . . . . . . . .  7
     5.3.  Fast Binding Update (FBU)  . . . . . . . . . . . . . . . .  7
     5.4.  Fast Binding Acknowledgement (FBack) . . . . . . . . . . .  7
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   7.  IANA consideration . . . . . . . . . . . . . . . . . . . . . .  7
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2.  Informative references . . . . . . . . . . . . . . . . . .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10


















Xia & Sarikaya           Expires August 11, 2007                [Page 2]

Internet-Draft              MN Agnostic FMIP               February 2007


1.  Introduction

   [RFC4068] introduces the operation of fast handovers for Mobile IPv6.
   [I-D.sgundave-mip6-proxymip6] defines Proxy Mobile IPv6 procedures.
   Based on the primitives defined in [802.21], this memo combines
   FMIPv6 operation with PMIPv6 protocol, and proposes a high
   performance handover solution in PMIPv6.


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

   ACoA:  Agent Care of Address.  From Home Agent perspective, all MNs
      attached to the same AR share one or more IPv6 addresses as their
      CoAs in PMIPv6 scheme.  These addresses could be the AR's egress
      interface IP addresses, or it's loopback IP addresses.  Defined as
      Proxy Mobile Agent (PMA) CoA in [I-D.sgundave-mip6-proxymip6].

   [BS-ID, AR-ACoA] tuple:  Contains ACoA of an AR to which a Base
      Station (identified by BS-ID) is attached.

   Additionally, we use the following triggers that are proposed by IEEE
   [802.21] and their standardization is in progress.

   Link Going Down (LGD):  A trigger from the link layer to IP layer in
      a BS to report that a link down event will be fired in the near
      future.
   Link Up (LUP):  A trigger from the link layer to IP layer in a BS to
      report that an MN completes L2 connection establishment with the
      BS.

   We define the following messages and some are similar to the
   definitions in [RFC4068].
   Handover Initiate (HI):  A message from PAR to NAR regarding MN's
      handover.
   Handover Acknowledge (HAck):  A message from NAR to PAR as a response
      to HI.
   Fast Binding Update (FBU):  A message from NAR to PAR instructing PAR
      to redirect MN's traffic (toward NAR).
   Fast Binding Acknowledgment (FBack):  A message from PAR in response
      to FBU.







Xia & Sarikaya           Expires August 11, 2007                [Page 3]

Internet-Draft              MN Agnostic FMIP               February 2007


3.  Protocol Operation

   Depending on whether L2 HO signaling is finished on a previous link,
   there are two modes of operation, that is, predictive and reactive
   mode.  The predictive mode is that L2 HO signaling finish on the
   previous link.

3.1.  Predictive Mode


                                ----------                   ----------
         MN                    | s-BS PAR |                 | NAR t-BS |
                                 ---------                   ----------
          |       1a             | 1b   |                     |      |
          |<-------------------->|<---->|                     |      |
          |                      |      |                     |      |
          | 2 L2 HO Signaling    |      |                     |      |
          |<====================>|      |                     |      |
          |                      |      |                     |      |
          |                      | 3 LGD|                     |      |
          |                      |----->|                     |      |
          |                      |      |      4 HI           |      |
          |                      |      |-------------------->|      |
          |                      |      |                     |      |
          |                      |      |      5 HAck         |      |
          |                      |      |<--------------------|      |
          |                      |      |                     |      |
          |                      |      |                     |      |
       disconnect                |      |  6 forward packets  |      |
          |                      |      |====================>|      |
          |                      |      |                     |      |
       connect                   |      |                     |      |
          |                      |      |                     | 7 LUP|
          |                      |      |    8 RA             |<-----|
          |<--------------------------------------------------|      |
          |                      |      | 9 deliver packets   |      |
          |<==================================================|      |
          |                      |      |                     |      |




                         Figure 1: Predictive Mode

   The procedure is as follows:
   1.  In stage 1a and 1b, an MN performs access authentication and
       address configuration.  After finishing IP connectivity, the PAR
       does the mobility related signaling on behalf of the MN.  For



Xia & Sarikaya           Expires August 11, 2007                [Page 4]

Internet-Draft              MN Agnostic FMIP               February 2007


       detailed information, please refer to
       [I-D.sgundave-mip6-proxymip6].
   2.  Before the MN moves from serving Base Station (s-BS) to target
       Base Station (t-BS), negotiation occurs between the MN and s-BS
       through L2 handover signaling.
   3.  When the L2 handover decision is achieved, the s-BS sends Link
       Going Down (LDG) message to the PAR.  The following information
       MUST be included: t-BS ID.
   4.  There are [BS-ID, AR-ACoA] tuples in ARs.  These tuples are
       probably manually configured or through other mechanisms which
       are out of scope for this memo.  Once receiving LGD message, the
       PAR retrieves NAR's ACoA through [BS-ID, AR-ACoA] tuple, and
       sends HI with the following information: the MN's IP address, the
       PAR's ACoA, the MN's Link Layer Address(LLA).  The NAR creates a
       Neighbor Cache entry for the MN based on the information of the
       HI message.
   5.  To reply the HI, the NAR sends HAck to the PAR.  Once HAck is
       received by the PAR, a bidirectional tunnel is established, and
       the PAR's ACoA and the NAR's ACoA are the tunnel's two ends.
   6.  PAR decapsulates the packets received from the HA-PAR tunnel and
       then relays them to NAR through PAR-NAR tunnel.
   7.  When a layer 2 link is established, the t-BS sends a LUP message
       to the NAR.
   8.  The NAR sends Router Advertisement(RA) with the NAR's information
       which facilitates the MN to send packets.
   9.  The NAR delivers the buffered packets to the MN.

3.2.  Reactive Mode























Xia & Sarikaya           Expires August 11, 2007                [Page 5]

Internet-Draft              MN Agnostic FMIP               February 2007


                                ----------                   ----------
         MN                    | s-BS PAR |                 | NAR t-BS |
                                 ---------                   ----------
          |                      |      | 1 Network Re-entry  |      |
          |<------------------------------------------------->|----->|
          |                      |      |                     |2 LUP |
          |                      |      |       3 RA          |<-----|
          |<--------------------------------------------------|      |
          |                      |      |       4 FBU         |      |
          |                      |      |<--------------------|      |
          |                      |      |                     |      |
          |                      |      |       5 FBack       |      |
          |                      |      |-------------------->|      |
          |                      |      |                     |      |
          |                      |      |  6 forward  packets |      |
          |                      |      |====================>|      |
          |                      |      |  7 deliver packets  |      |
          |<==================================================|      |
          |                      |      |                     |      |



                          Figure 2: Reactive Mode

   The procedure is as follows:

   1.  An MN performs network re-entry process, and link layer
       connectivity is established.

   2.  The target BS (t-BS) sends LUP message to the NAR.  The s-BS
       identifier, LLA of the MN MUST be included in this message.

   3.  The NAR sends Router Advertisement(RA) with the NAR's information
       which facilitates the MN to send packets.

   4.  There are [BS-ID, AR-ACoA] tuples in ARs.  These tuples are
       probably manually configured or through other mechanism, and how
       to formulate the tuples is out of scope for this memo.  Once
       receiving LUP message, the NAR retrieves PAR's ACoA through
       [BS-ID, AR-ACoA], and sends FBU to the PAR with the following
       information: the NAR's ACoA, MN's LLA.

   5.  Based on the MN's LLA, the PAR retrieves the MN's IP address from
       it's Neighbor Cache, and sends the IP address to the NAR in FBack
       message.  The NAR builds a Neighbor Cache entry of the MN after
       receiving FBack message.  During the message exchanges, a
       bidirectional tunnel is established, and the PAR's ACoA and the
       NAR's ACoA are the tunnel's two ends.



Xia & Sarikaya           Expires August 11, 2007                [Page 6]

Internet-Draft              MN Agnostic FMIP               February 2007


   6.  Packets destined to the MN are tunneled from HA to PAR then
       relayed to NAR through PAR-NAR tunnel.

   7.  The NAR delivers packets to the MN.


4.  IPv4 Considerations

   The main idea of this document is also applicable in IPv4 scenario,
   and some IPv6 specific sigaling should be modified.  Modifications
   are TBD.


5.  Message Formats

   All the messages between PAR and NAR are ICMPv6 messages and are
   defined in [RFC4068].  The messages that require modifications are
   specified below.

5.1.  Handover Initiate (HI)

   TBD

5.2.  Handover Acknowledge (HAck)

   TBD

5.3.  Fast Binding Update (FBU)

   TBD

5.4.  Fast Binding Acknowledgement (FBack)

   TBD


6.  Security Considerations

   The assumption of this proposal is that signaling between ARs is
   safe.  There is no signaling exchange between MNs and ARs.


7.  IANA consideration

   None.


8.  Acknowledgements



Xia & Sarikaya           Expires August 11, 2007                [Page 7]

Internet-Draft              MN Agnostic FMIP               February 2007


9.  References

9.1.  Normative References

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

9.2.  Informative references

   [802.16e]  Institute of Electrical and Electronics Engineer,
              "Amendment for Physical and Medium Access Control Layers
              for Combined Fixed  and Mobile Operation in Licensed
              Bands",  IEEE 802.16e/D12.

   [802.21]   Institute of Electrical and Electronics Engineer, "Draft
              IEEE Standard for Local and Metropolitan Area Networks:
              Media  Independent Handover Services",  IEEE P802.21/
              D00.05.

   [RFC4068]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
              July 2005.

   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461,
              December 1998.

   [I-D.ietf-mipshop-fh80216e]
              Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
              Networks", draft-ietf-mipshop-fh80216e-01 (work in
              progress), January 2007.

   [I-D.ietf-16ng-ipv6-over-ipv6cs]
              Patil, B., "IPv6 Over the IP Specific part of the Packet
              Convergence sublayer in 802.16  Networks",
              draft-ietf-16ng-ipv6-over-ipv6cs-07 (work in progress),
              January 2007.

   [I-D.ietf-16ng-ipv6-link-model-analysis]
              Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
              based Networks",
              draft-ietf-16ng-ipv6-link-model-analysis-02 (work in
              progress), January 2007.

   [I-D.sgundave-mip6-proxymip6]
              Gundavelli, S., "Proxy Mobile IPv6",
              draft-sgundave-mip6-proxymip6-01 (work in progress),
              January 2007.




Xia & Sarikaya           Expires August 11, 2007                [Page 8]

Internet-Draft              MN Agnostic FMIP               February 2007


Authors' Addresses

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

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 100
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

































Xia & Sarikaya           Expires August 11, 2007                [Page 9]

Internet-Draft              MN Agnostic FMIP               February 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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


Intellectual Property

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

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

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


Acknowledgment

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





Xia & Sarikaya           Expires August 11, 2007               [Page 10]