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

Versions: (draft-jang-mipshop-fh80216e) 00 01 02 03 04 05 06 07 RFC 5270

MIPSHOP Working Group                                       Hee-Jin Jang
Internet-Draft                                               Samsung AIT
Intended status: Informational                              Junghoon Jee
Expires: August 1, 2008                                             ETRI
                                                            Youn-Hee Han
                                                                     KUT
                                                     Soohong Daniel Park
                                                     Samsung Electronics
                                                             Jaesun Cha
                                                                    ETRI
                                                        January 29, 2008


         Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
                   draft-ietf-mipshop-fh80216e-06.txt

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on August 1, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).







Jang, et al.             Expires August 1, 2008                 [Page 1]

Internet-Draft             FMIPv6 over 802.16e              January 2008


Abstract

   This document describes how a Mobile IPv6 Fast Handover can be
   implemented on link layers conforming to the 802.16e suite of
   specifications.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . .  6
   4.  Network Topology Acquisition and Network Selection . . . . . .  8
   5.  Interaction between FMIPv6 and IEEE 802.16e  . . . . . . . . .  9
     5.1.  Access Router Discovery  . . . . . . . . . . . . . . . . .  9
     5.2.  Handover Preparation . . . . . . . . . . . . . . . . . . .  9
     5.3.  Handover Execution . . . . . . . . . . . . . . . . . . . . 10
     5.4.  Handover Completion  . . . . . . . . . . . . . . . . . . . 11
   6.  The Examples of Handover Scenario  . . . . . . . . . . . . . . 13
     6.1.  Predictive Mode  . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 18
   9.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22






















Jang, et al.             Expires August 1, 2008                 [Page 2]

Internet-Draft             FMIPv6 over 802.16e              January 2008


1.  Introduction

   Mobile IPv6 (MIPv6) [RFC3775] is currently available to provide the
   session continuity during handover.  It is capable of handling IP
   handover between different subnets in a transparent way for higher-
   layer connections.  However, the handover latency resulting from
   MIPv6 is often unacceptable to real-time traffic such as Voice over
   IP, and Mobile IPv6 Fast Handover protocol (FMIPv6)
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] has been proposed as a mechanism
   to reduce the handover latency by predicting and preparing the
   impending handover in advance.

   As [RFC4260] pointed out, FMIPv6 assumes the support from the link-
   layer technology, but the specific link-layer information available,
   as well as the timing of its availability (before, during or after a
   handover occurs), differs according to the particular link-layer
   technology in use.  This document is proposed to provide
   informational guide to the developers about how to optimize the
   FMIPv6 handover procedure, specifically in the 802.16 networks.

   To provide the seamless handover, this proposal tries to maximize the
   benefits of synchronizing the link layer handover with the fast IP
   handover procedure by exploiting the link-layer handover indicators
   when available.  In this proposal, the Media Independent Handover
   (MIH) services being defined in the IEEE 802.21 working group
   [802.21] is used as an example of link-layer specific indicators for
   this purpose.  This document introduces a set of useful messages
   among primitives proposed by IEEE 802.21 which can be cooperated with
   802.16 handover and FMIPv6 procedures, and provides the most
   appropriate timing for the trigger of each selected primitive during
   802.16 handover procedure.

   We begin with a summary of a handover procedure of [802.16e] which is
   the amendment of 802.16 for mobility.  Then the interaction between
   802.16e and FMIPv6 is presented with the primitives proposed by IEEE
   802.21 [802.21] for the close interaction between Layer 2 and Layer
   3.  Lastly, the examples of handover scenarios are described for both
   predictive mode and reactive mode.













Jang, et al.             Expires August 1, 2008                 [Page 3]

