idnits 2.17.1 draft-ietf-mipshop-fh80216e-06.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 702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 726. 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 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (January 29, 2008) is 5925 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fmipv6-rfc4068bis-04 == Outdated reference: A later version (-07) exists of draft-irtf-mobopts-l2-abstractions-05 Summary: 3 errors (**), 0 flaws (~~), 4 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: August 1, 2008 ETRI 6 Youn-Hee Han 7 KUT 8 Soohong Daniel Park 9 Samsung Electronics 10 Jaesun Cha 11 ETRI 12 January 29, 2008 14 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks 15 draft-ietf-mipshop-fh80216e-06.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 August 1, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document describes how a Mobile IPv6 Fast Handover can be 49 implemented on link layers conforming to the 802.16e suite of 50 specifications. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . . 6 57 4. Network Topology Acquisition and Network Selection . . . . . . 8 58 5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 9 59 5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 9 60 5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 9 61 5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 10 62 5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 11 63 6. The Examples of Handover Scenario . . . . . . . . . . . . . . 13 64 6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 13 65 6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 14 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 18 68 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 19 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 73 Intellectual Property and Copyright Statements . . . . . . . . . . 22 75 1. Introduction 77 Mobile IPv6 (MIPv6) [RFC3775] is currently available to provide the 78 session continuity during handover. It is capable of handling IP 79 handover between different subnets in a transparent way for higher- 80 layer connections. However, the handover latency resulting from 81 MIPv6 is often unacceptable to real-time traffic such as Voice over 82 IP, and Mobile IPv6 Fast Handover protocol (FMIPv6) 83 [I-D.ietf-mipshop-fmipv6-rfc4068bis] has been proposed as a mechanism 84 to reduce the handover latency by predicting and preparing the 85 impending handover in advance. 87 As [RFC4260] pointed out, FMIPv6 assumes the support from the link- 88 layer technology, but the specific link-layer information available, 89 as well as the timing of its availability (before, during or after a 90 handover occurs), differs according to the particular link-layer 91 technology in use. This document is proposed to provide 92 informational guide to the developers about how to optimize the 93 FMIPv6 handover procedure, specifically in the 802.16 networks. 95 To provide the seamless handover, this proposal tries to maximize the 96 benefits of synchronizing the link layer handover with the fast IP 97 handover procedure by exploiting the link-layer handover indicators 98 when available. In this proposal, the Media Independent Handover 99 (MIH) services being defined in the IEEE 802.21 working group 100 [802.21] is used as an example of link-layer specific indicators for 101 this purpose. This document introduces a set of useful messages 102 among primitives proposed by IEEE 802.21 which can be cooperated with 103 802.16 handover and FMIPv6 procedures, and provides the most 104 appropriate timing for the trigger of each selected primitive during 105 802.16 handover procedure. 107 We begin with a summary of a handover procedure of [802.16e] which is 108 the amendment of 802.16 for mobility. Then the interaction between 109 802.16e and FMIPv6 is presented with the primitives proposed by IEEE 110 802.21 [802.21] for the close interaction between Layer 2 and Layer 111 3. Lastly, the examples of handover scenarios are described for both 112 predictive mode and reactive mode. 114 2. Terminology 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document is to be interpreted as described in [RFC2119]. 120 Most of terms used in this document are defined in MIPv6 [RFC3775] 121 and FMIPv6 [I-D.ietf-mipshop-fmipv6-rfc4068bis]. 123 The following terms come from IEEE 802.16e specification [802.16e]. 125 MOB_NBR-ADV 127 An IEEE 802.16e neighbor advertisement message sent 128 periodically by a base station. 130 MOB_MSHO-REQ 132 An IEEE 802.16e handover request message sent by a mobile node. 134 MOB_BSHO-RSP 136 An IEEE 802.16e handover response message sent by a base 137 station. 139 MOB_BSHO-REQ 141 An IEEE 802.16e handover request message sent by a base 142 station. 144 MOB_HO-IND 146 An IEEE 802.16e handover indication message sent by a mobile 147 node. 149 BSID 151 An IEEE 802.16e base station identifier. 153 Additionally, the following primitives are proposed by [802.21] and 154 the standardization is in progress. 156 Link_Detected (LD) 158 A trigger from the link layer to the IP layer in a mobile node 159 to report that a new link is detected. 161 Link_Handover_Imminent (LHI) 163 A trigger from the link layer to the IP layer in a mobile node 164 to report that a native link layer handover/switch decision has 165 been made and its execution is imminent. 167 Link_Up (LUP) 169 A trigger from the link layer to the IP layer in a mobile node 170 to report that the mobile node completes the link layer 171 connection establishment with a new BS. 173 Handover_Commit (HC) 175 A control command from the IP layer to the link layer in a 176 mobile node in order to force the mobile node to switch from an 177 old BS to a new BS. 179 3. IEEE 802.16e Handover Overview 181 Compared with the handover in the wireless LAN, the 802.16e handover 182 mechanism consists of more steps since 802.16e embraces the 183 functionality for elaborate parameter adjustment and procedural 184 flexibility. 186 When a mobile node (MN) stays in a link, it listens to L2 neighbor 187 advertisement messages, named a MOB_NBR-ADV, from its serving base 188 station (BS). A BS broadcasts them periodically to identify the 189 network and announces the characteristics of neighbor BSs. Once 190 receiving this, the MN decodes this message to find out information 191 about the parameters of neighbor BSs for its future handover. With 192 the provided information in a MOB_NBR-ADV, the MN may minimize the 193 handover latency by obtaining the channel number of neighbors and 194 reducing the scanning time, or may select the better target BS based 195 on the signal strength, QoS level, service price, etc. 197 The handover procedure is conceptually divided into two steps: 198 "handover preparation" and "handover execution" [SH-802.16e]. The 199 handover preparation can be initiated by either the MN or the BS. 200 During this period, neighbors are compared by the metrics such as 201 signal strength or QoS parameters and a target BS is selected among 202 them. If necessary, the MN may try to associate (initial ranging) 203 with candidate BSs to expedite a future handover. Once the MN 204 decides handover, it notifies its intent by sending a MOB_MSHO-REQ 205 message to the serving BS. The BS then replies with a MOB_BSHO-RSP 206 containing the recommended BSs to the MN after negotiating with 207 candidates. Optionally it may confirm handover to the target BS over 208 backbone when the target is decided. The BS alternatively may 209 trigger handover with a MOB_BSHO-REQ message. 211 After handover preparation, handover execution starts. When the MN 212 is about to move to the new link after deciding the target BS, it 213 sends a MOB_HO-IND message to the serving BS as a final indication 214 for its handover. Once the MN makes a new attachment, it conducts 215 802.16e ranging through which it can acquire physical parameters from 216 the target BS, tuning its parameters to the target BS. After ranging 217 with the target BS successfully, the MN negotiates basic capabilities 218 such as maximum transmit power and modulator/demodulator type. It 219 then performs authentication and key exchange procedure, and finally 220 registers with the target BS. If the target BS has already learned 221 some contexts such as authentication or capability parameters through 222 backbone, it may omit the corresponding procedures. For the detailed 223 procedure of the 802.16 network entry, refer to section 6.3.22 of 224 [802.16e]. After completing registration, the target BS starts to 225 serve the MN and communication via target BS is available. However, 226 when the MN moves to a different subnet, it should re-configure a new 227 IP address and re-establish an IP connection. To resume the active 228 session of the previous link, the MN should perform IP layer handover 229 additionally. 231 4. Network Topology Acquisition and Network Selection 233 This section describes how discovery of adjacent networks and 234 selection of target network work in 802.16e for background 235 information. 237 An MN can learn the network topology and acquire the link information 238 in two ways. One method is via L2 neighbor advertisements. A BS 239 supporting mobile functionality shall broadcast a MOB_NBR-ADV message 240 including the network topology periodically (maximum interval, 241 1sec.). This message includes BSIDs and channel information of 242 neighbor BSs, and is used to facilitate the MN's synchronization with 243 neighbor BSs. An MN can collect the necessary information of the 244 neighbor BSs through this message for its future handover. 246 Another method for acquisition of network topology is scanning, which 247 is the process to seek and monitor available BSs in order to find 248 suitable handover targets. While a MOB_NBR-ADV message includes 249 static information about neighbor BSs, scanning provides rather 250 dynamic parameters such as link quality parameters. Since the 251 MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically 252 and scanning provides a way to sort out some adequate BSs, it is 253 recommended that when new BSs are found in the advertisement, the MN 254 identifies them via scanning and resolves their BSIDs to the 255 information of the subnet where the BS is connected. The 256 association, an optional initial ranging procedure occurring during 257 scanning, is one of the helpful methods to facilitate the impending 258 handover. The MN is able to get ranging parameters and service 259 availability information for the purpose of proper selection of the 260 target BS and expediting a potential future handover to it. The 261 detailed explanation of association is described in section 6.3.22 of 262 [802.16e]. 264 After learning about neighbors, the MN may compare them to find a BS 265 which can serve better than the serving BS. The target BS may be 266 determined by considering various criteria such as required QoS, 267 cost, user preference, and policy. How to select the target BS is 268 not in the scope of this document. 270 5. Interaction between FMIPv6 and IEEE 802.16e 272 In this section, we describe the desirable FMIPv6 handover procedure 273 in 802.16 networks. We introduce four primitives proposed by 274 [802.21] for the close interaction between FMIPv6 and 802.16e, and 275 present the detailed interaction procedure. 277 5.1. Access Router Discovery 279 Once a new BS is detected through the reception of a MOB_NBR-ADV and 280 scanning, an MN may try to learn the associated AR information as 281 soon as possible. In order to enable quick discovery of the 282 associated AR information in the IP layer, the link layer (802.16) 283 triggers a Link_Detected (LD) primitive to the IP layer (FMIPv6) on 284 detecting the new BS. 286 Receiving the Link_Detected from the link layer, the IP layer tries 287 to learn the associated AR information by exchanging a RtSolPr 288 (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy 289 Router Advertisement) with the PAR. According to 290 [I-D.ietf-mipshop-fmipv6-rfc4068bis], the MN may send a RtSolPr at 291 any convenient time. However this proposal recommends that, if 292 feasible, the MN send it as soon as possible after receiving the 293 primitive for quick router discovery because detection of a new BS 294 usually implies MN's movement. 296 It is unlikely that RtSolPr messages may cause signaling overheads 297 mentioned in Section 2 of [RFC4907]. The MN may detect more than one 298 BSs and issue the Link_Detected primitives but not all at once. 299 Furthermore, retransmission of RtSolPr messages are rate-limited by 300 exponential backoff in [I-D.ietf-mipshop-fmipv6-rfc4068bis]. 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 receives a 307 MOB_BSHO-RSP from the BS as a response. Alternatively the BS may 308 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_Imminent (LHI) in order to signal the IP 312 layer of arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly. At this time, 313 the target network decided in the link layer is delivered to the IP 314 layer in the MAC_access_router parameter (MAC address of the target 315 AR) of the Link_Handover_Imminent primitive. According to [802.21], 316 the Link_Handover_Imminent primitive is used to report that a native 317 link layer handover/switch decision has been made and its execution 318 is imminent. This primitive can be helpfully used for FMIPv6 as an 319 indication to start handover preparation procedure, that is to send 320 an FBU message to the PAR. 322 To avoid erroneous results due to unreliable and inconsistent 323 characteristics of link, for instance, to move to the unpredicted 324 network or to keep staying in the current network after sending an 325 FBU, Section 2 of [RFC4907] advises to use combination of signal 326 strength data with other techniques rather than relying only on 327 signal strength for handover decision. For example, an LHI may be 328 sent after validating filtered signal strength measurements with 329 other indications of link loss such as lack of beacon reception. 331 Once the IP layer receives the LHI, it checks whether the specified 332 target network belongs to the different subnet or not based on the 333 information collected during Access Router Discovery step. If the 334 target proves to be in the same subnet, the MN can continue to use 335 the current IP address after handover and there is no need to perform 336 FMIPv6. Otherwise, the IP layer formulates a prospective NCoA (New 337 CoA) with the information provided in the PrRtAdv message and sends 338 an FBU message to the PAR. 340 When the FBU message arrives in the PAR successfully, the PAR and the 341 NAR process it according to [I-D.ietf-mipshop-fmipv6-rfc4068bis]. 342 The PAR sets up a tunnel between the PCoA (Previous CoA) and NCoA by 343 exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) 344 messages with the NAR, forwarding the packets destined for the MN to 345 NCoA. The NCoA is confirmed or re-assigned by the NAR in the HAck 346 and finally delivered to the MN through the FBack message in case of 347 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 the 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 the use of a 364 Handover_Commit (HC) [802.21] primitive. When the Handover_Commit is 365 applied, the MN's IP layer may issue a Handover_Commit primitive to 366 the link layer on receiving the FBack message in the previous link. 367 Until it occurs, the link-layer keeps the previous link if feasible 368 and postpones sending a MOB_HO-IND message while waiting for the 369 FBack message. The Handover_Commit is a command service provided by 370 [802.21] in order to force the MN to switch from an old BS to a new 371 BS and the similar concept has introduced for the wireless LAN in 372 [I-D.irtf-mobopts-l2-abstractions]. 374 After switching links, the MN synchronizes with the target BS and 375 performs the 802.16e network entry procedure. The MN exchanges the 376 RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages with 377 the target BS. Some of these messages may be omitted if the 378 (previously) serving BS transferred the context to the target BS over 379 the backbone beforehand. When the network entry procedure is 380 completed and the link layer is ready for data transmission, it 381 informs the IP layer of the fact with a Link_Up (LUP) primitive. 383 Note that the Link_Up should not be sent due to changes in transient 384 link conditions and less sensitive to link conditions as mentioned in 385 Section 2 of [RFC4907]. However, the link may experience a 386 intermittent loss. Even in such a case, the following FMIPv6 387 operation is performed only when the MN handovers to the link with 388 different subnet and there is no signaling overhead as a result of a 389 intermittent loss. 391 5.4. Handover Completion 393 When the MN's IP layer receives the Link_Up primitive from the link 394 layer, it should check whether it has moved into the target network 395 predicted by FMIPv6. In case the NAR has moved to the same subnet, 396 the MN does not perform the FMIPv6 operation. 398 o If the MN discovers itself in the predicted target network 399 and receives an FBack message in the previous link, the MN's 400 IP layer sends a UNA (Unsolicited Neighbor Advertisement) to 401 the NAR (predictive mode). 403 o If the MN has moved to the target network without receiving 404 an FBack message in the previous link, the IP layer sends an 405 UNA and also an FBU message immediately after sending the 406 UNA message (reactive mode). The NAR may provide different IP 407 address by using an RA (Router Advertisement) with a NAACK 408 (Neighbor Advertisement Acknowledge) option other than the 409 formulated NCoA by the MN. 411 o The MN may discover itself in the unpredicted network 412 (erroneous movement). This is the case the MN moves to the 413 network that is not the target specified in the LHI primitive. 414 For the recovery from such a invalid indication which is 415 mentioned in Section 2 of [RFC4907], the MN should send a new 416 FBU to the PAR according to Section 5.6 of 417 [I-D.ietf-mipshop-fmipv6-rfc4068bis] so that the PAR can update 418 the existing binding entry and redirect the packets to the new 419 confirmed location. 421 In both cases of predictive and reactive modes, the MN uses the NCoA 422 as a source IP address of the UNA message and starts a DAD probe for 423 NCoA concurrently according to [RFC4862]. 425 When the NAR receives the UNA message, it deletes its proxy neighbor 426 cache entry if it exists, and forwards buffered packets to the MN 427 after updating the neighbor cache properly. Detailed UNA processing 428 rules are specified in Section 6.4 of 429 [I-D.ietf-mipshop-fmipv6-rfc4068bis]. 431 6. The Examples of Handover Scenario 433 In this section, the recommended handover procedures over 802.16e 434 network are shown for both predictive and reactive modes. It is 435 assumed that the MN handovers to the network which belongs to the 436 different subnet. 438 6.1. Predictive Mode 440 The procedure is described briefly as follows. 442 1. A BS broadcasts a MOB_NBR-ADV periodically. 444 2. If the MN discovers a new neighbor BS in this message, it 445 may perform scanning for the BS. 447 3. When a new BS is found through the MOB_NBR-ADV and 448 scanning, the MN's link layer notifies it to the IP layer 449 by a Link_Detected primitive. 451 4. Then the MN tries to resolve the new BS's BSID to the 452 associated AR by exchange of RtSolPr and PrRtAdv messages 453 with the PAR. 455 5. The MN initiates handover by sending a MOB_MSHO-REQ message 456 to the BS and receives a MOB_BSHO-RSP from the BS. 457 Alternatively, the BS may initiate handover by sending a 458 MOB_BSHO-REQ to the MN. 460 6. When the MN receives either a MOB_BSHO-RSP or a MOB_BSHO-REQ 461 from the BS, its link layer triggers a 462 Link_Handover_Imminent primitive to the IP layer. 464 7. On reception of the Link_Handover_Imminent, the MN's IP layer 465 identifies that the target in the Link_Handover_Imminent 466 belongs to the different subnet and sends an FBU message to 467 the PAR. On receiving this message, the PAR establishes 468 tunnel between the PCoA and the NCoA by exchange of HI and 469 HAck messages with the NAR, and forwards packets destined for 470 the MN to the NCoA. During this time, the NAR may confirm 471 NCoA availability in the new link via HAck. 473 8. The MN receives the FBack message before its handover and 474 sends a MOB_HO-IND message as a final indication of handover. 475 Issue of a MOB_HO-IND optionally may be promoted by using 476 a Handover_Commit command from the IP layer. Afterwards it 477 operates in predictive mode in the new link. 479 9. The MN conducts handover to the target BS and performs 480 the 802.16e network entry procedure. 482 10. As soon as the network entry procedure is completed, the 483 MN's link layer signals the IP layer with a Link_Up. On 484 receiving this, the IP layer identifies that it has moved 485 to a predicted target network and received the FBack message 486 in the previous link. It issues a UNA to the NAR by using 487 NCoA as a source IP address. At the same time, it starts to 488 perform DAD for the NCoA. 490 11. When the NAR receives the UNA from the MN, it delivers 491 the buffered packets to the MN. 493 (MN L3 MN L2) s-BS PAR t-BS NAR 494 | | | | | | 495 1-2. | |<---MOB_NBR-ADV --------| | | | 496 | |<-------Scanning------->| | | | 497 3. |<-LD--| | | | | 498 4. |--------------(RtSolPr)-------------->| | | 499 |<--------------PrRtAdv----------------| | | 500 | | | | | | 501 5. | |------MOB_MSHO-REQ----->| | | | 502 | |<-----MOB_BSHO-RSP------| | | | 503 | | or | | | | 504 | |<-----MOB_BSHO-REQ------| | | | 505 6. |<-LHI-| | | | | 506 7. |------------------FBU---------------->| | | 507 | | | |--------HI-------->| 508 | | | |<------HACK--------| 509 |<-----------------FBack---------------|--> | | 510 | | | Packets==============>| 511 8. |(HC)->|-------MOB_HO-IND------>| | | | 512 disconnect| | | | | 513 connect | | | | | 514 9. | |<-------------802.16 network entry--------->| | 515 10. |<-LUP-| | | | | 516 |----------------------------UNA-------------------------->| 517 11. |<==================================================== Packets 518 | | | | | 520 Figure 3. Predictive Fast Handover in 802.16e 522 6.2. Reactive Mode 524 The procedure is described as follows in case of reactive mode. 526 1.~ 7. The same as procedures of predictive mode. 528 8. The MN does not receive the FBack message before handover 529 and sends a MOB_HO-IND message as a final indication of 530 handover. Afterwards, it operates in reactive mode in the 531 new link. 533 9. The MN conducts handover to the target network and performs 534 the 802.16e network entry procedure. 536 10. As soon as the network entry procedure is completed, the 537 MN's link layer signals the IP layer with a Link_Up. On 538 receiving this, the IP layer identifies that it has moved 539 to the predicted target network without receiving the FBack 540 in the previous link. The MN issues a UNA to the 541 NAR by using NCoA as a source IP address and starts to 542 perform DAD for the NCoA. Additionally, it also sends an 543 FBU to the PAR in the reactive mode. 545 11. When the NAR receives the UNA and the FBU from the MN, it 546 forwards the FBack to the PAR. The FBack and Packets are 547 forwarded from the PAR and delivered to the MN (NCoA) through 548 the NAR. The NAR may supply a different IP address than the 549 NCoA by sending an RA with a NAACK option to the MN. 551 (MN L3 MN L2) s-BS PAR t-BS NAR 552 | | | | | | 553 1-2. | |<---MOB_NBR-ADV & Scan--| | | | 554 | |<-------Scanning------->| | | | 555 3. |<-LD--| | | | | 556 4. |--------------(RtSolPr)-------------->| | | 557 |<--------------PrRtAdv----------------| | | 558 | | | | | | 559 5. | |------MOB_MSHO-REQ----->| | | | 560 | |<-----MOB_BSHO-RSP------| | | | 561 | | or | | | | 562 | |<-----MOB_BSHO-REQ------| | | | 563 6. |<-LHI-| | | | | 564 7. |--------FBU----X---> | | | | 565 8. | |-------MOB_HO-IND------>| | | | 566 disconnect| | | | | 567 connect | | | | | 568 9. | |<-----------802.16 network entry----------->| | 569 10. |<-LUP-| | | | | 570 |----------------------------UNA-------------------------->| 571 |----------------------------FBU--------------------------)| 572 11. | | | |<-------FBU-------)| 573 | | | |<-----HI/HAck----->| 574 | | | | (if necessary) | 575 | | | Packets & FBack=========>| 576 |<=========================================================| 577 | | | | | | 579 Figure 4. Reactive Fast Handover in 802.16e 581 7. Security Considerations 583 The security consideration of the FMIPv6 specification 584 [I-D.ietf-mipshop-fmipv6-rfc4068bis] is applicable to this document. 585 Particularly, the 802.16e architecture supports a number of mandatory 586 authentication mechanisms, for example, EAP-TTLS, EAP-SIM and EAP-AKA 587 and that will allow secure handover operation of the MN. 589 8. IANA Consideration 591 This document does not require any new number assignment from IANA. 593 9. Acknowledgment 595 Many thanks IETF Mobility Working Group members of KWISF (Korea 596 Wireless Internet Standardization Forum) for their efforts on this 597 work. In addition, we would like to thank Alper E. Yegin, Jinhyeock 598 Choi, Rajeev Koodli, Soininen Jonne, Gabriel Montenegro, Singh Ajoy, 599 Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli and Ved Kafle who 600 have provided the technical advice. 602 10. References 604 10.1. Normative References 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, March 1997. 609 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 610 in IPv6", RFC 3775, June 2004. 612 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 613 Address Autoconfiguration", RFC 4862, September 2007. 615 [802.16e] IEEE 802.16 TGe Working Document, "Amendment 2: Physical 616 and Medium Access Control Layers for Combined Fixed and 617 Mobile Operation in Licensed Bands and Corrigendum 1", 618 IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/ 619 Cor 1-2005, February 2006. 621 10.2. Informative References 623 [I-D.ietf-mipshop-fmipv6-rfc4068bis] 624 Koodli, R., "Mobile IPv6 Fast Handovers", 625 draft-ietf-mipshop-fmipv6-rfc4068bis-04 (work in 626 progress), November 2007. 628 [I-D.irtf-mobopts-l2-abstractions] 629 Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast 630 Handover", draft-irtf-mobopts-l2-abstractions-05 (work in 631 progress), January 2008. 633 [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 634 Networks", RFC 4260, November 2005. 636 [RFC4907] Aboba, B., "Architectural Implications of Link 637 Indications", RFC 4907, June 2007. 639 [802.21] IEEE 802.21 Working Group Document,"Draft IEEE Standard 640 for Local and Metropolitan Area Networks: Media 641 Independent Handover Services", IEEE P802.21/D7.1, 642 August 2007. 644 [SH-802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover 645 Mechanism for IEEE 802.16e Broadband Wireless Access", 646 International Conference on Computational Science, 647 vol. 2, pp. 527-534, 2005. 649 Authors' Addresses 651 Hee-Jin Jang 652 Samsung Advanced Institute of Technology 653 P.O. Box 111 654 Suwon 440-600 655 Korea 657 Email: heejin.jang@samsung.com 659 Junghoon Jee 660 Electronics and Telecommunications Research Institute 661 161 Gajeong-dong, Yuseong-gu 662 Daejon 305-350 663 Korea 665 Email: jhjee@etri.re.kr 667 Youn-Hee Han 668 Korea University of Technology and Education 670 Email: yhhan@kut.ac.kr 672 Soohong Daniel Park 673 Samsung Electronics 674 416 Maetan-3dong, Yeongtong-gu 675 Suwon 442-742 676 Korea 678 Email: soohong.park@samsung.com 680 Jaesun Cha 681 Electronics and Telecommunications Research Institute 682 161 Gajeong-dong, Yuseong-gu 683 Daejon 305-350 684 Korea 686 Email: jscha@etri.re.kr 688 Full Copyright Statement 690 Copyright (C) The IETF Trust (2008). 692 This document is subject to the rights, licenses and restrictions 693 contained in BCP 78, and except as set forth therein, the authors 694 retain all their rights. 696 This document and the information contained herein are provided on an 697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 699 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 700 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 701 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 Intellectual Property 706 The IETF takes no position regarding the validity or scope of any 707 Intellectual Property Rights or other rights that might be claimed to 708 pertain to the implementation or use of the technology described in 709 this document or the extent to which any license under such rights 710 might or might not be available; nor does it represent that it has 711 made any independent effort to identify any such rights. Information 712 on the procedures with respect to rights in RFC documents can be 713 found in BCP 78 and BCP 79. 715 Copies of IPR disclosures made to the IETF Secretariat and any 716 assurances of licenses to be made available, or the result of an 717 attempt made to obtain a general license or permission for the use of 718 such proprietary rights by implementers or users of this 719 specification can be obtained from the IETF on-line IPR repository at 720 http://www.ietf.org/ipr. 722 The IETF invites any interested party to bring to its attention any 723 copyrights, patents or patent applications, or other proprietary 724 rights that may cover technology that may be required to implement 725 this standard. Please address the information to the IETF at 726 ietf-ipr@ietf.org. 728 Acknowledgment 730 Funding for the RFC Editor function is provided by the IETF 731 Administrative Support Activity (IASA).