From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5270.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc5270.txt (limited to 'doc/rfc/rfc5270.txt') 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] + -- cgit v1.2.3