Internet-Draft             FMIPv6 over 802.16e              January 2008


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document is to be interpreted as described in [RFC2119].

   Most of terms used in this document are defined in MIPv6 [RFC3775]
   and FMIPv6 [I-D.ietf-mipshop-fmipv6-rfc4068bis].

   The following terms come from IEEE 802.16e specification [802.16e].

      MOB_NBR-ADV

         An IEEE 802.16e neighbor advertisement message sent
         periodically by a base station.

      MOB_MSHO-REQ

         An IEEE 802.16e handover request message sent by a mobile node.

      MOB_BSHO-RSP

         An IEEE 802.16e handover response message sent by a base
         station.

      MOB_BSHO-REQ

         An IEEE 802.16e handover request message sent by a base
         station.

      MOB_HO-IND

         An IEEE 802.16e handover indication message sent by a mobile
         node.

      BSID

         An IEEE 802.16e base station identifier.

   Additionally, the following primitives are proposed by [802.21] and
   the standardization is in progress.

      Link_Detected (LD)

         A trigger from the link layer to the IP layer in a mobile node
         to report that a new link is detected.





Jang, et al.             Expires August 1, 2008                 [Page 4]

Internet-Draft             FMIPv6 over 802.16e              January 2008


      Link_Handover_Imminent (LHI)

         A trigger from the link layer to the IP layer in a mobile node
         to report that a native link layer handover/switch decision has
         been made and its execution is imminent.

      Link_Up (LUP)

         A trigger from the link layer to the IP layer in a mobile node
         to report that the mobile node completes the link layer
         connection establishment with a new BS.

      Handover_Commit (HC)

         A control command from the IP layer to the link layer in a
         mobile node in order to force the mobile node to switch from an
         old BS to a new BS.


































Jang, et al.             Expires August 1, 2008                 [Page 5]

Internet-Draft             FMIPv6 over 802.16e              January 2008


3.  IEEE 802.16e Handover Overview

   Compared with the handover in the wireless LAN, the 802.16e handover
   mechanism consists of more steps since 802.16e embraces the
   functionality for elaborate parameter adjustment and procedural
   flexibility.

   When a mobile node (MN) stays in a link, it listens to L2 neighbor
   advertisement messages, named a MOB_NBR-ADV, from its serving base
   station (BS).  A BS broadcasts them periodically to identify the
   network and announces the characteristics of neighbor BSs.  Once
   receiving this, the MN decodes this message to find out information
   about the parameters of neighbor BSs for its future handover.  With
   the provided information in a MOB_NBR-ADV, the MN may minimize the
   handover latency by obtaining the channel number of neighbors and
   reducing the scanning time, or may select the better target BS based
   on the signal strength, QoS level, service price, etc.

   The handover procedure is conceptually divided into two steps:
   "handover preparation" and "handover execution" [SH-802.16e].  The
   handover preparation can be initiated by either the MN or the BS.
   During this period, neighbors are compared by the metrics such as
   signal strength or QoS parameters and a target BS is selected among
   them.  If necessary, the MN may try to associate (initial ranging)
   with candidate BSs to expedite a future handover.  Once the MN
   decides handover, it notifies its intent by sending a MOB_MSHO-REQ
   message to the serving BS.  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.

   After handover preparation, handover execution starts.  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.  Once the MN makes a new 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.  If the target BS has already learned
   some contexts such as authentication or capability parameters through
   backbone, it may omit the corresponding procedures.  For the detailed
   procedure of the 802.16 network entry, refer to section 6.3.22 of
   [802.16e].  After completing registration, the target BS starts to
   serve the MN and communication via target BS is available.  However,
   when the MN moves to a different subnet, it should re-configure a new



Jang, et al.             Expires August 1, 2008                 [Page 6]

Internet-Draft             FMIPv6 over 802.16e              January 2008


   IP address and re-establish an IP connection.  To resume the active
   session of the previous link, the MN should perform IP layer handover
   additionally.
















































Jang, et al.             Expires August 1, 2008                 [Page 7]

Internet-Draft             FMIPv6 over 802.16e              January 2008


