GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5270

Network Working Group H. Jang Request for Comments: 5270 SAMSUNG Category: Informational J. Jee

                                                                  ETRI
                                                                Y. Han
                                                                   KUT
                                                               S. Park
                                                   SAMSUNG Electronics
                                                                J. Cha
                                                                  ETRI
                                                             June 2008
       Mobile IPv6 Fast Handovers over IEEE 802.16e Networks

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Abstract

 This document describes how a Mobile IPv6 Fast Handover can be
 implemented on link layers conforming to the IEEE 802.16e suite of
 specifications.  The proposed scheme tries to achieve seamless
 handover by exploiting the link-layer handover indicators and thereby
 synchronizing the IEEE 802.16e handover procedures with the Mobile
 IPv6 fast handover procedures efficiently.

Jang, et al. Informational [Page 1] RFC 5270 FMIPv6 over 802.16e June 2008

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . .  4
 4.  Network Topology Acquisition and Network Selection . . . . . .  5
 5.  Interaction between FMIPv6 and IEEE 802.16e  . . . . . . . . .  6
   5.1.  Access Router Discovery  . . . . . . . . . . . . . . . . .  6
   5.2.  Handover Preparation . . . . . . . . . . . . . . . . . . .  7
   5.3.  Handover Execution . . . . . . . . . . . . . . . . . . . .  8
   5.4.  Handover Completion  . . . . . . . . . . . . . . . . . . .  9
 6.  The Examples of Handover Scenario  . . . . . . . . . . . . . . 10
   6.1.  Predictive Mode  . . . . . . . . . . . . . . . . . . . . . 10
   6.2.  Reactive Mode  . . . . . . . . . . . . . . . . . . . . . . 12
 7.  IEEE 802.21 Considerations . . . . . . . . . . . . . . . . . . 14
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
 9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
   10.2. Informative References . . . . . . . . . . . . . . . . . . 16

1. Introduction

 Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC5268] was proposed to
 complement the Mobile IPv6 (MIPv6) [RFC3775] by reducing the handover
 latency for the real-time traffic.  FMIPv6 assumes the support from
 the link-layer technology; however, the specific link-layer
 information available and its available timing differs according to
 the particular link-layer technology in use, as pointed out in
 [RFC4260], which provides an FMIPv6 solution for the IEEE 802.11
 networks.  So, this document is proposed to provide an informational
 guide to the developers about how to optimize the FMIPv6 handover
 procedures, specifically in the IEEE 802.16e networks
 [IEEE802.16][IEEE802.16e].
 The proposed scheme achieves seamless handover by exploiting the
 link-layer handover indicators and designing an efficient
 interleaving scheme of the 802.16e and the FMIPv6 handover
 procedures.  The scheme targets a hard handover, which is the default
 handover type of IEEE 802.16e.  For the other handover types, i.e.,
 the Macro Diversity Handover (MDHO) and Fast Base Station Switching
 (FBSS), the base stations in the same diversity set are likely to
 belong to the same subnet for diversity, and FMIPv6 might not be
 needed.  Regarding the MDHO and the FBSS deployment with FMIPv6,
 further discussion will be needed and is not in the scope of this
 document.

