doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5270.txt b/doc/rfc/rfc5270.txt
new file mode 100644
index 0000000..f55a14e
--- /dev/null
+++ b/doc/rfc/rfc5270.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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]
+