4.  Network Topology Acquisition and Network Selection

   This section describes how discovery of adjacent networks and
   selection of target network work in 802.16e for background
   information.

   An MN can learn the network topology and acquire the link information
   in two ways.  One method is via L2 neighbor advertisements.  A BS
   supporting mobile functionality shall broadcast a MOB_NBR-ADV message
   including the network topology periodically (maximum interval,
   1sec.).  This message includes BSIDs and channel information of
   neighbor BSs, and is used to facilitate the MN's synchronization with
   neighbor BSs.  An MN can collect the necessary information of the
   neighbor BSs through this message for its future handover.

   Another method for acquisition of network topology is scanning, which
   is the process to seek and monitor available BSs in order to find
   suitable handover targets.  While a MOB_NBR-ADV message includes
   static information about neighbor BSs, scanning provides rather
   dynamic parameters such as link quality parameters.  Since the
   MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically
   and scanning provides a way to sort out some adequate BSs, it is
   recommended that when new BSs are found in the advertisement, the MN
   identifies them via scanning and resolves their BSIDs to the
   information of the subnet where the BS is connected.  The
   association, an optional initial ranging procedure occurring during
   scanning, is one of the helpful methods to facilitate the impending
   handover.  The MN is able to get ranging parameters and service
   availability information for the purpose of proper selection of the
   target BS and expediting a potential future handover to it.  The
   detailed explanation of association is described in section 6.3.22 of
   [802.16e].

   After learning about neighbors, the MN may compare them to find a BS
   which can serve better than the serving BS.  The target BS may be
   determined by considering various criteria such as required QoS,
   cost, user preference, and policy.  How to select the target BS is
   not in the scope of this document.













Jang, et al.             Expires August 1, 2008                 [Page 8]

Internet-Draft             FMIPv6 over 802.16e              January 2008


5.  Interaction between FMIPv6 and IEEE 802.16e

   In this section, we describe the desirable FMIPv6 handover procedure
   in 802.16 networks.  We introduce four primitives proposed by
   [802.21] for the close interaction between FMIPv6 and 802.16e, and
   present the detailed interaction procedure.

5.1.  Access Router Discovery

   Once a new BS is detected through the reception of a MOB_NBR-ADV and
   scanning, an MN may try to learn the associated AR information as
   soon as possible.  In order to enable quick discovery of the
   associated AR information in the IP layer, the link layer (802.16)
   triggers a Link_Detected (LD) primitive to the IP layer (FMIPv6) on
   detecting the new BS.

   Receiving the Link_Detected from the link layer, the IP layer tries
   to learn the associated AR information by exchanging a RtSolPr
   (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy
   Router Advertisement) with the PAR.  According to
   [I-D.ietf-mipshop-fmipv6-rfc4068bis], the MN may send a RtSolPr at
   any convenient time.  However this proposal recommends that, if
   feasible, the MN send it as soon as possible after receiving the
   primitive for quick router discovery because detection of a new BS
   usually implies MN's movement.

   It is unlikely that RtSolPr messages may cause signaling overheads
   mentioned in Section 2 of [RFC4907].  The MN may detect more than one
   BSs and issue the Link_Detected primitives but not all at once.
   Furthermore, retransmission of RtSolPr messages are rate-limited by
   exponential backoff in [I-D.ietf-mipshop-fmipv6-rfc4068bis].

5.2.  Handover Preparation

   When the MN decides to change links based on its policy such as the
   degrading signal strength or increasing packet loss rate, it
   initiates handover by sending a MOB_MSHO-REQ to the BS and receives a
   MOB_BSHO-RSP from the BS as a response.  Alternatively the BS may
   initiate handover by sending a MOB_BSHO-REQ to the MN.

   On receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ, the link layer
   triggers a Link_Handover_Imminent (LHI) in order to signal the IP
   layer of arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly.  At this time,
   the target network decided in the link layer is delivered to the IP
   layer in the MAC_access_router parameter (MAC address of the target
   AR) of the Link_Handover_Imminent primitive.  According to [802.21],
   the Link_Handover_Imminent primitive is used to report that a native
   link layer handover/switch decision has been made and its execution



Jang, et al.             Expires August 1, 2008                 [Page 9]