Jang, et al. Informational [Page 2] RFC 5270 FMIPv6 over 802.16e June 2008

 We begin with a summary of handover procedures of [IEEE802.16e] and
 then present the optimized complete FMIPv6 handover procedures by
 using the link-layer handover indicators.  The examples of handover
 scenarios are described for both the predictive mode and reactive
 mode.

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 [RFC5268].
 The following terms come from the IEEE 802.16e specification
 [IEEE802.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.

Jang, et al. Informational [Page 3] RFC 5270 FMIPv6 over 802.16e June 2008

3. IEEE 802.16e Handover Overview

 Compared with the handover in the WLAN (Wireless Local Area Network),
 the IEEE 802.16e handover mechanism consists of more steps since the
 802.16e embraces the functionality for elaborate parameter adjustment
 and procedural flexibility.
 When a mobile node (MN) stays in a link, it listens to the Layer 2
 neighbor advertisement messages, named MOB_NBR-ADV, from its serving
 base station (BS).  A BS broadcasts them periodically to identify the
 network and announce the characteristics of neighbor BSs.  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, Quality-of-Service (QoS) level, service
 price, etc.
 The handover procedure is conceptually divided into two steps:
 "handover preparation" and "handover execution" [SH802.16e].  The
 handover preparation can be initiated by either an MN or a 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 to handover, it notifies its intent by sending a MOB_MSHO-REQ
 message to the serving BS (s-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 (t-BS) over backbone when the target is decided.
 Alternatively, the BS may trigger handover with a MOB_BSHO-REQ
 message.
 After handover preparation, handover execution starts.  The MN sends
 a MOB_HO-IND message to the serving BS as a final indication of its
 handover.  Once it 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 procedures, 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 details
 of the 802.16 handover procedures, refer to Section 6.3.22 of
 [IEEE802.16e].  After completing registration, the target BS starts

Jang, et al. Informational [Page 4] RFC 5270 FMIPv6 over 802.16e June 2008

 to serve the MN and communication via target BS is available.
 However, in case the MN moves to a different subnet, it should
 reconfigure a new IP address and reestablish an IP connection.  To
 resume the active session of the previous link, the MN should also
 perform IP layer handover.

4. Network Topology Acquisition and Network Selection

 This section describes how discovery of adjacent networks and
 selection of target network work in the IEEE 802.16e for background
 information.
 An MN can learn the network topology and acquire the link information
 in several ways.  First of all, it can do that via L2 neighbor
 advertisements.  A BS supporting mobile functionality shall broadcast
 a MOB_NBR-ADV message periodically that includes the network topology
 information (its maximum interval is 1 second).  This message
 includes BSIDs and channel information of neighbor BSs, and it 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
 [IEEE802.16e].
 Besides the methods provided by 802.16e, the MN may rely on other
 schemes.  For instance, the topology information may be provided
 through the MIIS (Media Independent Information Service)
 [IEEE802.21], which has been developed by the IEEE 802.21 working
 group.  The MIIS is a framework by which the MN or network can obtain
 network information to facilitate network selection and handovers.

Jang, et al. Informational [Page 5] RFC 5270 FMIPv6 over 802.16e June 2008

 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.

5. Interaction between FMIPv6 and IEEE 802.16e

 In this section, a set of primitives is introduced for an efficient
 interleaving of the IEEE 802.16e and the FMIPv6 procedures as below.
 The following sections present the handover procedures in detail by
 using them.
    o NEW_LINK_DETECTED (NLD)
       A trigger from the link layer to the IP layer in the MN to
       report that a new link has been detected.
    o LINK_HANDOVER_IMPEND (LHI)
       A trigger from the link layer to the IP layer in the MN to
       report that a link-layer handover decision has been made and
       its execution is imminent.
    o LINK_SWITCH (LSW)
       A control command from the IP layer to the link layer in the MN
       in order to force the MN to switch from an old BS to a new BS.
    o LINK_UP (LUP)
       A trigger from the link layer to the IP layer in the MN to
       report that the MN completes the link-layer connection
       establishment with a new BS.

5.1. Access Router Discovery

 Once a new BS is detected through reception of a MOB_NBR-ADV and
 scanning, an MN may try to learn the associated access router (AR)
 information as soon as possible.  In order to enable its quick
 discovery in the IP layer, the link layer (802.16) triggers a
 NEW_LINK_DETECTED primitive to the IP layer (FMIPv6) on detecting a
 new BS.
 Receiving the NEW_LINK_DETECTED from the link layer, the IP layer
 tries to learn the associated AR information by exchanging an RtSolPr
 (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy
 Router Advertisement) with the PAR (Previous Access Router).

Jang, et al. Informational [Page 6] RFC 5270 FMIPv6 over 802.16e June 2008

 According to [RFC5268], the MN may send an RtSolPr at any convenient
 time.  However, this proposal recommends that, if feasible, the MN
 send it as soon as possible after receiving the NEW_LINK_DETECTED for
 quick router discovery because detection of a new BS usually implies
 MN's movement, which may result in handover.
 Transmission of RtSolPr messages may cause the signaling overhead
 problem that is mentioned in Section 2 of [RFC4907].  To rate-limit
 the retransmitted RtSolPr messages, FMIPv6 provides a back-off
 mechanism.  It is also possible that attackers may forge a MOB_NBR-
 ADV message so that it can contain a bunch of bogus BSIDs or may send
 a flood of MOB_NBR-ADV messages each of which contains different
 BSIDs.  This problem is mentioned in Section 8.

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 will
 receive 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_IMPEND in order to signal the IP layer of
 arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly.  At this time, the
 target BS decided in the link layer is delivered to the IP layer as a
 parameter of the primitive.  The primitive is used to report that a
 link-layer handover decision has been made and its execution is
 imminent.  It can be helpfully used for FMIPv6 as an indication to
 start the handover preparation procedure, that is to send an FBU
 (Fast Binding Update) 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 stay in the current network after sending an FBU,
 Section 2 of [RFC4907] advises the use of a combination of signal
 strength data with other techniques rather than relying only on
 signal strength for handover decision.  For example, the
 LINK_HANDOVER_IMPEND 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 LINK_HANDOVER_IMPEND, it checks
 whether or not the specified target network belongs to a different
 subnet based on the information collected during the 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

Jang, et al. Informational [Page 7] RFC 5270 FMIPv6 over 802.16e June 2008

 formulates a prospective NCoA (New Care-of Address) 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 (New Access Router) process it according to [RFC5268].  The PAR
 sets up a tunnel between the PCoA (Previous Care-of Address) and NCoA
 by exchanging HI (Handover Initiate) and HAck (Handover Acknowledge)
 messages with the NAR, forwarding the packets destined for the MN to
 the NCoA.  The NCoA is confirmed or re-assigned by the NAR in the
 HAck and, finally delivered to the MN through the FBack (Fast Binding
 Acknowledgment) 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 no longer allowed.  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 all the MN's 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 an 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 use of a
 LINK_SWITCH primitive.  The LINK_SWITCH is a command 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 [RFC5184].  When it is
 applied, the MN's IP layer issues a LINK_SWITCH primitive to the link
 layer on receiving the FBack message in the previous link.  Until it
 occurs, the link layer keeps the current (previous) link if feasible
 and postpones sending a MOB_HO-IND message while waiting for the
 FBack message.
 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 primitive.

Jang, et al. Informational [Page 8] RFC 5270 FMIPv6 over 802.16e June 2008

 Section 2 of [RFC4907] recommends that link indications should be
 designed with built-in damping.  The LINK_UP primitive defined in
 this document is generated by the link layer state machine based on
 the 802.16e link layer message exchanges, that is, the IEEE 802.16e
 network entry and the service flow creation procedures.  Therefore,
 the LINK_UP is typically less sensitive to changes in transient link
 conditions.  The link may experience an intermittent loss.  Even in
 such a case, the following FMIPv6 operation is performed only when
 the MN handovers to the link with a 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 a LINK_UP primitive from the link
 layer, it should check whether it has moved into the target network
 predicted by FMIPv6.  In case the target BS is within the same
 subnet, the MN does not perform the FMIPv6 operation.
  • 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 an UNA (Unsolicited Neighbor Advertisement) to the
       NAR (predictive mode).
  • 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 a different IP
       address by using an RA (Router Advertisement) with a NAACK
       (Neighbor Advertisement Acknowledge) option other than the
       formulated NCoA by the MN.
  • The MN may discover itself in the unpredicted network

(erroneous movement). If this is the case, the MN moves to the

       network that is not the target specified in the
       LINK_HANDOVER_IMPEND primitive.  For the recovery from such an
       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 [RFC5268] 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, once the MN has moved
 into the new link, it uses the NCoA formulated by the MN as a source
 address of the UNA, irrespective of NCoA availability.  It then
 starts a Duplicate Address Detection (DAD) probe for NCoA according
 to [RFC4862].  In case the NAR provides the MN with a new NCoA, the
 MN MUST use the provided NCoA instead of the NCoA formulated by the
 MN.

Jang, et al. Informational [Page 9] RFC 5270 FMIPv6 over 802.16e June 2008

 When the NAR receives an 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 [RFC5268].

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 that belongs to a
 different subnet.
 In the following figures, the messages between the MN's Layer 2 (MN
 L2) and the BS are the IEEE 802.16 messages, while messages between
 the MN's Layer 3 (MN L3) and the PAR and messages between PAR and NAR
 are the FMIPv6 messages.  The messages between the MN L2 and the MN
 L3 are primitives introduced in this document.

6.1. Predictive Mode

 The handover procedures in the predictive mode are briefly described
 as follows.  Figure 3 illustrates these procedures.
    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
         NEW_LINK_DETECTED primitive.
    4.   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_IMPEND
         primitive to the IP layer.

Jang, et al. Informational [Page 10] RFC 5270 FMIPv6 over 802.16e June 2008

    7.   On reception of the LINK_HANDOVER_IMPEND, the MN's IP layer
         identifies that the target delivered along with the
         LINK_HANDOVER_IMPEND belongs to a 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 it
         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 may be promoted optionally by using a
         LINK_SWITCH command from the IP layer.  Afterwards it
         operates in predictive mode in the new link.
    9.   The MN conducts handover to the target BS and performs the
         IEEE 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 an UNA to the NAR by using the
         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.

Jang, et al. Informational [Page 11] RFC 5270 FMIPv6 over 802.16e June 2008

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

6.2. Reactive Mode

 The handover procedures in the reactive mode are described as
 follows.  Figure 4 is illustrating these procedures.
    1. ~ 7.  The same as procedures of predictive mode.
    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.

Jang, et al. Informational [Page 12] RFC 5270 FMIPv6 over 802.16e June 2008

    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 an UNA to the NAR by using NCoA
         as a source IP address and starts to perform DAD for the
         NCoA.  Additionally, it 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.
     (MN L3  MN L2)                   s-BS   PAR          t-BS   NAR
        |      |                        |      |            |      |
  1-2.  |      |<---MOB_NBR-ADV & Scan--|      |            |      |
        |      |<-------Scanning------->|      |            |      |
  3.    |<-NLD-|                        |      |            |      |
  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.    |      |<---------IEEE 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. Informational [Page 13] RFC 5270 FMIPv6 over 802.16e June 2008

7. IEEE 802.21 Considerations

 It is worth noting that great research has been conducted on defining
 generic services in the IEEE 802.21 working group that facilitate
 handovers between heterogeneous access links.  The standard works are
 named as a Media Independent Handover (MIH) Service [IEEE802.21], and
 propose three kinds of services: Media Independent Event Service
 (MIES), Media Independent Command Service (MICS), and Media
 Independent Information Service (MIIS).
 An MIES defines the events triggered from lower layers (physical and
 link) to higher layers (network and above) in order to report changes
 of physical and link-layer conditions.  On the other hand, an MICS
 supports the commands sent from higher layers to lower layers, and it
 provides users with a way of managing the link behavior relevant to
 handovers and mobility.  An MIIS provides a framework by which the MN
 or network can obtain network information to facilitate network
 selection and handovers.
 Although the purpose of IEEE 802.21 has been developed to enhance the
 user experience of MNs roaming between heterogeneous networks, the
 results may be utilized to optimize the handover performance in a
 homogeneous network.  When the MIH primitives are available for
 handover in the 802.16e network, the MN can use them instead of the
 primitives proposed in this document.  Table 1 shows examples of the
 mapping between the proposed primitives and the MIH primitives.
         +-------------------------+-------------------------+
         |   Proposed primitives   |      MIH primitives     |
         +===================================================+
         |  NEW_LINK_DETECTED      |  LINK_DETECTED          |
         +---------------------------------------------------+
         |  LINK_HANDOVER_IMPEND   |  LINK_HANDOVER_IMMINENT |
         +---------------------------------------------------+
         |  LINK_SWITCH            |  HANDOVER_COMMIT        |
         +---------------------------------------------------+
         |  LINK_UP                |  LINK_UP                |
         +---------------------------------------------------+
          Table 1. The Proposed Primitives and MIH Primitives

8. Security Considerations

 The primitives defined in this document are used only for local
 indication inside of the MN, so no security mechanism is required to
 protect those primitives.  However, FMIPv6 messages and IEEE 802.16e
 messages, which may trigger the primitives, need to be protected.

Jang, et al. Informational [Page 14] RFC 5270 FMIPv6 over 802.16e June 2008

 Security considerations of the FMIPv6 specification [RFC5268] are
 applicable to this document.  It is also worthwhile to note that the
 IEEE802.16e has a security sub-layer that provides subscribers with
 privacy and authentication over the broadband wireless network.  This
 layer has two main component protocols: a privacy key management
 protocol (PKM) for key management and authentication and an
 encapsulation protocol for encrypting data.  From the perspective of
 the 802.16e, FMIPv6 messages are considered as data and are delivered
 securely by using those protocols.
 However, some of IEEE 802.16e management messages are sent without
 authentication.  For example, there is no protection to secure
 802.16e broadcast messages.  It may be possible for the attacker to
 maliciously forge a MOB_NBR-ADV message so that it contains the bogus
 BSIDs, or send a flood of MOB_NBR-ADV messages having different bogus
 BSIDs toward the MN.  As a result, the MN may trigger a bunch of
 NEW_LINK_DETECTED primitives and send useless consecutive RtSolPr
 messages to the PAR, finally resulting in wasting the air resources.
 Therefore, the MN SHOULD perform scanning when detecting new BSs in
 the received MOB_NBR-ADV messages in order to assure the included
 neighbor information.
 It is also possible that attackers try a DoS (Denial-of-Service)
 attack by sending a flood of MOB_BSHO-REQ messages and triggering
 LINK_HANDOVER_IMPEND primitives in the MN.  But the IEEE 802.16e
 provides a message authentication scheme for management messages
 involved in handover as well as network entry procedures by using a
 message authentication code (MAC) such as HMAC/CMAC (hashed/cipher
 MAC).  Thus, those management messages are protected from the
 malicious use by attackers who intend to trigger LINK_HANDOVER_IMPEND
 or LINK_UP primitives in the MN.

9. Acknowledgments

 Many thanks to the 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, Jonne Soininen, Gabriel Montenegro,
 Singh Ajoy, Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli, and
 Ved Kafle who have provided technical advice.

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.

Jang, et al. Informational [Page 15] RFC 5270 FMIPv6 over 802.16e June 2008

 [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.
 [RFC5268]      Koodli, R., Ed., "Mobile IPv6 Fast Handovers",
                RFC 5268, June 2008.
 [IEEE802.16]   "IEEE Standard for Local and Metropolitan Area
                Networks, Part 16: Air Interface for Fixed Broadband
                Wireless Access Systems", IEEE Std 802.16-2004,
                October 2004.
 [IEEE802.16e]  "IEEE Standard for Local and Metropolitan Area
                Networks, 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

 [RFC4260]      McCann, P., "Mobile IPv6 Fast Handovers for 802.11
                Networks", RFC 4260, November 2005.
 [RFC5184]      Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
                Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
                (L3)-Driven Fast Handover", RFC 5184, May 2008.
 [RFC4907]      Aboba, B., "Architectural Implications of Link
                Indications", RFC 4907, June 2007.
 [IEEE802.21]   "Draft IEEE Standard for Local and Metropolitan Area
                Networks: Media Independent Handover Services", IEEE
                Std P802.21 D9.0, February 2008.
 [SH802.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. Informational [Page 16] RFC 5270 FMIPv6 over 802.16e June 2008

Authors' Addresses

 Heejin Jang
 SAMSUNG Advanced Institute of Technology
 P.O. Box 111
 Suwon 440-600
 Korea
 EMail: heejin.jang@gmail.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
 Gajeon-ri, Byeongcheon-myeon
 Cheonan 330-708
 Korea
 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. Informational [Page 17] RFC 5270 FMIPv6 over 802.16e June 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Jang, et al. Informational [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5270.txt · Last modified: 2008/06/18 19:13 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki