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.
AbstractThis 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.
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 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.
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. 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.
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
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. 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.
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.
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. 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
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. 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.
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. 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.
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]. 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. 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.
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.
(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 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.
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
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
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. [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. [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. [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.
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 firstname.lastname@example.org.