Internet-Draft             FMIPv6 over 802.16e              January 2008


   is imminent.  This primitive can be helpfully used for FMIPv6 as an
   indication to start handover preparation procedure, that is to send
   an FBU message to the PAR.

   To avoid erroneous results due to unreliable and inconsistent
   characteristics of link, for instance, to move to the unpredicted
   network or to keep staying in the current network after sending an
   FBU, Section 2 of [RFC4907] advises to use combination of signal
   strength data with other techniques rather than relying only on
   signal strength for handover decision.  For example, an LHI may be
   sent after validating filtered signal strength measurements with
   other indications of link loss such as lack of beacon reception.

   Once the IP layer receives the LHI, it checks whether the specified
   target network belongs to the different subnet or not based on the
   information collected during Access Router Discovery step.  If the
   target proves to be in the same subnet, the MN can continue to use
   the current IP address after handover and there is no need to perform
   FMIPv6.  Otherwise, the IP layer formulates a prospective NCoA (New
   CoA) with the information provided in the PrRtAdv message and sends
   an FBU message to the PAR.

   When the FBU message arrives in the PAR successfully, the PAR and the
   NAR process it according to [I-D.ietf-mipshop-fmipv6-rfc4068bis].
   The PAR sets up a tunnel between the PCoA (Previous CoA) and NCoA by
   exchanging HI (Handover Initiate) and HAck (Handover Acknowledge)
   messages with the NAR, forwarding the packets destined for the MN to
   NCoA.  The NCoA is confirmed or re-assigned by the NAR in the HAck
   and finally delivered to the MN through the FBack message in case of
   predictive mode.

   After the MN sends a MOB_HO-IND to the serving BS, data packet
   transfer between the MN and the BS is not allowed any more.  Note
   that when a MOB_HO-IND is sent out before an FBack arrives in the MN,
   it is highly probable that the MN will operate in reactive mode
   because the serving BS releases the MN's all connections and
   resources after receiving a MOB_HO-IND.  Therefore, if possible, the
   MN should exchange FBU and FBack messages with the PAR before sending
   a MOB_HO-IND to the BS so as to operate in predictive mode.

5.3.  Handover Execution

   If the MN receives the FBack message on the previous link, it runs in
   predictive mode after handover.  Otherwise, it should run in reactive
   mode.  In order for the MN to operate in predictive mode as far as
   possible after handover, implementations may allow the use of a
   Handover_Commit (HC) [802.21] primitive.  When the Handover_Commit is
   applied, the MN's IP layer may issue a Handover_Commit primitive to



Jang, et al.             Expires August 1, 2008                [Page 10]

Internet-Draft             FMIPv6 over 802.16e              January 2008


   the link layer on receiving the FBack message in the previous link.
   Until it occurs, the link-layer keeps the previous link if feasible
   and postpones sending a MOB_HO-IND message while waiting for the
   FBack message.  The Handover_Commit is a command service provided by
   [802.21] in order to force the MN to switch from an old BS to a new
   BS and the similar concept has introduced for the wireless LAN in
   [I-D.irtf-mobopts-l2-abstractions].

   After switching links, the MN synchronizes with the target BS and
   performs the 802.16e network entry procedure.  The MN exchanges the
   RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages with
   the target BS.  Some of these messages may be omitted if the
   (previously) serving BS transferred the context to the target BS over
   the backbone beforehand.  When the network entry procedure is
   completed and the link layer is ready for data transmission, it
   informs the IP layer of the fact with a Link_Up (LUP) primitive.

   Note that the Link_Up should not be sent due to changes in transient
   link conditions and less sensitive to link conditions as mentioned in
   Section 2 of [RFC4907].  However, the link may experience a
   intermittent loss.  Even in such a case, the following FMIPv6
   operation is performed only when the MN handovers to the link with
   different subnet and there is no signaling overhead as a result of a
   intermittent loss.

5.4.  Handover Completion

   When the MN's IP layer receives the Link_Up primitive from the link
   layer, it should check whether it has moved into the target network
   predicted by FMIPv6.  In case the NAR has moved to the same subnet,
   the MN does not perform the FMIPv6 operation.




















Jang, et al.             Expires August 1, 2008                [Page 11]

