idnits 2.17.1 draft-ietf-mipshop-fh80216e-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 809. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2008) is 5853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fmipv6-rfc4068bis-06 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group Hee-Jin Jang 3 Internet-Draft Samsung AIT 4 Intended status: Informational Junghoon Jee 5 Expires: September 11, 2008 ETRI 6 Youn-Hee Han 7 KUT 8 Soohong Daniel Park 9 Samsung Electronics 10 Jaesun Cha 11 ETRI 12 March 10, 2008 14 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks 15 draft-ietf-mipshop-fh80216e-07.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 11, 2008. 42 Abstract 44 This document describes how a Mobile IPv6 Fast Handover can be 45 implemented on link layers conforming to the IEEE 802.16e suite of 46 specifications. The proposed scheme tries to achieve seamless 47 handover by exploiting the link-layer handover indicators and thereby 48 synchronizing the IEEE 802.16e handover procedures with the Mobile 49 IPv6 fast handover procedures efficiently. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . . 5 56 4. Network Topology Acquisition and Network Selection . . . . . . 7 57 5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 8 58 5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 8 59 5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 9 60 5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 10 61 5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 11 62 6. The Examples of Handover Scenario . . . . . . . . . . . . . . 12 63 6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 12 64 6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 14 65 7. IEEE 802.21 Considerations . . . . . . . . . . . . . . . . . . 17 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 19 68 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 20 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 73 Intellectual Property and Copyright Statements . . . . . . . . . . 23 75 1. Introduction 77 Mobile IPv6 Fast Handover protocol (FMIPv6) 78 [I-D.ietf-mipshop-fmipv6-rfc4068bis] was proposed to complement the 79 Mobile IPv6 (MIPv6) [RFC3775] by reducing the handover latency for 80 the real-time traffic. FMIPv6 assumes the support from the link- 81 layer technology, however, the specific link-layer information 82 available and its available timing differs according to the 83 particular link-layer technology in use, as pointed out in [RFC4260] 84 which provides an FMIPv6 solution for the IEEE 802.11 networks. So, 85 this document is proposed to provide an informational guide to the 86 developers about how to optimize the FMIPv6 handover procedures, 87 specifically in the IEEE 802.16e networks [IEEE 802.16][IEEE 88 802.16e]. 90 The proposed scheme achieves seamless handover by exploiting the 91 link-layer handover indicators, and designing an efficient 92 interleaving scheme of the 802.16e and the FMIPv6 handover 93 procedures. The scheme is targeting a hard handover which is the 94 default handover type of IEEE 802.16e. For the other handover types, 95 i.e., the Macro Diversity Handover (MDHO) and Fast Base Station 96 Switching (FBSS), the base stations in the same diversity set are 97 likely to belong to the same subnet for diversity, and FMIPv6 might 98 be no needed. This needs further discussion regarding the MDHO and 99 the FBSS deployment. 101 We begin with a summary of handover procedures of [IEEE 802.16e], and 102 then present the optimized complete FMIPv6 handover procedures by 103 using the link-layer handover indicators. The examples of handover 104 scenarios are described for both predictive mode and reactive mode 105 lastly. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document is to be interpreted as described in [RFC2119]. 113 Most of terms used in this document are defined in MIPv6 [RFC3775] 114 and FMIPv6 [I-D.ietf-mipshop-fmipv6-rfc4068bis]. 116 The following terms come from IEEE 802.16e specification [IEEE 117 802.16e]. 119 MOB_NBR-ADV 121 An IEEE 802.16e neighbor advertisement message sent 122 periodically by a base station. 124 MOB_MSHO-REQ 126 An IEEE 802.16e handover request message sent by a mobile node. 128 MOB_BSHO-RSP 130 An IEEE 802.16e handover response message sent by a base 131 station. 133 MOB_BSHO-REQ 135 An IEEE 802.16e handover request message sent by a base 136 station. 138 MOB_HO-IND 140 An IEEE 802.16e handover indication message sent by a mobile 141 node. 143 BSID 145 An IEEE 802.16e base station identifier. 147 3. IEEE 802.16e Handover Overview 149 Compared with the handover in the WLAN (Wireless Local Area Network), 150 the IEEE 802.16e handover mechanism consists of more steps since the 151 802.16e embraces the functionality for elaborate parameter adjustment 152 and procedural flexibility. 154 When a mobile node (MN) stays in a link, it listens to the layer 2 155 neighbor advertisement messages, named a MOB_NBR-ADV, from its 156 serving base station (BS). A BS broadcasts them periodically to 157 identify the network and announces the characteristics of neighbor 158 BSs. Once receiving this, the MN decodes this message to find out 159 information about the parameters of neighbor BSs for its future 160 handover. With the provided information in a MOB_NBR-ADV, the MN may 161 minimize the handover latency by obtaining the channel number of 162 neighbors and reducing the scanning time, or may select the better 163 target BS based on the signal strength, QoS level, service price, 164 etc. 166 The handover procedure is conceptually divided into two steps: 167 "handover preparation" and "handover execution" [SH-802.16e]. The 168 handover preparation can be initiated by either an MN or a BS. 169 During this period, neighbors are compared by the metrics such as 170 signal strength or QoS parameters and a target BS is selected among 171 them. If necessary, the MN may try to associate (initial ranging) 172 with candidate BSs to expedite a future handover. Once the MN 173 decides handover, it notifies its intent by sending a MOB_MSHO-REQ 174 message to the serving BS (s-BS). The BS then replies with a 175 MOB_BSHO-RSP containing the recommended BSs to the MN after 176 negotiating with candidates. Optionally it may confirm handover to 177 the target BS (t-BS) over backbone when the target is decided. The 178 BS alternatively may trigger handover with a MOB_BSHO-REQ message. 180 After handover preparation, handover execution starts. The MN sends 181 a MOB_HO-IND message to the serving BS as a final indication for its 182 handover. Once it makes a new attachment, it conducts 802.16e 183 ranging through which it can acquire physical parameters from the 184 target BS, tuning its parameters to the target BS. After ranging 185 with the target BS successfully, the MN negotiates basic capabilities 186 such as maximum transmit power and modulator/demodulator type. It 187 then performs authentication and key exchange procedures, and finally 188 registers with the target BS. If the target BS has already learned 189 some contexts such as authentication or capability parameters through 190 backbone, it may omit the corresponding procedures. For the details 191 of the 802.16 handover procedures, refer to Section 6.3.22 of [IEEE 192 802.16e]. After completing registration, the target BS starts to 193 serve the MN and communication via target BS is available. However, 194 in case the MN moves to a different subnet, it should re-configure a 195 new IP address and re-establish an IP connection. To resume the 196 active session of the previous link, the MN should perform IP layer 197 handover additionally. 199 4. Network Topology Acquisition and Network Selection 201 This section describes how discovery of adjacent networks and 202 selection of target network work in the IEEE 802.16e for background 203 information. 205 An MN can learn the network topology and acquire the link information 206 in several ways. First of all, it can do that via L2 neighbor 207 advertisements. A BS supporting mobile functionality shall broadcast 208 a MOB_NBR-ADV message periodically which includes the network 209 topology information. (its maximum interval is 1 second.). This 210 message includes BSIDs and channel information of neighbor BSs and is 211 used to facilitate the MN's synchronization with neighbor BSs. An MN 212 can collect the necessary information of the neighbor BSs through 213 this message for its future handover. 215 Another method for acquisition of network topology is scanning, which 216 is the process to seek and monitor available BSs in order to find 217 suitable handover targets. While a MOB_NBR-ADV message includes 218 static information about neighbor BSs, scanning provides rather 219 dynamic parameters such as link quality parameters. Since the 220 MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically 221 and scanning provides a way to sort out some adequate BSs, it is 222 recommended that when new BSs are found in the advertisement, the MN 223 identifies them via scanning and resolves their BSIDs to the 224 information of the subnet where the BS is connected. The 225 association, an optional initial ranging procedure occurring during 226 scanning, is one of the helpful methods to facilitate the impending 227 handover. The MN is able to get ranging parameters and service 228 availability information for the purpose of proper selection of the 229 target BS and expediting a potential future handover to it. The 230 detailed explanation of association is described in Section 6.3.22 of 231 [IEEE 802.16e]. 233 Besides the methods provided by 802.16e, the MN may rely on other 234 schemes. For instance, the topology information may be provided 235 through the MIIS (Media Independent Information Service) [IEEE 236 802.21] which has been developed by IEEE 802.21 working group. The 237 MIIS is a framework by which the MN or network can obtain network 238 information to facilitate network selection and handovers. 240 After learning about neighbors, the MN may compare them to find a BS 241 which can serve better than the serving BS. The target BS may be 242 determined by considering various criteria such as required QoS, 243 cost, user preference, and policy. How to select the target BS is 244 not in the scope of this document. 246 5. Interaction between FMIPv6 and IEEE 802.16e 248 In this section, a set of primitives is introduced for an efficient 249 interleaving of the IEEE 802.16e and the FMIPv6 procedures as below. 250 The following sections present the handover procedures in detail by 251 using them. 253 o NEW_LINK_DETECTED (NLD) 255 A trigger from the link layer to the IP layer in the MN to 256 report that a new link is detected. 258 o LINK_HANDOVER_IMPEND (LHI) 260 A trigger from the link layer to the IP layer in the MN to 261 report that a link layer handover decision has been made and 262 its execution is imminent. 264 o LINK_SWITCH (LSW) 266 A control command from the IP layer to the link layer in the MN 267 in order to force the MN to switch from an old BS to a new BS. 269 o LINK_UP (LUP) 271 A trigger from the link layer to the IP layer in the MN to 272 report that the MN completes the link layer connection 273 establishment with a new BS. 275 5.1. Access Router Discovery 277 Once a new BS is detected through reception of a MOB_NBR-ADV and 278 scanning, an MN may try to learn the associated access router (AR) 279 information as soon as possible. In order to enable its quick 280 discovery in the IP layer, the link layer (802.16) triggers a 281 NEW_LINK_DETECTED primitive to the IP layer (FMIPv6) on detecting a 282 new BS. 284 Receiving the NEW_LINK_DETECTED from the link layer, the IP layer 285 tries to learn the associated AR information by exchanging an RtSolPr 286 (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy 287 Router Advertisement) with the PAR (Previous Access Router). 288 According to [I-D.ietf-mipshop-fmipv6-rfc4068bis], the MN may send an 289 RtSolPr at any convenient time. However this proposal recommends 290 that, if feasible, the MN send it as soon as possible after receiving 291 the NEW_LINK_DETECTED for quick router discovery because detection of 292 a new BS usually implies MN's movement, which may result in handover. 294 Transmission of RtSolPr messages may cause signaling overhead problem 295 which is mentioned in Section 2 of [RFC4907]. To rate-limit the 296 retransmitted RtSolPr messages, FMIPv6 provides a back-off mechanism. 297 It is also possible that attackers may forge a MOB_NBR-ADV message so 298 that it can contain a bunch of bogus BSIDs, or may send a flood of 299 MOB_NBR-ADV messages each of which contains different BSIDs. This 300 problem is mentioned in Section 8. 302 5.2. Handover Preparation 304 When the MN decides to change links based on its policy such as the 305 degrading signal strength or increasing packet loss rate, it 306 initiates handover by sending a MOB_MSHO-REQ to the BS and will 307 receive a MOB_BSHO-RSP from the BS as a response. Alternatively the 308 BS may initiate handover by sending a MOB_BSHO-REQ to the MN. 310 On receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ, the link layer 311 triggers a LINK_HANDOVER_IMPEND in order to signal the IP layer of 312 arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly. At this time, the 313 target BS decided in the link layer is delivered to the IP layer as a 314 parameter of the primitive. The primitive is used to report that a 315 link layer handover decision has been made and its execution is 316 imminent. It can be helpfully used for FMIPv6 as an indication to 317 start handover preparation procedure, that is to send an FBU (Fast 318 Binding Update) message to the PAR. 320 To avoid erroneous results due to unreliable and inconsistent 321 characteristics of link, for instance, to move to the unpredicted 322 network or to keep staying in the current network after sending an 323 FBU, Section 2 of [RFC4907] advises to use combination of signal 324 strength data with other techniques rather than relying only on 325 signal strength for handover decision. For example, the 326 LINK_HANDOVER_IMPEND may be sent after validating filtered signal 327 strength measurements with other indications of link loss such as 328 lack of beacon reception. 330 Once the IP layer receives the LINK_HANDOVER_IMPEND, it checks 331 whether the specified target network belongs to a different subnet or 332 not based on the information collected during Access Router Discovery 333 step. If the target proves to be in the same subnet, the MN can 334 continue to use the current IP address after handover and there is no 335 need to perform FMIPv6. Otherwise, the IP layer formulates a 336 prospective NCoA (New Care-of-Address) with the information provided 337 in the PrRtAdv message and sends an FBU message to the PAR. 339 When the FBU message arrives in the PAR successfully, the PAR and the 340 NAR (New Access Router) process it according to 341 [I-D.ietf-mipshop-fmipv6-rfc4068bis]. The PAR sets up a tunnel 342 between the PCoA (Previous Care-of-Address) and NCoA by exchanging HI 343 (Handover Initiate) and HAck (Handover Acknowledge) messages with the 344 NAR, forwarding the packets destined for the MN to NCoA. The NCoA is 345 confirmed or re-assigned by the NAR in the HAck and, finally 346 delivered to the MN through the FBack (Fast Binding Acknowledgment) 347 in case of predictive mode. 349 After the MN sends a MOB_HO-IND to the serving BS, data packet 350 transfer between the MN and the BS is not allowed any more. Note 351 that when a MOB_HO-IND is sent out before an FBack arrives in the MN, 352 it is highly probable that the MN will operate in reactive mode 353 because the serving BS releases the MN's all connections and 354 resources after receiving a MOB_HO-IND. Therefore, if possible, the 355 MN should exchange FBU and FBack messages with the PAR before sending 356 a MOB_HO-IND to the BS so as to operate in predictive mode. 358 5.3. Handover Execution 360 If the MN receives an FBack message on the previous link, it runs in 361 predictive mode after handover. Otherwise, it should run in reactive 362 mode. In order for the MN to operate in predictive mode as far as 363 possible after handover, implementations may allow use of a 364 LINK_SWITCH primitive. The LINK_SWITCH is a command in order to 365 force the MN to switch from an old BS to a new BS and the similar 366 concept has introduced for the wireless LAN in 367 [I-D.irtf-mobopts-l2-abstractions]. When it is applied, the MN's IP 368 layer issues a LINK_SWITCH primitive to the link layer on receiving 369 the FBack message in the previous link. Until it occurs, the link- 370 layer keeps the current (previous) link if feasible and postpones 371 sending a MOB_HO-IND message while waiting for the FBack message. 373 After switching links, the MN synchronizes with the target BS and 374 performs the 802.16e network entry procedure. The MN exchanges the 375 RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages with 376 the target BS. Some of these messages may be omitted if the 377 (previously) serving BS transferred the context to the target BS over 378 the backbone beforehand. When the network entry procedure is 379 completed and the link layer is ready for data transmission, it 380 informs the IP layer of the fact with a LINK_UP primitive. 382 Note that the LINK_UP should not be sent due to changes in transient 383 link conditions and less sensitive to link conditions according to 384 Section 2 of [RFC4907]. However, the link may experience a 385 intermittent loss. Even in such a case, the following FMIPv6 386 operation is performed only when the MN handovers to the link with a 387 different subnet and there is no signaling overhead as a result of a 388 intermittent loss. 390 5.4. Handover Completion 392 When the MN's IP layer receives a LINK_UP primitive from the link 393 layer, it should check whether it has moved into the target network 394 predicted by FMIPv6. In case the target BS is within the same 395 subnet, the MN does not perform the FMIPv6 operation. 397 o If the MN discovers itself in the predicted target network 398 and receives an FBack message in the previous link, the MN's 399 IP layer sends a UNA (Unsolicited Neighbor Advertisement) to 400 the NAR (predictive mode). 402 o If the MN has moved to the target network without receiving 403 an FBack message in the previous link, the IP layer sends an 404 UNA and also an FBU message immediately after sending the UNA 405 message (reactive mode). The NAR may provide a different IP 406 address by using an RA (Router Advertisement) with a NAACK 407 (Neighbor Advertisement Acknowledge) option other than the 408 formulated NCoA by the MN. 410 o The MN may discover itself in the unpredicted network 411 (erroneous movement). This is the case the MN moves to the 412 network that is not the target specified in the 413 LINK_HANDOVER_IMPEND primitive. For the recovery from such 414 invalid indication which is mentioned in Section 2 of [RFC4907], 415 the MN should send a new FBU to the PAR according to Section 5.6 416 of [I-D.ietf-mipshop-fmipv6-rfc4068bis] so that the PAR can 417 update the existing binding entry and redirect the packets to 418 the new confirmed location. 420 In both cases of predictive and reactive modes, once the MN has moved 421 into the new link, it uses the NCoA formulated by the MN as a source 422 address of the UNA, irrespective of NCoA availability. It then 423 starts a DAD probe for NCoA according to [RFC4862]. In case the NAR 424 provides the MN with a new NCoA, the MN MUST use the provided NCoA 425 instead of the NCoA formulated by the MN. 427 When the NAR receives a UNA message, it deletes its proxy neighbor 428 cache entry if it exists, and forwards buffered packets to the MN 429 after updating the neighbor cache properly. Detailed UNA processing 430 rules are specified in Section 6.4 of 431 [I-D.ietf-mipshop-fmipv6-rfc4068bis]. 433 6. The Examples of Handover Scenario 435 In this section, the recommended handover procedures over 802.16e 436 network are shown for both predictive and reactive modes. It is 437 assumed that the MN handovers to the network which belongs to a 438 different subnet. 440 In the follwing figures, the messages between the MN's layer 2 (MN 441 L2) and the BS are the IEEE 802.16 messages while messages between 442 the MN's layer 3 (MN L3) and the PAR, and messages between PAR and 443 NAR are the FMIPv6 messages. The messages between the the MN L2 and 444 the MN L3 are primitives introduced in this document. 446 6.1. Predictive Mode 448 The handover procedures in the predictive mode are briefly described 449 as follows. Figure 3 is illustrating these procedures. 451 1. A BS broadcasts a MOB_NBR-ADV periodically. 453 2. If the MN discovers a new neighbor BS in this message, it 454 may perform scanning for the BS. 456 3. When a new BS is found through the MOB_NBR-ADV and 457 scanning, the MN's link layer notifies it to the IP layer 458 by a NEW_LINK_DETECTED primitive. 460 4. The MN tries to resolve the new BS's BSID to the 461 associated AR by exchange of RtSolPr and PrRtAdv messages 462 with the PAR. 464 5. The MN initiates handover by sending a MOB_MSHO-REQ message 465 to the BS and receives a MOB_BSHO-RSP from the BS. 466 Alternatively, the BS may initiate handover by sending a 467 MOB_BSHO-REQ to the MN. 469 6. When the MN receives either a MOB_BSHO-RSP or a MOB_BSHO-REQ 470 from the BS, its link layer triggers a 471 LINK_HANDOVER_IMPEND primitive to the IP layer. 473 7. On reception of the LINK_HANDOVER_IMPEND, the MN's IP layer 474 identifies that the target delivered along with the 475 LINK_HANDOVER_IMPEND belongs to a different subnet and sends 476 an FBU message to the PAR. On receiving this message, the 477 PAR establishes tunnel between the PCoA and the NCoA by 478 exchange of HI and HAck messages with the NAR, and forwards 479 packets destined for the MN to the NCoA. During this time, 480 the NAR may confirm NCoA availability in the new link via 481 HAck. 483 8. The MN receives the FBack message before its handover and 484 sends a MOB_HO-IND message as a final indication of handover. 485 Issue of a MOB_HO-IND optionally may be promoted by using 486 a LINK_SWITCH command from the IP layer. Afterwards it 487 operates in predictive mode in the new link. 489 9. The MN conducts handover to the target BS and performs 490 the IEEE 802.16e network entry procedure. 492 10. As soon as the network entry procedure is completed, the 493 MN's link layer signals the IP layer with a LINK_UP. On 494 receiving this, the IP layer identifies that it has moved 495 to a predicted target network and received the FBack message 496 in the previous link. It issues a UNA to the NAR by using 497 NCoA as a source IP address. At the same time, it starts to 498 perform DAD for the NCoA. 500 11. When the NAR receives the UNA from the MN, it delivers 501 the buffered packets to the MN. 503 (MN L3 MN L2) s-BS PAR t-BS NAR 504 | | | | | | 505 1-2. | |<---MOB_NBR-ADV --------| | | | 506 | |<-------Scanning------->| | | | 507 3. |<-NLD-| | | | | 508 4. |--------------(RtSolPr)-------------->| | | 509 |<--------------PrRtAdv----------------| | | 510 | | | | | | 511 5. | |------MOB_MSHO-REQ----->| | | | 512 | |<-----MOB_BSHO-RSP------| | | | 513 | | or | | | | 514 | |<-----MOB_BSHO-REQ------| | | | 515 6. |<-LHI-| | | | | 516 7. |------------------FBU---------------->| | | 517 | | | |--------HI-------->| 518 | | | |<------HACK--------| 519 |<-----------------FBack---------------|--> | | 520 | | | Packets==============>| 521 8. |(LSW)>|-------MOB_HO-IND------>| | | | 522 disconnect| | | | | 523 connect | | | | | 524 9. | |<---------IEEE 802.16 network entry-------->| | 525 10. |<-LUP-| | | | | 526 |----------------------------UNA-------------------------->| 527 11. |<==================================================== Packets 528 | | | | | 530 Figure 3. Predictive Fast Handover in 802.16e 532 6.2. Reactive Mode 534 The handover procedures in the reactive mode are described as 535 follows. Figure 4 is illustrating these procudures. 537 1.~ 7. The same as procedures of predictive mode. 539 8. The MN does not receive the FBack message before handover 540 and sends a MOB_HO-IND message as a final indication of 541 handover. Afterwards, it operates in reactive mode in the 542 new link. 544 9. The MN conducts handover to the target network and performs 545 the 802.16e network entry procedure. 547 10. As soon as the network entry procedure is completed, the 548 MN's link layer signals the IP layer with a LINK_UP. On 549 receiving this, the IP layer identifies that it has moved 550 to the predicted target network without receiving the FBack 551 in the previous link. The MN issues a UNA to the 552 NAR by using NCoA as a source IP address and starts to 553 perform DAD for the NCoA. Additionally, it also sends an 554 FBU to the PAR in the reactive mode. 556 11. When the NAR receives the UNA and the FBU from the MN, it 557 forwards the FBack to the PAR. The FBack and Packets are 558 forwarded from the PAR and delivered to the MN (NCoA) through 559 the NAR. The NAR may supply a different IP address than the 560 NCoA by sending an RA with a NAACK option to the MN. 562 (MN L3 MN L2) s-BS PAR t-BS NAR 563 | | | | | | 564 1-2. | |<---MOB_NBR-ADV & Scan--| | | | 565 | |<-------Scanning------->| | | | 566 3. |<-NLD-| | | | | 567 4. |--------------(RtSolPr)-------------->| | | 568 |<--------------PrRtAdv----------------| | | 569 | | | | | | 570 5. | |------MOB_MSHO-REQ----->| | | | 571 | |<-----MOB_BSHO-RSP------| | | | 572 | | or | | | | 573 | |<-----MOB_BSHO-REQ------| | | | 574 6. |<-LHI-| | | | | 575 7. |--------FBU----X---> | | | | 576 8. | |-------MOB_HO-IND------>| | | | 577 disconnect| | | | | 578 connect | | | | | 579 9. | |<---------IEEE 802.16 network entry-------->| | 580 10. |<-LUP-| | | | | 581 |----------------------------UNA-------------------------->| 582 |----------------------------FBU--------------------------)| 583 11. | | | |<-------FBU-------)| 584 | | | |<-----HI/HAck----->| 585 | | | | (if necessary) | 586 | | | Packets & FBack=========>| 587 |<=========================================================| 588 | | | | | | 590 Figure 4. Reactive Fast Handover in 802.16e 592 7. IEEE 802.21 Considerations 594 It is worth noting that great researches have been conducted on 595 defining generic services in the IEEE 802.21 working group that 596 facilitate handovers between heterogeneous access links. The 597 standard works are named as a Media Independent Handover (MIH) 598 Service [IEEE 802.21], and propose three kinds of services, that is 599 Media Independent Event Service (MIES), Media Independent Command 600 Service (MICS), and Media Independent Information Service (MIIS). 602 An MIES defines the events triggered from lower layers (physical and 603 link) to higher layers (network and above) in order to report changes 604 of physical and link layer conditions. On the other hand, an MICS 605 supports the commands sent from higher layers to lower layers, and 606 provides users with a way of managing the link behavior relevant to 607 handovers and mobility. An MIIS provides a framework by which the MN 608 or network can obtain network information to facilitate network 609 selection and handovers. 611 Although the purpose of IEEE 802.21 has been developed to enhance 612 user experience of MNs roaming between heterogeneous networks, the 613 results may be utilized to optimize the handover performance in a 614 homogeneous network. When the MIH primitives are available for 615 handover in the 802.16e network, the MN can use them instead of the 616 primitives proposed in this document. The Table 1 shows examples of 617 the mapping between the proposed primitives and the MIH primitives. 619 +-------------------------+-------------------------+ 620 | Proposed primitives | MIH primitives | 621 +===================================================+ 622 | NEW_LINK_DETECTED | LINK_DETECTED | 623 +---------------------------------------------------+ 624 | LINK_HANDOVER_IMPEND | LINK_HANDOVER_IMMINENT | 625 +---------------------------------------------------+ 626 | LINK_SWITCH | HANDOVER_COMMIT | 627 +---------------------------------------------------+ 628 | LINK_UP | LINK_UP | 629 +---------------------------------------------------+ 631 Table 1. The proposed primitives and MIH primitives 633 8. Security Considerations 635 The primitives defined in this document are used only for local 636 indication inside of the MN, so no security mechanism is required to 637 protect those primitives. However, FMIPv6 messages and IEEE 802.16e 638 messages which may trigger the primitives need to be protected. 640 Security considerations of the FMIPv6 specification 641 [I-D.ietf-mipshop-fmipv6-rfc4068bis] are applicable to this document. 642 It is also worthwhile to note that the IEE802.16e has a security sub- 643 layer which provides subscribers with privacy and authentication over 644 the broadband wireless network. This layer has two main component 645 protocols: a privacy key management protocol (PKM) for key management 646 and authentication, and an encapsulation protocol for encrypting 647 data. From the perspective of the 802.16e, FMIPv6 messages are 648 considered as data and delivered securely by using those protocols. 650 However, some of IEEE 802.16e management messages are sent without 651 authentication. There is no protection to secure 802.16e broadcast 652 messages. It may be possible for the attacker to maliciously forge a 653 MOB_NBR-ADV message so that it contains the bogus BSIDs, or send a 654 flood of MOB_NBR-ADV messages having different bogus BSIDs toward the 655 MN. As a result of this, the MN may send the useless consecutive 656 RtSolPr messages to the PAR and result in wasting the air resources. 657 Therefore, the MN SHOULD perform scanning lest it should issue a 658 NEW_LINK_DETECTED primitive when receiving the forged MOB_NBR-ADV 659 messages from attackers. It is also possible that attackers try a 660 DoS (Denial-of-Service) attack by sending a flood of a MOB_BSHO-REQ 661 messages and triggering LINK_HANDOVER_IMPEND primitives in the MN. 662 But the IEEE 802.16e provides a message authentication scheme for 663 management messages involved in handover as well as network entry 664 procedures by using a message authentication code (MAC) such as HMAC/ 665 CMAC (hashed/cipher MAC). Therefore those management messages are 666 protected from the malicious use by attackers for triggering 667 LINK_HANDOVER_IMPEND or LINK_UP primitives. 669 9. IANA Consideration 671 This document does not require any new number assignment from IANA. 673 10. Acknowledgment 675 Many thanks IETF Mobility Working Group members of KWISF (Korea 676 Wireless Internet Standardization Forum) for their efforts on this 677 work. In addition, we would like to thank Alper E. Yegin, Jinhyeock 678 Choi, Rajeev Koodli, Soininen Jonne, Gabriel Montenegro, Singh Ajoy, 679 Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli and Ved Kafle who 680 have provided the technical advice. 682 11. References 684 11.1. Normative References 686 [I-D.ietf-mipshop-fmipv6-rfc4068bis] 687 Koodli, R., "Mobile IPv6 Fast Handovers", 688 draft-ietf-mipshop-fmipv6-rfc4068bis-06 (work in 689 progress), February 2008. 691 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 692 Requirement Levels", BCP 14, RFC 2119, March 1997. 694 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 695 in IPv6", RFC 3775, June 2004. 697 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 698 Address Autoconfiguration", RFC 4862, September 2007. 700 [IEEE 802.16] IEEE Standard for Local and Metropolitan Area Networks, 701 "Part 16 - Air Interface for Fixed Broadband Wireless 702 Access Systems", IEEE Std 802.16-2004, June 2004. 704 [IEEE 802.16e] IEEE Standard for Local and Metropolitan Area Networks, 705 "Amendment 2: Physical and Medium Access Control Layers for 706 Combined Fixed and Mobile Operation in Licensed Bands and 707 Corrigendum 1", IEEE Std 802.16e-2005 and IEEE Std 802.16 708 -2004/Cor 1-2005, February 2006. 710 11.2. Informative References 712 [I-D.irtf-mobopts-l2-abstractions] 713 Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast 714 Handover", draft-irtf-mobopts-l2-abstractions-07 (work in 715 progress), February 2008. 717 [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 718 Networks", RFC 4260, November 2005. 720 [RFC4907] Aboba, B., "Architectural Implications of Link 721 Indications", RFC 4907, June 2007. 723 [IEEE 802.21] IEEE 802.21 Working Group Document,"Draft IEEE Standard 724 for Local and Metropolitan Area Networks: Media Independent 725 Handover Services", IEEE P802.21 D9.0, February 2008. 727 [SH-802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover 728 Mechanism for IEEE 802.16e Broadband Wireless Access", 729 International Conference on Computational Science, 730 vol. 2, pp. 527-534, 2005. 732 Authors' Addresses 734 Hee-Jin Jang 735 Samsung Advanced Institute of Technology 736 P.O. Box 111 737 Suwon 440-600 738 Korea 740 Email: heejin.jang@samsung.com 742 Junghoon Jee 743 Electronics and Telecommunications Research Institute 744 161 Gajeong-dong, Yuseong-gu 745 Daejon 305-350 746 Korea 748 Email: jhjee@etri.re.kr 750 Youn-Hee Han 751 Korea University of Technology and Education 753 Email: yhhan@kut.ac.kr 755 Soohong Daniel Park 756 Samsung Electronics 757 416 Maetan-3dong, Yeongtong-gu 758 Suwon 442-742 759 Korea 761 Email: soohong.park@samsung.com 763 Jaesun Cha 764 Electronics and Telecommunications Research Institute 765 161 Gajeong-dong, Yuseong-gu 766 Daejon 305-350 767 Korea 769 Email: jscha@etri.re.kr 771 Full Copyright Statement 773 Copyright (C) The IETF Trust (2008). 775 This document is subject to the rights, licenses and restrictions 776 contained in BCP 78, and except as set forth therein, the authors 777 retain all their rights. 779 This document and the information contained herein are provided on an 780 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 781 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 782 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 783 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 784 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 785 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Intellectual Property 789 The IETF takes no position regarding the validity or scope of any 790 Intellectual Property Rights or other rights that might be claimed to 791 pertain to the implementation or use of the technology described in 792 this document or the extent to which any license under such rights 793 might or might not be available; nor does it represent that it has 794 made any independent effort to identify any such rights. Information 795 on the procedures with respect to rights in RFC documents can be 796 found in BCP 78 and BCP 79. 798 Copies of IPR disclosures made to the IETF Secretariat and any 799 assurances of licenses to be made available, or the result of an 800 attempt made to obtain a general license or permission for the use of 801 such proprietary rights by implementers or users of this 802 specification can be obtained from the IETF on-line IPR repository at 803 http://www.ietf.org/ipr. 805 The IETF invites any interested party to bring to its attention any 806 copyrights, patents or patent applications, or other proprietary 807 rights that may cover technology that may be required to implement 808 this standard. Please address the information to the IETF at 809 ietf-ipr@ietf.org.