Internet DRAFT - draft-xia-netlmm-fmip-mnagno

draft-xia-netlmm-fmip-mnagno






Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Expires: May 21, 2008                                         Huawei USA
                                                       November 18, 2007


       Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6
                    draft-xia-netlmm-fmip-mnagno-02

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 May 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Xia & Sarikaya            Expires May 21, 2008                  [Page 1]

Internet-Draft              MN Agnostic FMIP               November 2007


Abstract

   Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility
   management protocol, that is, a mobile node does not implement any
   mobility management protocol.  This document proposes an enhancement
   to PMIPv6 protocol in order to improve layer 3 handover performance
   and to transfer context borrowing some ideas from Fast Handovers for
   Mobile IPv6 (FMIPv6) protocol.  In predictive mode, the previous
   mobile access gateway (PMAG) transfers context to the next MAG (NMAG)
   using Handover Indication (HI) message, while in reactive mode, NMAG
   uses Fast Binding Update (FBU) to request context from PMAG.  A bi-
   directional tunnel is established between PMAG and NMAG to transfer
   packets during handover.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  Predictive Mode  . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Handover Initiate (HI) . . . . . . . . . . . . . . . . . .  7
     4.2.  Handover Acknowledge (HAck)  . . . . . . . . . . . . . . .  9
     4.3.  Fast Binding Update (FBU)  . . . . . . . . . . . . . . . .  9
     4.4.  Fast Binding Acknowledgement (FBack) . . . . . . . . . . . 10
     4.5.  New Options  . . . . . . . . . . . . . . . . . . . . . . . 10
       4.5.1.  Mobile Node Identifier Option  . . . . . . . . . . . . 10
       4.5.2.  IPv4 Address Option  . . . . . . . . . . . . . . . . . 10
       4.5.3.  Vendor Specific Option . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   6.  IANA consideration . . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative references . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Interaction Fast PMIPv6 and IEEE802.16e . . . . . . . 14
     A.1.  IEEE802.16e terminology  . . . . . . . . . . . . . . . . . 14
     A.2.  IEEE 802.16e Network Entry and Handover Overview . . . . . 14
     A.3.  Interaction between Fast PMIPv6 and IEEE 802.16e . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17








Xia & Sarikaya            Expires May 21, 2008                  [Page 2]

Internet-Draft              MN Agnostic FMIP               November 2007


1.  Introduction

   [I-D.ietf-mipshop-fmipv6-rfc4068bis] introduces the operation of fast
   handovers for Mobile IPv6.  [I-D.ietf-netlmm-proxymip6] defines Proxy
   Mobile IPv6 procedures.  [I-D.ietf-netlmm-pmip6-ipv4-support]
   elaborates the support for the mobile node's IPv4 home address
   mobility in order to support the scenario where the local mobility
   anchor (LMA) and the mobile access gateway (MAG) are separated by an
   IPv4 transport network.  This memo combines FMIPv6 operation with
   PMIPv6 protocol, and proposes a network based handover solution in
   PMIPv6.

   The handovers in FMIPv6 always involve the mobile node.  In
   predictive mode, MN solicits the next access router (NAR)'s
   information by sending RtSolPr message; MN uses prefix information in
   PrRtAdv to formulate NCoA; MN initiates handover sending FBU to the
   previous access router (PAR); MN sends a UNA message to the NAR as
   soon as it regains connectivity on the new link so that arriving or
   buffered packets can be immediately forwarded.

   In PMIPv6, MNs attached to the same MAG have the same CoA which is
   called Proxy-CoA.  Using network side layer 2 trigger, previous
   mobile access gateway (PMAG) can initiate predictive handover on
   behalf of MNs.  The next mobile access gateway (NMAG) may also
   initiate reactive handover procedure when related layer 2 triggers
   are received.


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

   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:

   [BS-ID, Proxy-CoA] tuple:  Contains Proxy-CoA of an MAG and the Base
      Station (identified by BS-ID) which is attached to MAG.  The tuple
      is probably manually configured or using other mechanisms that are
      out of scope.

   PMAG:  Previous Mobile Access Gateway.  The MN's default router prior
      to its handover.  In this memo, it has the same meaning as the
      Previous Access Router (PAR) of FMIPv6.