Internet-Draft             FMIPv6 over 802.16e              January 2008


       o If the MN discovers itself in the predicted target network
         and receives an FBack message in the previous link, the MN's
         IP layer sends a UNA (Unsolicited Neighbor Advertisement) to
         the NAR (predictive mode).

       o If the MN has moved to the target network without receiving
         an FBack message in the previous link, the IP layer sends an
         UNA and also an FBU message immediately after sending the
         UNA message (reactive mode). The NAR may provide different IP
         address by using an RA (Router Advertisement) with a NAACK
         (Neighbor Advertisement Acknowledge) option other than the
         formulated NCoA by the MN.

       o The MN may discover itself in the unpredicted network
         (erroneous movement). This is the case the MN moves to the
         network that is not the target specified in the LHI primitive.
         For the recovery from such a invalid indication which is
         mentioned in Section 2 of [RFC4907], the MN should send a new
         FBU to the PAR according to Section 5.6 of
         [I-D.ietf-mipshop-fmipv6-rfc4068bis] so that the PAR can update
         the existing binding entry and redirect the packets to the new
         confirmed location.

   In both cases of predictive and reactive modes, the MN uses the NCoA
   as a source IP address of the UNA message and starts a DAD probe for
   NCoA concurrently according to [RFC4862].

   When the NAR receives the UNA message, it deletes its proxy neighbor
   cache entry if it exists, and forwards buffered packets to the MN
   after updating the neighbor cache properly.  Detailed UNA processing
   rules are specified in Section 6.4 of
   [I-D.ietf-mipshop-fmipv6-rfc4068bis].



















Jang, et al.             Expires August 1, 2008                [Page 12]

Internet-Draft             FMIPv6 over 802.16e              January 2008


6.  The Examples of Handover Scenario

   In this section, the recommended handover procedures over 802.16e
   network are shown for both predictive and reactive modes.  It is
   assumed that the MN handovers to the network which belongs to the
   different subnet.

6.1.  Predictive Mode

   The procedure is described briefly as follows.

        1. A BS broadcasts a MOB_NBR-ADV periodically.

        2. If the MN discovers a new neighbor BS in this message, it
           may perform scanning for the BS.

        3. When a new BS is found through the MOB_NBR-ADV and
           scanning, the MN's link layer notifies it to the IP layer
           by a Link_Detected primitive.

        4. Then the MN tries to resolve the new BS's BSID to the
           associated AR by exchange of RtSolPr and PrRtAdv messages
           with the PAR.

        5. The MN initiates handover by sending a MOB_MSHO-REQ message
           to the BS and receives a MOB_BSHO-RSP from the BS.
           Alternatively, the BS may initiate handover by sending a
           MOB_BSHO-REQ to the MN.

        6. When the MN receives either a MOB_BSHO-RSP or a MOB_BSHO-REQ
           from the BS, its link layer triggers a
           Link_Handover_Imminent primitive to the IP layer.

        7. On reception of the Link_Handover_Imminent, the MN's IP layer
           identifies that the target in the Link_Handover_Imminent
           belongs to the different subnet and sends an FBU message to
           the PAR. On receiving this message, the PAR establishes
           tunnel between the PCoA and the NCoA by exchange of HI and
           HAck messages with the NAR, and forwards packets destined for
           the MN to the NCoA. During this time, the NAR may confirm
           NCoA availability in the new link via HAck.

        8. The MN receives the FBack message before its handover and
           sends a MOB_HO-IND message as a final indication of handover.
           Issue of a MOB_HO-IND optionally may be promoted by using
           a Handover_Commit command from the IP layer. Afterwards it
           operates in predictive mode in the new link.




Jang, et al.             Expires August 1, 2008                [Page 13]

