idnits 2.17.1 draft-ietf-mipshop-fh80216e-01.txt: -(599): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (January 2, 2007) is 6295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'BSID' on line 319 -- Looks like a reference, but probably isn't: 'AR-Info' on line 319 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (ref. '3') (Obsoleted by RFC 5268) == Outdated reference: A later version (-07) exists of draft-irtf-mobopts-l2-abstractions-01 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group Heejin Jang 3 Internet-Draft Samsung AIT 4 Intended status: Informational Junghoon Jee 5 Expires: July 6, 2007 ETRI 6 Youn-Hee Han 7 KUT 8 Soohong Daniel Park 9 Samsung Electronics 10 Jaesun Cha 11 ETRI 12 January 2, 2007 14 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks 15 draft-ietf-mipshop-fh80216e-01.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 July 6, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2007). 46 Abstract 48 This document describes how a Mobile IPv6 Fast Handover could 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. Deployment Architectures for Mobility on IEEE 802.16e . . . . 6 57 4. IEEE 802.16e Handovers Overview . . . . . . . . . . . . . . . 8 58 5. Network Topology Acquisition and Cell Selection . . . . . . . 9 59 6. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 10 60 6.1. Access Router Discovery . . . . . . . . . . . . . . . . . 10 61 6.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 10 62 6.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 11 63 6.4. Handover Completion . . . . . . . . . . . . . . . . . . . 11 64 7. The Examples of Handover Scenario . . . . . . . . . . . . . . 12 65 7.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 12 66 7.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 14 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17 69 10. Normative References . . . . . . . . . . . . . . . . . . . . . 18 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 71 Intellectual Property and Copyright Statements . . . . . . . . . . 20 73 1. Introduction 75 In order to provide the session continuity during handover, Mobile 76 IPv6 protocol [2] is currently available. It is capable of handling 77 IP handovers between different subnets in a transparent way for 78 higher-level connections. However, the handover latency resulting 79 from standard Mobile IPv6 is often unacceptable to real-time traffic 80 such as Voice over IP, and Mobile IPv6 Fast Handover protocol 81 (FMIPv6) [3] has been proposed as a mechanism to improve the handover 82 latency by predicting and preparing the impending handover in 83 advance. 85 As [4] pointed out, Mobile IPv6 Fast Handover assumes the support 86 from the link-layer technology, but the particular link-layer 87 information available, as well as the timing of its availability 88 (before, during or after a handover has occurred), differs according 89 to the particular link-layer technology in use. 91 This document describes Mobile IPv6 Fast Handovers on 802.16 92 networks. There are three kinds of handover modes, hard handover, 93 fast base station (BS) switching and soft handover in IEEE 802.16e. 94 In this version of the draft, we consider the hard handover mode 95 because this is the default mode. We begin with a summary of a 96 handover procedure on 802.16e [6], the amendment of 802.16 for 97 mobility. Then the interaction between 802.16e and FMIPv6 is 98 presented with the primitives proposed by IEEE 802.21 for the close 99 interaction between Layer 2 and Layer 3. Lastly, the examples of 100 handover scenario are described for both predictive mode and reactive 101 mode. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document is to be interpreted as described in RFC2119 [1]. 109 Most of terms used in this draft are defined in Mobile IPv6 [2] and 110 FMIPv6 [3]. 112 The following terms come from IEEE 802.16e specification [6]. 114 MOB_NBR-ADV 116 IEEE 802.16e neighbor advertisement message sent periodically 117 by a base station. 119 MOB_MSHO-REQ 121 IEEE 802.16e handover request message sent by a mobile node. 123 MOB_BSHO-RSP 125 IEEE 802.16e handover response message sent by a base station. 127 MOB_BSHO-REQ 129 IEEE 802.16e handover request message sent by a base station. 131 MOB_HO-IND 133 IEEE 802.16e handover indication message sent by a mobile node. 135 BSID 137 IEEE 802.16e base station identifier. 139 Additionally, the following triggers are proposed by IEEE 802.21 [7] 140 and the standardization is in progress. We also referred to [5]. 142 New_BS_Found (NBF) 144 A trigger from the link layer to IP layer in a mobile node to 145 report that new BS is detected. 147 Link_Going_Down (LGD) 148 A trigger from the link layer to IP layer in a mobile node to 149 report that a link down event will be fired in the near future. 151 Link_Up (LUP) 153 A trigger from the link layer to IP layer in a mobile node to 154 report that the mobile node completes L2 connection 155 establishment with a new BS and preparation for carrying IP 156 packets. 158 Link_Switch (LSW) 160 A control command come from IP layer to the link layer in a 161 mobile node in order to force the mobile node to switch from an 162 old BS to a new BS. 164 3. Deployment Architectures for Mobility on IEEE 802.16e 166 In this section, we describe two possible deployment architectures of 167 802.16 networks and the mobile node's handover over it. 169 Figure 1 shows the deployment with two IP subnets. An access router 170 (AR) and several base stations (BSs) form a single subnet. In this 171 case, the movement between BSs does not always require IP mobility. 172 The handover from BS1 to BS2, or within same subnet, can be carried 173 out using link layer mobility without IP mobility. However, the 174 handover from BS5 to BS6 may require IP mobility since they belong to 175 the different subnets respectively. 177 /-------------------------------------\ 178 | IP Backbone | 179 \-------------------------------------/ 180 | | 181 /-----------\ /-----------\ 182 | AR1 | | AR2 | 183 \-----------/ \-----------/ 184 / / | \ \ / / | \ \ 185 / / | \ \ / / | \ \ 186 / | | | \ / | | | \ 187 BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10 189 Figure 1. The 802.16e deployment architecture in a centralized manner 191 Figure 2 represents an alternative 802.16e deployment where a subnet 192 consists of only single AR and single BS. In this case, a BS may be 193 integrated with an AR, composing one box in view of implementation. 194 Every handover in this architecture means a change of subnet, 195 resulting in IP handovers. 197 /------------------\ 198 | IP Backbone | 199 \------------------/ 200 / | \ 201 / | \ 202 / | \ 203 ----- ----- ----- 204 | AR1 | | AR2 | | AR3 | 205 | BS1 | | BS2 | | BS3 | 206 ----- ----- ----- 208 Figure 2. The 802.16e deployment architecture with integrated BSs & 209 ARs 211 The FMIPv6 is a kind of IP mobility solution, so needs to be 212 performed when a mobile node (MN) handovers across the subnet. 213 Regarding its specific operation, the FBU (Fast Binding Update) 214 message is sent conditionally depending on whether the target BS is 215 under different subnet or not. The information may be available to 216 the MN before handover through the link-layer technology or 217 implementation-specific method. This document describes the case 218 when an MN handovers across the subnet. 220 4. IEEE 802.16e Handovers Overview 222 Compared with the handover in the wireless LAN, the 802.16e handover 223 mechanism consists of more steps since 802.16e embraces the 224 functionality for elaborate parameter adjustment and procedural 225 flexibility. 227 When an MN stays in a link, it listens to L2 neighbor advertisement 228 messages, named MOB_NBR-ADV, from its serving BS. A BS broadcasts 229 them periodically to identify the network and announces the 230 characteristics of neighbor BSs. Once receiving this, the mobile 231 node decodes this message to find out information about the 232 parameters of neighbors for its future handover. With the provided 233 information in MOB_NBR-ADV, the MN may minimize the handover latency 234 by decoding the channel number of neighbors and reducing the scanning 235 time, or may select the target BS tailored for its taste. 237 In 802.16e, the handover procedure is conceptually divided into two 238 steps: ``handover preparation'' and ``handover execution'' [8]. The 239 handover preparation begins with a decision by MN or BS. During the 240 handover preparation, neighbors are compared by the metrics such as 241 signal strength or QoS parameters and the target BS is selected among 242 them. If necessary, the MN may try to associate (initial ranging) 243 with candidate BSs to expedite a potential future handover. Once the 244 MN decides handover, it may notify its intent by sending MOB_MSHO-REQ 245 message to the serving BS (s-BS). The serving BS then replies with 246 MOB_BSHO-RSP containing the recommended BSs to the MN after 247 negotiating with candidates. When the target is decided, the BS may 248 confirm the handover to target BS (t-BS) over backbone. The BS also 249 can trigger handover with MOB_BSHO-REQ message. 251 After handover preparation, handover execution starts. When the MN 252 sets the target BS finally and is about to move to the link, it sends 253 MOB_HO-IND to the serving BS as a final indication for handover and 254 for resource release, then conducting handover. Once the MN switches 255 the link, it shall conduct 802.16e ranging through which it can 256 acquire physical parameters from the target BS, tuning its parameters 257 to the target BS. After ranging with the target BS successfully, the 258 MN negotiates basic capabilities and performs authentication, finally 259 registering with the target BS. If the target BS has already learned 260 some contexts such as authentication or capability parameters through 261 backbone, the MN may omit the corresponding procedures. Since this 262 point, the target BS starts to serve the MN and communication via 263 target BS is available. However, when the MN moves to different 264 subnet, it should re-configure new IP address and re-establish IP 265 connection. To resume the active session of previous link, the MN 266 should perform IP handover additionally. 268 5. Network Topology Acquisition and Cell Selection 270 An MN can learn the network topology and acquire the link information 271 in two ways. One method is via L2 neighbor advertisements. A BS 272 supporting mobile functionality shall broadcast a MOB_NBR-ADV message 273 including the network topology at a periodic interval (maximum 274 interval, 1sec.). This message includes the BSID and channel 275 information of neighbor BSs and is used to facilitate the MN's 276 synchronization with neighbor BSs. An MN can collect the necessary 277 information of the neighbor BSs for its future handover through this 278 message. 280 Another method for acquisition of network topology is scanning, which 281 is the process to seek and monitor available BS suitability as 282 targets for handover. While the MOB_NBR-ADV message includes static 283 information about neighbor BSs, scanning provides rather dynamic 284 parameters such as link quality parameters. Since the MOB_NBR-ADV 285 message delivers a list of neighbor BSIDs periodically and scanning 286 provides a way to sort out some adequate BSs, it is recommended that 287 when new BSs are found in the advertisement, the MN identifies them 288 via scanning and resolves their BSIDs to the associated network 289 information. The association, optional initial ranging procedure 290 occurring during scanning, is one of the helpful methods to 291 facilitate the impending handover. An MN is able to get ranging 292 parameters and service availability information for the purpose of 293 proper selection of the target BS and expediting a potential future 294 handover to it. 296 After learning about neighbors, the MN may compare them to find 297 another BS which can serve better than the serving BS. The target BS 298 may be determined considering various criteria such as required QoS, 299 cost, user preference, policy, etc. How to select the target BS is 300 not in the scope of this draft. 302 6. Interaction between FMIPv6 and IEEE 802.16e 304 In this section, we describe the desirable FMIPv6 handover procedure 305 in 802.16 networks. We introduce four primitives for the close 306 interaction between FMIPv6 and 802.16e, and present their interaction 307 by using the primitives. 309 6.1. Access Router Discovery 311 Once a new BS is detected through the reception of MOB_NBR-ADV, an MN 312 tries to learn the associated AR information. With the new BSID in 313 MOB_NBR-ADV message, the MN requests the associated AR information to 314 the PAR (Previous AR). To minimize the possible latency from new BS 315 detection in link layer (802.16) to the resolution in IP layer 316 (fmip6), the link layer can trigger the New_BS_Found primitive to the 317 IP layer within the MN. 319 The result of resolving BSIDs is a list of [BSID, AR-Info] tuple(s). 320 AR-Info consists of the corresponding new AR's information including 321 its prefix, IP address and link layer address. The RtSolPr (Router 322 Solicitation for Proxy Advertisement) and PrRtAdv (Proxy Router 323 Advertisement) messages of FMIPv6 are used for the resolution. Note 324 that this phase is not necessarily involved with any specific 325 handover procedure and the MN may perform them at any convenient 326 time. 328 6.2. Handover Preparation 330 As mentioned in Section 4, an MN may initiate handover by sending 331 MOB_MSHO-REQ to the serving BS and receive MOB_BSHO-RSP from it. 332 Also, the BS can initiate handover by sending MOB_BSHO-REQ to the MN. 333 After receiving either MOB_BSHO-RSP or MOB_BSHO-REQ message, the MN 334 may send FBU (Fast Binding Update) to the PAR. At this time, the 335 Link_Going_Down (LGD) is introduced to signal IP layer of the arrival 336 of MOB_BSHO-REQ/MOB_BSHO-RSP in link layer as soon as possible. The 337 MN may be notified of the target BS as a parameter at the same time. 338 On receiving LGD, the MN's IP layer (fmip6) sends FBU to the PAR. 339 Before sending FBAck (Fast Binding Acknowledgement) to the MN, the 340 PAR sets up tunnel between PCoA (Previous CoA) and NCoA (New CoA) by 341 exchange of HI (Handover Initiate) and HAck (Handover Acknowledge) 342 messages, and forwards the packets destined for MN to NCoA. During 343 this time, an available NCoA is confirmed with HAck message. 345 After the MN sends a MOB_HO-IND to the serving BS, data packet 346 transfer between MN and serving BS is not allowed any more. 347 Therefore, if possible, the MN should exchange a FBU and a FBAck 348 message with the PAR before sending MOB_HO-IND to the serving BS so 349 as to operate as predictive mode. 351 6.3. Handover Execution 353 When the FBAck message arrives before handover, the MN runs 354 predictive mode. If the MN can not acquire FBAck message on the 355 current link, it should run the reactive mode after handover. Note 356 that when MOB_HO-IND is sent prior to the arrival of FBAck, the MN 357 should operate as reactive mode since when the serving BS receives 358 this message, it releases MN's all connections and resources. The 359 serving BS may retain the resource until the resource retain timer 360 expires. 362 If applicable, the primitive from IP layer to link layer can be used 363 to optimize the L2/L3 interaction. Link_Switch trigger (LSW) can be 364 issued from the IP layer to the link layer within MN when FBAck 365 message arrives to make the possibility of predictive mode operation 366 higher or to promote the issue of MOB_HO-IND message immediately. 367 Similar concept has already introduced for the wireless LAN in [5] 368 and the IEEE 802.21 document [8] also provides MIH (Media Independent 369 Handover) command service for the same reason. 371 After switching links, the MN synchronizes with the target BS and 372 performs the 802.16e network entry procedure. The MN may exchange 373 the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages 374 with the target BS. Some of these messages may be omitted if the 375 (previously) serving BS transferred the context to the target BS over 376 the backbone before. On completion of the network entry procedure, 377 according to WiMAX model, the initial service flow (ISF) for IPv6 CS 378 needs to be established by the network. ISF is the first flow of the 379 pre-provisioned service before carrying the data packets. For more 380 detailed description, refer to [9]. After that, the MN's link layer 381 informs its IP layer of the fact with Link_Up (LUP) trigger, forcing 382 IP layer to send FNA (Fast Neighbor Advertisement) to the NAR (New 383 AR). In case of reactive mode, the MN should include the FBU within 384 the FNA message. 386 6.4. Handover Completion 388 Receiving the FNA, in predictive mode, the NAR should verify the 389 availability of NCoA. If the NAR detects the NCoA is already in use, 390 it MUST discard the FBU and reply with Router Advertisement with 391 Neighbor Advertisement Acknowledge (NAACK) option to the MN. 392 Otherwise, the NAR starts to flush the buffered packets to MN. In 393 reactive mode, the NAR should forward the inner FBU to the PAR, 394 establishing the tunnel, finally forwarding the packets destined to 395 the NCoA to the MN. 397 7. The Examples of Handover Scenario 399 In this section, the recommended handover procedure over 802.16 400 network is shown for both predictive mode and reactive mode. Note 401 that there is no need of IP mobility when the target BS is under same 402 subnet. Therefore FBU is sent conditionally depending on whether the 403 target BS is under different subnet or not. In following scenarios, 404 the MN is assumed to move to the different subnet. 406 7.1. Predictive Mode 408 The procedure is described briefly as follows. 410 1. A BS broadcasts MOB_NBR-ADV periodically. 412 2. If the MN discovers a new neighbor BS in this message, it 413 may perform scanning for it. 415 3. When a new BS is found through the MOB_NBR-ADV or 416 scanning, the MN's link layer notifies it of the IP layer 417 (fmip6) by New_BS_Found primitive. 419 4. Then the MN may try to resolve new neighbor's BSID to the 420 associated AR by exchange of RtSolPr and PrRtAdv with the 421 PAR. 423 5. The MN initiates handover by sending MOB_MSHO-REQ to the 424 serving BS and receives MOB_BSHO-RSP from it. Also, the 425 serving BS can initiate handover by sending MOB_BSHO-REQ 426 to the MN. 428 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ 429 from BS, its link layer triggers Link_Going_Down to IP 430 layer. 432 7. On reception of LGD, the MN IP layer exchanges FBU and 433 FBAck with the PAR. Before sending the FBAck, the PAR 434 establishes tunnel with the NAR by exchange of HI and HAck 435 messages. During this time, the NAR confirms NCoA 436 availability in new link via HAck. 438 8. When the FBAck arrives before handover, the MN 439 operates as predictive mode. It sends MOB_HO-IND 440 as a final indication of handovers. 442 9. The MN conducts handover to the target BS and performs 443 802.16e network entry procedure. 445 10. As soon as the network entry and ISF setup are completed, 446 the MN's link layer signals its IP layer with Link_Up and 447 then the MN issues the FNA encapsulating FBU to the NAR. 449 11. When the NAR receives the FNA from the MN, it delivers 450 the buffered packets to the MN. 452 ---------- ---------- 453 MN L3 MN L2 | s-BS PAR | | NAR t-BS | 454 ---------- ---------- 455 | | | | | | 456 |<-NBF-|<-----MOB_NBR-ADV-------| | | | 457 | |( Scanning )| | | | 458 |--------------(RtSolPr)-------------->| | | 459 |<--------------PrRtAdv----------------| | | 460 | | | | | | 461 | | [MN initiation] | | | | 462 | |------MOB_MNHO-REQ----->| | | | 463 |<-LGD-|<-----MOB_BSHO-RSP------| | | | 464 | | or | | | | 465 | | [BS initiation] | | | | 466 |<-LGD-|<-----MOB_BSHO-REQ------| | | | 467 | | | | | | 468 |------------------FBU---------------->| | | 469 | | | |-----HI---->| | 470 | | | |<---HACK----| | 471 |<-----------------FBACK---------------|--> | | 472 |(LSW)>|-------MOB_HO-IND------>| forward========>| | 473 disconnect | packets | | 474 | connect | | | | 475 |<-LUP-|<--------802.16 network reentry & ISF ------------>| 476 connect | | | | 477 |-------------------------FNA---------------------->| | 478 |<===============================================deliver | 479 | | | | packets | 481 Figure 3. Predictive Fast Handover in 802.16 483 7.2. Reactive Mode 485 The procedure is described as follows in case of reactive mode. 487 1. A BS broadcasts MOB_NBR-ADV periodically. 489 2. If the MN discovers a new neighbor BS in this message, it 490 may perform scanning for it. 492 3. When a new BS is found through the MOB_NBR-ADV or 493 scanning, the MN's link layer notifies it of the IP layer 494 (fmip6) by New_BS_Found primitive. 496 4. Then the MN may try to resolve new neighbor's BSID to the 497 associated AR by exchange of RtSolPr and PrRtAdv with the 498 PAR. 500 5. The MN initiates handover by sending MOB_MSHO-REQ to the 501 BS and receives MOB_BSHO-RSP from the BS. Also, the BS 502 can initiate handover by sending MOB_BSHO-REQ to the MN. 504 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ 505 from the BS, its link layer triggers Link_Going_Down to 506 IP layer, thereby sending FBU if possible. 508 7. When the MN can not receive FBAck on the current link, it 509 runs the reactive mode. After conducting handover to the 510 target BS, the MN performs the 802.16e network entry 511 procedure. 513 8. As soon as the network entry and ISF setup are completed, 514 the MN's link layer signals its IP layer with Link_Up and 515 then the MN issues the FNA encapsulating FBU to the NAR. 517 9. Receiving FNA, the NAR verifies the availability of NCoA 518 and forwards the inner FBU to the PAR, establishing the 519 tunnel. 521 10. If the NAR detects the NCoA is already in use, it MUST 522 discard the FBU and reply with Router Advertisement with 523 NAACK option to the MN. Otherwise, it delivers the 524 packets destined for NCoA to the MN. 526 ---------- ---------- 527 MN L3 MN L2 | s-BS PAR | | NAR t-BS | 528 ---------- ---------- 529 | | | | | | 530 |<-NBF-|<-----MOB_NBR-ADV-------| | | | 531 | |( Scanning )| | | | 532 |--------------(RtSolPr)-------------->| | | 533 |<--------------PrRtAdv----------------| | | 534 | | | | | | 535 | | [MN initiation] | | | | 536 | |------MOB_MSHO-REQ----->| | | | 537 |<-LGD-|<-----MOB_BSHO-RSP------| | | | 538 | | or | | | | 539 | | [BS initiation] | | | | 540 |<-LGD-|<-----MOB_BSHO-REQ------| | | | 541 | | | | | | 542 |-----------------(FBU)--------------->| | | 543 | |-------MOB_HO-IND------>| | | | 544 disconnect| | | | | 545 | connect | | | | 546 |<-LUP-|<--------802.16 network reentry & ISF ------------>| 547 connect | | | | 548 |-------------------------FNA[FBU]----------------->| | 549 | | | |<---FBU-----| | 550 | | | |----FBACK-->| | 551 | | | forward | | 552 | | | packets=========>| | 553 |<================================================deliver | 554 | | | | packets | 556 Figure 4. Reactive Fast Handover in 802.16 558 8. Security Considerations 560 The security consideration of the FMIPv6 specification [3] is 561 applicable to this document. Particularly, 802.16e architecture 562 supports a number of mandatory authorization mechanisms, for example, 563 EAP-TTLS, EAP-SIM and EAP-AKA, as well as, secure IP address 564 management between the MN and its network entity. That will allow 565 secure handover operation between the mobile node and the network 566 entity. 568 Further security considerations will be carefully studied along with 569 this document. 571 9. Acknowledgment 573 Many thanks IETF Mobility Working Group members of KWISF (Korea 574 Wireless Internet Standardization Forum) for their efforts on this 575 work. In addition, we would like to thank Alper E. Yegin, Jinhyeock 576 Choi and Misun Do who have provided the technical advice. 578 10. Normative References 580 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 581 Levels", BCP 14, RFC 2119, March 1997. 583 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 584 IPv6", RFC 3775, June 2004. 586 [3] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 587 July 2005. 589 [4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", 590 RFC 4260, November 2005. 592 [5] Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast 593 Handover", draft-irtf-mobopts-l2-abstractions-01 (work in 594 progress), September 2006. 596 [6] IEEE 802.16 TGe Working Document, "Amendment 2: 597 Physical and Medium Access Control Layers for Combined Fixed and 598 Mobile Operation in Licensed Bands and Corrigendum 1", 599 IEEE Std 802.16e��-2005 and IEEE Std 802.16��-2004/Cor 1-2005, 600 February 2006. 602 [7] IEEE 802.21 Working Group Document,"Draft IEEE Standard for Local 603 and Metropolitan Area Networks: Media Independent Handover 604 Services", IEEE P802.21/D03.00, December 2006. 606 [8] Kim, K., Kim, C., and T. Kim, "A Seamless Handover Mechanism 607 for IEEE 802.16e Broadband Wireless Access", International 608 Conference on Computational Science, vol. 2, pp. 527-534, 2005. 610 [9] WiMAX Network Working Group, "End-to-End Network Systems 611 Architecture (Stage 3: Detailed Protocols and Procedures)", 612 August 2006 release 1 V&V Draft. 614 Authors' Addresses 616 Heejin Jang 617 Samsung Advanced Institute of Technology 618 P.O. Box 111 619 Suwon 440-600 620 Korea 622 Email: heejin.jang@samsung.com 624 Junghoon Jee 625 Electronics and Telecommunications Research Institute 626 161 Gajeong-dong, Yuseong-gu 627 Daejon 305-350 628 Korea 630 Email: jhjee@etri.re.kr 632 Youn-Hee Han 633 Korea University of Technology and Education 635 Email: yh21.han@gmail.com 637 Soohong Daniel Park 638 Samsung Electronics 639 416 Maetan-3dong, Yeongtong-gu 640 Suwon 442-742 641 Korea 643 Email: soohong.park@samsung.com 645 Jaesun Cha 646 Electronics and Telecommunications Research Institute 647 161 Gajeong-dong, Yuseong-gu 648 Daejon 305-350 649 Korea 651 Email: jscha@etri.re.kr 653 Full Copyright Statement 655 Copyright (C) The Internet Society (2007). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 664 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 665 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 666 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 Acknowledgment 695 Funding for the RFC Editor function is provided by the IETF 696 Administrative Support Activity (IASA).