Xia & Sarikaya            Expires May 21, 2008                  [Page 3]

Internet-Draft              MN Agnostic FMIP               November 2007



   NMAG:  New Mobile Access Gateway.  The MN's default router subsequent
      to its handover.  In this memo, it has the same meaning as the New
      Access Router (NAR) of FMIPv6.


3.  Protocol Operation

   Depending on whether layer 2 Handover (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.  In the following section, BS and MAG
   can be collocated or in different physical entities.  The picture in
   Figure 1 illustrates the scenario where BS and MAG are physically
   separated from each other.

3.1.  Predictive Mode


                           ---------------               -----------
       MN                 | s-BS     PMAG |             | NMAG t-BS |
                           ---------------               -----------
        |  1 Network Entry  |            |                |        |
        |<----------------->|<---------->|                |        |
        |   2 L2 HO         |            |                |        |
        |   Signalling      |            |                |        |
        |<=================>|===========>|                |        |
    disconnect              |            |                |        |
        |                   |3 L2-HO-IND |                |        |
        |                   |----------->|                |        |
        |                   |         buffering           |        |
        |                   |            |   4 HI         |        |
        |                   |            |--------------->|        |
        |                   |            |   5 HAck       |        |
        |                   |            |<---------------|        |
        |                   |            |  6 forward     |        |
        |                   |            |    packets     |        |
        |                   |            |===============>|        |
        |                   |            |            buffering    |
    connect                 |            |                |        |
        |                   |            |                | 7 LUP  |
        |                   |            |    8 RA        |<------>|
        |<------------------------------------------------|        |
        |                   |            | 10 deliver     | 9 PBU  |
        |                   |            |    packets     |---------->LMA
        |<================================================|        |





Xia & Sarikaya            Expires May 21, 2008                  [Page 4]

Internet-Draft              MN Agnostic FMIP               November 2007


                         Figure 1: Predictive Mode

   The procedure is as follows:
   1.   MN performs network entry procedure in which access
        authentication and IPv6 address configuration is done.  After
        finishing IP connectivity, the PMAG does the mobility related
        signaling on behalf of the MN.  For detailed information, please
        refer to [I-D.ietf-netlmm-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 made, the s-BS sends the PMAG
        L2-HO-IND message in which target BS-ID SHOULD be included.  The
        details on L2-HO-IND is out of scope.
   4.   There are [BS-ID, Proxy-CoA] tuples in MAGs.  Once receiving L2-
        HO-IND message, PMAG then
        *  collects MN's related context which includes the following
           information: MN identifier, MN-HoA, MN-HNP, MN's Proxy-CoA in
           the PMAG and MN's MAC.
        *  determines the NMAG's address for the destination of HI
           message.  Using BS-ID in L2-HO-IND message, the PMAG
           retrieves NMAG's Proxy-CoA from [BS-ID, Proxy-CoA] tuple.
        *  sends HI to NMAG with options which are defined in
           Section 4.1.
   5.   The NMAG creates a Binding Update List defined in
        [I-D.ietf-netlmm-proxymip6] for the MN based on the information
        in the HI message and probably synchronizes the context with
        corresponding BS.  NMAG then sends HAck to the PMAG.  Once HAck
        is received by the PMAG, a bi-directional tunnel is established,
        and the PMAG's Proxy-CoA and the NAR's Proxy-CoA are the
        tunnel's two ends.
   6.   Packets destined to the MN are tunneled from the PMAG to the
        NMAG based on the MN-HoA.  PMAG decapsulates the packets
        received from the tunnel to the LMA, encapsulates into PMAG/NMAG
        tunnel, and then sends them to NMAG.  NMAG SHOULD buffer the
        packets until the link between NMAG and MN is ready.
   7.   Network re-entry is performed when MN attaches to t-BS.  Context
        transferred from PMAG can be used to expedite the procedure.
        When a layer 2 link is established, the t-BS sends a Link Up
        (LUP) message to NMAG.
   8.   The NMAG sends Router Advertisement(RA) with the NMAG's
        information which facilitates the MN to send packets.
   9.   The NMAG sends PBU for updating the binding in LMA.  For detail,
        please refer to [I-D.ietf-netlmm-proxymip6].
   10.  The NMAG delivers the buffered packets to the MN.






Xia & Sarikaya            Expires May 21, 2008                  [Page 5]

Internet-Draft              MN Agnostic FMIP               November 2007


3.2.  Reactive Mode


                         ----------                   ------------
     MN                 | s-BS PMAG |                | NMAG    t-BS|
                          ---------                   ------------
      |                   |      | 1 Network Re-entry  |         |
      |<---------------------------------------------->|<------->|
      |                   |      |                     |         |
      |                   | 2 movement detection       |         |
      |                   |   and buffering            |         |
      |                   |      |                     | 3 LUP   |
      |                   |      |                     |<--------|
      |                   |      |       4 FBU         |         |
      |                   |      |<--------------------|         |
      |                   |      |                     | 5 PBU   |
      |                   |      |                     |---------->LMA
      |                   |      |       6 FBack       |         |
      |                   |      |-------------------->|         |
      |                   |      |                     |         |
      |                   |      | 7 forward  packets  |         |
      |                   |      |====================>|         |
      |                   |      |                     |         |
      |                   |      |       8 RA          |         |
      |<-----------------------------------------------|         |
      |                   |      |                     |         |
      |                   |      | 9 deliver packets   |         |
      |<===============================================|         |
      |                   |      |                     |         |





                          Figure 2: Reactive Mode

   The procedure is as follows:
   1.  MN performs network re-entry process to establish the link layer.
       Context from original session are necessary to expedite link
       establishment.
   2.  To minimize packet loss during handover, PMAG SHOULD
       automatically buffer packets for all MNs that have disappeared
       off its link.  There are two cases to cover here.  Case A, MN
       just moved and the PMAG didn't know that it was handing over.
       Case B, MN exchanged L2 messages with the PMAG and it knew that
       it was moving, but it may not have completed the whole procedure.
       PMAGs automatically buffer packets (perhaps for a default period
       of time) for each MN that is not on its link in case A, or PMAGs



Xia & Sarikaya            Expires May 21, 2008                  [Page 6]

Internet-Draft              MN Agnostic FMIP               November 2007


       just buffer packets in case B because it's less open to denial of
       service (DoS) attacks or errors.
   3.  After network re-entry process is finished, t-BS sends a LUP
       message to the NMAG.  The detail about LUP is out of scope.
   4.  Once previous BS-ID and MN's MAC are available during network re-
       entry process, NMAG sends FBU to the PMAG with the following
       information: the NMAG's Proxy-CoA and MN's MAC.  NMAG determines
       the PMAG's address through referring to [BS-ID, Proxy-CoA] tuples
       in NMAG.  In this step, it is reasonable to assume that the
       previous BS-ID is exchanged during network re-entry as for
       example in WiMAX links [802.16e].
   5.  NMAG sends PBU for updating the binding in LMA.  For details,
       please refer to [I-D.ietf-netlmm-proxymip6].
   6.  Based on the MN's MAC, PMAG identifies MN's Binding Update List
       and collects MN's related context which includes the following
       information: MN identifier, MN-HoA, MN-HNP, MN's Proxy-CoA in the
       PMAG, and MN's MAC.  PMAG transfers the context to NMAG through
       FBack message.  When FBack is received by NMAG, a bi-directional
       tunnel is established, and the PMAG's Proxy-CoA and the NMAG's
       Proxy-CoA are the tunnel's two ends.
   7.  Once the bi-directional tunnel is established, PMAG forwards the
       buffered packets to NMAG.
   8.  NMAG sends Router Advertisement (RA) with the NMAG's information
       which facilitates the MN to send packets.
   9.  NMAG then delivers packets to the MN.


4.  Message Formats

   All the messages between PMAG and NMAG are ICMPv6 messages and are as
   defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  Some new options
   are defined.  Only the messages that require modification are
   specified below.

4.1.  Handover Initiate (HI)

   HI is an ICMPv6 message sent by PMAG to NMAG to convey context and
   establish bi-directional tunnel.  Please refer to
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.2.1 for details.  The
   following information are included in options for bi-directional
   tunnel creation and context transfer:

   MN Identifier  The information is conveyed by Mobile Node Identifier
      option defined in Section 4.5.1.  The identifier is used for
      retrieving MN's profile from a policy store.






Xia & Sarikaya            Expires May 21, 2008                  [Page 7]

Internet-Draft              MN Agnostic FMIP               November 2007



   Proxy-CoA of PMAG  The information is conveyed by IP Address Option
      defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1.
      PMAG's Proxy-CoA is one end of the bi-directional tunnel between
      PMAG and NMAG.

   Proxy-CoA of NMAG  The information is conveyed by IP Address Option
      defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  The address is
      intended to be the other end of the bi-directional tunnel.  NMAG
      can return another address in HAck message as the tunnel end if
      the address is not proper.

   MN MAC  The information is conveyed by Link-layer Address (LLA)
      Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section
      6.4.3.  MAC is used to correlate Bind Update List and the
      corresponding layer 2 link.

   MN-HoA  The information is conveyed by IP Address Option defined in
      [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1.  It is the
      main element for Bind Update List in NMAG.  All traffic from the
      source address MN-HoA is routed via the bi-directional tunnel
      between PMAG and NMAG when the new tunnel between LMA and NMAG is
      not created.  The option is necessary only if MN is IPv6 or dual
      stack support.

   LMAA  The information is conveyed by IP Address Option defined in
      [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.4.1.  The address
      is configured on the interface of the local mobility anchor and is
      the transport endpoint of the tunnel between the local mobility
      anchor and the mobile access gateway.  The option is necessary
      only if transport network is IPv6.

   IPv4 LMAA  The information is conveyed by IPv4 Address Option defined
      in Section 4.5.2.  The option is necessary only if transport
      network is IPv4.

   MN-HNP  The information is conveyed by New Router Prefix Information
      Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section
      6.4.2.  To emulate MN's home link, MN's Home Network Prefix is
      included in the NMAG's Router Advertisement.

   Link-local Address of PMAG  The information is conveyed by IP Address
      Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  The value
      will be the link-local address of the first MAG to which this MN
      attached.  NMAG MUST advertise RA using the PMAG's link-local
      address with the Router Lifetime field set to value 0, then it is
      possible to force the flush out of the Previous Default-Router
      entry from the mobile node's cache.



Xia & Sarikaya            Expires May 21, 2008                  [Page 8]

Internet-Draft              MN Agnostic FMIP               November 2007



   DHCP Server Address  The information is conveyed by IP Address Option
      defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  If Address
      Configuration using DHCP is supported on the link on which the
      mobile node is attached, the DHCP relay agent needs to be
      configured on the MAG.  When the mobile node sends a DHCPv6
      Request message, the relay agent function on the MAG must relay
      the message to the DHCP server.  The option is necessary only if
      DHCP Server Address is IPv6.

   IPv4 DHCP Server Address  The information is conveyed by IPv4 Address
      Option defined in Section 4.5.2.  The option is necessary only if
      DHCP Server Address is IPv4.

   Vendor Specific Option  A new option is defined in Section 4.5.3.
      This option is defined for implementation specific context such as
      security parameters, compression parameters and so on.

4.2.  Handover Acknowledge (HAck)

   HAck is a reply to the HI message.  Please refer to
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.2.2.  The following
   option is needed:

   Proxy-CoA of NMAG  The information is conveyed by IP Address Option
      defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  PMAG MUST use
      this as one end of a bi-directional tunnel.

4.3.  Fast Binding Update (FBU)

   The Fast Binding Update message is defined in
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.3.1.  The following
   modifications are made:

   Proxy-CoA of PMAG  .  The information is conveyed by IP Address
      Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  PMAG's
      Proxy-CoA is one end of the bi-directional tunnel between PMAG and
      NMAG.

   Proxy-CoA of NMAG  .  The information is conveyed by IP Address
      Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis].  The
      address is intended to be the other end of the bi-directional
      tunnel.  NMAG can return another address in HAck message as the
      tunnel end if the address is not proper.







Xia & Sarikaya            Expires May 21, 2008                  [Page 9]

Internet-Draft              MN Agnostic FMIP               November 2007



   MN MAC  The information is conveyed by Link-layer Address (LLA)
      Option defined in [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section
      6.4.3.  MAC is used to correlate Bind Update List and
      corresponding layer 2 link.

4.4.  Fast Binding Acknowledgement (FBack)

   FBack message is sent by the PMAG to acknowledge receipt of a Fast
   Binding Update message and is defined in
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] Section 6.3.2.  The message has
   the same option set as HI message to establish bi-directional tunnel
   and transfer contexts.

4.5.  New Options

4.5.1.  Mobile Node Identifier Option

   Various forms of identifiers can be used to identify a MN.  Since
   [I-D.ietf-netlmm-proxymip6] uses the mobile node identifier option
   for Mobile IPv6 defined in [RFC4283], this document also adopts the
   same format.

4.5.2.  IPv4 Address Option

   A mobile node operating in IPv4-only mode or in a dual-stack mode
   should be able to obtain an IPv4 home address.  When the transport
   network between the local mobility anchor and the mobile access
   gateway is an IPv4 network, LMA IPv4 address is necessary.  This
   option is used for IPv4 address context transfer between PMAG and
   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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     | Option-Code   |  Reserved     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      IPv4 address                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Type       To be assigned by IANA

        Length     the length of the option in units of 8 octets.

        Option-Code
                   1 IPv4 MN-HoA
                   2 IPv4 LMA Address when transport network is IPv4.




Xia & Sarikaya            Expires May 21, 2008                 [Page 10]

Internet-Draft              MN Agnostic FMIP               November 2007


        IPv4 Address
                  The IPv4 address defined by the Option-Code field



4.5.3.  Vendor Specific Option

   Like Mobile IPv6 Vendor Specific Option defined in
   [I-D.ietf-mip6-vsm], the option defined here is for vendors specific
   implementation.  MAGs not equipped to interpret the option MUST
   ignore it.


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |        Reserved               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Vendor ID                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      String...                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




     Type       To be assigned by IANA

     Length     The length of the option in units of 8 octets.

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

     String     The String field is one or more octets.  The actual format of the
                information is site or application specific. It SHOULD be encoded as
                a sequence of  type / length / value fields. Multiple
                sub-options MAY be encoded within a single Vendor Specific option.



5.  Security Considerations

   AAA-based secret keys or local CAs can be used to protect the
   signalling exchange between PMAG and NMAG.






Xia & Sarikaya            Expires May 21, 2008                 [Page 11]

Internet-Draft              MN Agnostic FMIP               November 2007


6.  IANA consideration

   The values of Vendor Specific Option and IPv4 Address Option MUST be
   allocated by IANA.


7.  Acknowledgements


8.  References

8.1.  Normative References

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

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

8.2.  Informative references

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

   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

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

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
              Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
              (MIPv6)", RFC 4283, November 2005.

   [I-D.ietf-mipshop-fmipv6-rfc4068bis]
              Koodli, R., "Mobile IPv6 Fast Handovers",
              draft-ietf-mipshop-fmipv6-rfc4068bis-03 (work in
              progress), October 2007.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",



Xia & Sarikaya            Expires May 21, 2008                 [Page 12]

Internet-Draft              MN Agnostic FMIP               November 2007


              draft-ietf-netlmm-proxymip6-07 (work in progress),
              November 2007.

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01
              (work in progress), July 2007.

   [I-D.ietf-mip6-vsm]
              Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
              Vendor Specific Option", draft-ietf-mip6-vsm-03 (work in
              progress), October 2007.







































Xia & Sarikaya            Expires May 21, 2008                 [Page 13]

Internet-Draft              MN Agnostic FMIP               November 2007


Appendix A.  Interaction Fast PMIPv6 and IEEE802.16e

A.1.  IEEE802.16e terminology

   MOB_MSHO-REQ:  handover request message sent by MN.

   MOB_BSHO-RSP:  handover response message sent by BS.

   MOB_BSHO-REQ:  handover request message sent by BS.

   MOB_HO-IND:  handover indication message sent by MN.

   RNG-REQ:  Ranging Request.

   RNG-RSP:  Ranging Response.

   REG-REQ:  Registration Request.

   REG-RSP:  Registration Response.

   PKM-REQ:  Privacy Key Management Request.

   PKM-RSP:  Privacy Key Management Response.

A.2.  IEEE 802.16e Network Entry and Handover Overview

   Related IEEE 802.16e processes are highlighted in the following
   section.

   Network Entry.  Once the MN makes a first network attachment, it
   conducts 802.16e ranging through which it can acquire physical
   parameters from the target BS, tuning its parameters to the target
   BS.  After ranging with the target BS successfully, the MN negotiates
   basic capabilities such as maximum transmit power and modulator/
   demodulator type.  It then performs authentication and key exchange
   procedure, and finally registers with the target BS.  After
   successful registration, the target BS become a serving BS.

   Handover Preparation.  The handover preparation can be initiated by
   either the MN or the BS.  During this period, neighboring BSs are
   compared by the metrics such as signal strength or QoS parameters and
   a target BS is selected among them.  Once the MN decides handover, it
   notifies the serving BS by sending a MOB_MSHO-REQ message.  The BS
   then replies with a MOB_BSHO-RSP containing the recommended BSs to
   the MN after negotiating with candidates.  Optionally it may confirm
   handover to the target BS over backbone when the target is decided.
   The BS alternatively may trigger handover with a MOB_BSHO-REQ
   message.



Xia & Sarikaya            Expires May 21, 2008                 [Page 14]

Internet-Draft              MN Agnostic FMIP               November 2007


   Handover Execution.  When the MN is about to move to the new link
   after deciding the target BS, it sends a MOB_HO-IND message to the
   serving BS as a final indication for its handover.

   Network Reentry.  The process is almost the same as the network
   entry.  If the target BS has already learned some contexts such as
   authentication or capability parameters through backbone, it may omit
   the corresponding procedures.

A.3.  Interaction between Fast PMIPv6 and IEEE 802.16e

   o  Predictive Mode.  In handover execution phase which is described
      in the above section, a MN sends MOB_HO-IND to the serving BS.
      The target BSID should be included in the MOB_HO-IND.  Upon
      receiving MOB_HO-IND, the serving BS notifies PMAG with L2-HO-IND
      event as described in Figure 1.  The target BSID should be
      included in the L2-HO-IND.  The PMAG can decide the corresponding
      NMAG by referring to [BS-ID, Proxy-CoA] tuple.  The details of the
      handover are described in Section 3.1.

   o  Reactive Mode.  After switching links, the MN synchronizes with
      the target BS and performs the 802.16e network reentry
      procedure.The MN exchanges the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/
      RSP and REG-REQ/RSP messages with the target BS.  When the network
      reentry procedure is completed and the link layer is ready for
      data transmission, the target BS informs the NMAG with a LUP
      primitive in which the previous serving BSID is included.  The
      NMAG can decide the corresponding PMAG by referring to [BS-ID,
      Proxy-CoA] tuple.  The details of the handover are described in
      Section 3.2





















Xia & Sarikaya            Expires May 21, 2008                 [Page 15]

Internet-Draft              MN Agnostic FMIP               November 2007


Authors' Addresses

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

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


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

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

































Xia & Sarikaya            Expires May 21, 2008                 [Page 16]

Internet-Draft              MN Agnostic FMIP               November 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 May 21, 2008                 [Page 17]