Internet-Draft             FMIPv6 over 802.16e              January 2008


         9. The MN conducts handover to the target BS and performs
            the 802.16e network entry procedure.

         10. As soon as the network entry procedure is completed, the
            MN's link layer signals the IP layer with a Link_Up. On
            receiving this, the IP layer identifies that it has moved
            to a predicted target network and received the FBack message
            in the previous link. It issues a UNA to the NAR by using
            NCoA as a source IP address. At the same time, it starts to
            perform DAD for the NCoA.

         11. When the NAR receives the UNA from the MN, it delivers
            the buffered packets to the MN.

        (MN L3  MN L2)                   s-BS   PAR          t-BS   NAR
          |      |                        |      |            |      |
    1-2.  |      |<---MOB_NBR-ADV --------|      |            |      |
          |      |<-------Scanning------->|      |            |      |
    3.    |<-LD--|                        |      |            |      |
    4.    |--------------(RtSolPr)-------------->|            |      |
          |<--------------PrRtAdv----------------|            |      |
          |      |                        |      |            |      |
    5.    |      |------MOB_MSHO-REQ----->|      |            |      |
          |      |<-----MOB_BSHO-RSP------|      |            |      |
          |      |  or                    |      |            |      |
          |      |<-----MOB_BSHO-REQ------|      |            |      |
    6.    |<-LHI-|                        |      |            |      |
    7.    |------------------FBU---------------->|            |      |
          |      |                        |      |--------HI-------->|
          |      |                        |      |<------HACK--------|
          |<-----------------FBack---------------|-->         |      |
          |      |                        |    Packets==============>|
    8.    |(HC)->|-------MOB_HO-IND------>|      |            |      |
       disconnect|                        |      |            |      |
       connect   |                        |      |            |      |
    9.    |      |<-------------802.16 network entry--------->|      |
    10.   |<-LUP-|                        |      |            |      |
          |----------------------------UNA-------------------------->|
    11.   |<==================================================== Packets
          |      |                        |      |                   |

               Figure 3. Predictive Fast Handover in 802.16e

6.2.  Reactive Mode

   The procedure is described as follows in case of reactive mode.

           1.~ 7. The same as procedures of predictive mode.



Jang, et al.             Expires August 1, 2008                [Page 14]

Internet-Draft             FMIPv6 over 802.16e              January 2008


        8. The MN does not receive the FBack message before handover
           and sends a MOB_HO-IND message as a final indication of
           handover. Afterwards, it operates in reactive mode in the
           new link.

        9. The MN conducts handover to the target network and performs
           the 802.16e network entry procedure.

        10. As soon as the network entry procedure is completed, the
           MN's link layer signals the IP layer with a Link_Up. On
           receiving this, the IP layer identifies that it has moved
           to the predicted target network without receiving the FBack
           in the previous link. The MN issues a UNA to the
           NAR by using NCoA as a source IP address and starts to
           perform DAD for the NCoA. Additionally, it also sends an
           FBU to the PAR in the reactive mode.

        11. When the NAR receives the UNA and the FBU from the MN, it
           forwards the FBack to the PAR. The FBack and Packets are
           forwarded from the PAR and delivered to the MN (NCoA) through
           the NAR. The NAR may supply a different IP address than the
           NCoA by sending an RA with a NAACK option to the MN.





























Jang, et al.             Expires August 1, 2008                [Page 15]

Internet-Draft             FMIPv6 over 802.16e              January 2008


       (MN L3  MN L2)                   s-BS   PAR          t-BS   NAR
          |      |                        |      |            |      |
    1-2.  |      |<---MOB_NBR-ADV & Scan--|      |            |      |
          |      |<-------Scanning------->|      |            |      |
    3.    |<-LD--|                        |      |            |      |
    4.    |--------------(RtSolPr)-------------->|            |      |
          |<--------------PrRtAdv----------------|            |      |
          |      |                        |      |            |      |
    5.    |      |------MOB_MSHO-REQ----->|      |            |      |
          |      |<-----MOB_BSHO-RSP------|      |            |      |
          |      |  or                    |      |            |      |
          |      |<-----MOB_BSHO-REQ------|      |            |      |
    6.    |<-LHI-|                        |      |            |      |
    7.    |--------FBU----X--->           |      |            |      |
    8.    |      |-------MOB_HO-IND------>|      |            |      |
       disconnect|                        |      |            |      |
       connect   |                        |      |            |      |
    9.    |      |<-----------802.16 network entry----------->|      |
    10.   |<-LUP-|                        |      |            |      |
          |----------------------------UNA-------------------------->|
          |----------------------------FBU--------------------------)|
    11.   |      |                        |      |<-------FBU-------)|
          |      |                        |      |<-----HI/HAck----->|
          |      |                        |      |  (if necessary)   |
          |      |                        | Packets & FBack=========>|
          |<=========================================================|
          |      |                        |      |            |      |

                Figure 4. Reactive Fast Handover in 802.16e






















Jang, et al.             Expires August 1, 2008                [Page 16]

Internet-Draft             FMIPv6 over 802.16e              January 2008


7.  Security Considerations

   The security consideration of the FMIPv6 specification
   [I-D.ietf-mipshop-fmipv6-rfc4068bis] is applicable to this document.
   Particularly, the 802.16e architecture supports a number of mandatory
   authentication mechanisms, for example, EAP-TTLS, EAP-SIM and EAP-AKA
   and that will allow secure handover operation of the MN.












































Jang, et al.             Expires August 1, 2008                [Page 17]

Internet-Draft             FMIPv6 over 802.16e              January 2008


8.  IANA Consideration

   This document does not require any new number assignment from IANA.
















































Jang, et al.             Expires August 1, 2008                [Page 18]

Internet-Draft             FMIPv6 over 802.16e              January 2008


9.  Acknowledgment

   Many thanks IETF Mobility Working Group members of KWISF (Korea
   Wireless Internet Standardization Forum) for their efforts on this
   work.  In addition, we would like to thank Alper E. Yegin, Jinhyeock
   Choi, Rajeev Koodli, Soininen Jonne, Gabriel Montenegro, Singh Ajoy,
   Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli and Ved Kafle who
   have provided the technical advice.











































Jang, et al.             Expires August 1, 2008                [Page 19]

Internet-Draft             FMIPv6 over 802.16e              January 2008


10.  References

10.1.  Normative References

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

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

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [802.16e]  IEEE 802.16 TGe Working Document, "Amendment 2: Physical
              and Medium Access Control Layers for Combined Fixed and
              Mobile Operation in Licensed Bands and Corrigendum 1",
              IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/
              Cor 1-2005, February 2006.

10.2.  Informative References

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

   [I-D.irtf-mobopts-l2-abstractions]
              Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast
              Handover", draft-irtf-mobopts-l2-abstractions-05 (work in
              progress), January 2008.

   [RFC4260]  McCann, P., "Mobile IPv6 Fast Handovers for 802.11
              Networks", RFC 4260, November 2005.

   [RFC4907]  Aboba, B., "Architectural Implications of Link
              Indications", RFC 4907, June 2007.

   [802.21]   IEEE 802.21 Working Group Document,"Draft IEEE Standard
              for Local and Metropolitan Area Networks: Media
              Independent Handover Services", IEEE P802.21/D7.1,
              August 2007.

   [SH-802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover
              Mechanism for IEEE 802.16e Broadband Wireless Access",
              International Conference on Computational Science,
              vol. 2, pp. 527-534, 2005.





Jang, et al.             Expires August 1, 2008                [Page 20]

Internet-Draft             FMIPv6 over 802.16e              January 2008


Authors' Addresses

   Hee-Jin Jang
   Samsung Advanced Institute of Technology
   P.O. Box 111
   Suwon 440-600
   Korea

   Email: heejin.jang@samsung.com


   Junghoon Jee
   Electronics and Telecommunications Research Institute
   161 Gajeong-dong, Yuseong-gu
   Daejon 305-350
   Korea

   Email: jhjee@etri.re.kr


   Youn-Hee Han
   Korea University of Technology and Education

   Email: yhhan@kut.ac.kr


   Soohong Daniel Park
   Samsung Electronics
   416 Maetan-3dong, Yeongtong-gu
   Suwon 442-742
   Korea

   Email: soohong.park@samsung.com


   Jaesun Cha
   Electronics and Telecommunications Research Institute
   161 Gajeong-dong, Yuseong-gu
   Daejon 305-350
   Korea

   Email: jscha@etri.re.kr









Jang, et al.             Expires August 1, 2008                [Page 21]

Internet-Draft             FMIPv6 over 802.16e              January 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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


Intellectual Property

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

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

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


Acknowledgment

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





Jang, et al.             Expires August 1, 2008                [Page 22]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/