idnits 2.17.1 draft-ietf-mipshop-fh80216e-00.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 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 665. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 are 2 instances of too long lines in the document, the longest one being 3 characters 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 (April 12, 2006) is 6561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'BSID' on line 316 -- Looks like a reference, but probably isn't: 'AR-Info' on line 316 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) ** Downref: Normative reference to an Experimental draft: draft-ietf-mipshop-fast-mipv6 (ref. '3') ** Downref: Normative reference to an Informational draft: draft-ietf-mipshop-80211fh (ref. '4') == Outdated reference: A later version (-05) exists of draft-koki-mobopts-l2-abstractions-03 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 13 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 Expires: October 14, 2006 Junghoon Jee 5 ETRI 6 Youn-Hee Han 7 KUT 8 Soohong Daniel Park 9 Samsung Electronics 10 Jaesun Cha 11 ETRI 12 April 12, 2006 14 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks 15 draft-ietf-mipshop-fh80216e-00.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 October 14, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . 13 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 17 69 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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 BS switching and soft handover in IEEE 802.16e. In this version 94 of the draft, we consider the hard handover mode because this is the 95 default mode. We begin with a summary of a handover procedure on 96 802.16e [6], the amendment of 802.16 for mobility. Then the 97 interaction between 802.16e and FMIPv6 is presented with the 98 primitives proposed by IEEE 802.21 for the close interaction between 99 Layer 2 and Layer 3. Lastly, the examples of handover scenario are 100 described for both predictive mode and reactive mode. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document is to be interpreted as described in RFC2119 [1]. 108 Most of terms used in this draft are defined in Mobile IPv6 [2] and 109 FMIPv6 [3]. 111 The following terms come from IEEE 802.16e specification [6]. 113 MOB_NBR-ADV 115 IEEE 802.16e neighbor advertisement message sent periodically 116 by a base station. 118 MOB_MSHO-REQ 120 IEEE 802.16e handover request message sent by a mobile node. 122 MOB_BSHO-RSP 124 IEEE 802.16e handover response message sent by a base station. 126 MOB_BSHO-REQ 128 IEEE 802.16e handover request message sent by a base station. 130 MOB_HO-IND 132 IEEE 802.16e handover indication message sent by a mobile node. 134 BSID 136 IEEE 802.16e base station identifier. 138 Additionally, the following triggers are proposed by IEEE 802.21 [7] 139 and the standardization is in progress. We also referred to [5]. 141 New_BS_Found (NBF) 143 A trigger from the link layer to IP layer in a mobile node to 144 report that new BS is detected. 146 Link_Going_Down (LGD) 147 A trigger from the link layer to IP layer in a mobile node to 148 report that a link down event will be fired in the near future. 150 Link_Up (LUP) 152 A trigger from the link layer to IP layer in a mobile node to 153 report that the mobile node completes L2 connection 154 establishment with a new BS. 156 Link_Switch (LSW) 158 A control command come from IP layer to the link layer in a 159 mobile node in order to force to switch to new BS. 161 3. Deployment Architectures for Mobility on IEEE 802.16e 163 In this section, we describe two possible deployment architectures of 164 802.16 networks and the mobile node's handover over it. 166 Figure 1 shows the deployment with two IP subnets. An access router 167 (AR) and several base stations (BSs) form a single subnet. In this 168 case, the movement between BSs does not always require IP mobility. 169 The handover from BS1 to BS2, or within same subnet, can be carried 170 out using link layer mobility without IP mobility. However, the 171 handover from BS5 to BS6 may require IP mobility since they belong to 172 the different subnets respectively. 174 /-------------------------------------\ 175 | IP Backbone | 176 \-------------------------------------/ 177 | | 178 /-----------\ /-----------\ 179 | AR1 | | AR2 | 180 \-----------/ \-----------/ 181 / / | \ \ / / | \ \ 182 / / | \ \ / / | \ \ 183 / | | | \ / | | | \ 184 BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10 186 Figure 1. The 802.16e deployment architecture 187 in a centralized manner 189 Figure 2 represents an alternative 802.16e deployment where a subnet 190 consists of only single AR and single BS. In this case, a BS may be 191 integrated with an AR, composing one box in view of implementation. 192 Every handover in this architecture means a change of subnet, 193 resulting in IP handovers. 195 /------------------\ 196 | IP Backbone | 197 \------------------/ 198 / | \ 199 / | \ 200 / | \ 201 ----- ----- ----- 202 | AR1 | | AR2 | | AR3 | 203 | BS1 | | BS2 | | BS3 | 204 ----- ----- ----- 206 Figure 2. The 802.16e deployment architecture 207 with the integrated BS & AR 209 The FMIPv6 is a kind of IP mobility solution, so needs to be 210 performed when a mobile node (MN) handovers across the subnet. 211 Regarding its specific operation, the FBU (Fast Binding Update) 212 message is sent conditionally depending on whether the target BS is 213 under different subnet or not. The information may be available to 214 the MN before handover through the link-layer technology or 215 implementation-specific method. This document describes the case 216 when an MN handovers across the subnet. 218 4. IEEE 802.16e Handovers Overview 220 Compared with the handover in the wireless LAN, the 802.16e handover 221 mechanism consists of more steps since 802.16e embraces the 222 functionality for elaborate parameter adjustments and procedural 223 flexibility. 225 When an MN stays in a link, it listens to L2 neighbor advertisement 226 message, named MOB_NBR-ADV, from its serving BS. A BS broadcasts it 227 periodically to identify the network and announces the 228 characteristics of neighbor BSs. Once the MN receives this, it 229 decodes this message to find out information about the parameters of 230 neighbors for its future handover. With the provided information in 231 this message, the MN may minimize the handover latency by decoding 232 the channel number of neighbors and reducing the scanning time, or 233 may select the target BS tailored for its taste. 235 In 802.16e, the handover procedure is conceptually divided into two 236 steps: ``handover preparation'' and ``handover execution'' [8]. The 237 handover preparation begins with a decision of MN or BS. During the 238 handover preparation, neighbors are compared by the metrics such as 239 signal strength or QoS parameters and the target BS is selected among 240 them. If necessary, the MN may try to associate (initial ranging) 241 with candidate BSs to expedite a potential future handover. Once the 242 MN decides handover, it may notify its intent by sending MOB_MSHO-REQ 243 message to the serving BS (s-BS). The serving BS then replies with 244 MOB_BSHO-RSP containing the recommended BSs to the MN after 245 negotiating with candidates. When the target is decided, the BS may 246 confirm the handover to target BS (t-BS) over backbone. The BS also 247 can trigger handover with MOB_BSHO-REQ message. 249 After handover preparation, handover execution occurs. When the MN 250 sets the target BS finally and is about to move to the link, it sends 251 MOB_HO-IND to the serving BS as a final indication for handover and 252 for resource release for it, then conducting handover. Once the MN 253 switches the link, it shall conduct 802.16e ranging through which it 254 can acquire physical parameters from the target BS, tuning its 255 parameters to the target BS. After ranging with the target BS 256 successfully, the MN negotiates basic capabilities and performs 257 authentication, finally registering with the target BS. If the 258 target BS has already learned some contexts such as authentication or 259 capability parameters through backbone, the MN may omit the 260 corresponding procedures. Since this point, the target BS starts to 261 serve the MN and communication via target BS is available. However, 262 when the MN moves to different subnet, it should re-configure new IP 263 address and re-establish IP connection. To resume the active session 264 of previous link, the MN should perform IP handover additionally. 266 5. Network Topology Acquisition and Cell Selection 268 An MN can learn the network topology and acquire the link information 269 in two ways. One method is via L2 neighbor advertisement. A BS 270 supporting mobile functionality shall broadcast MOB_NBR-ADV message 271 including the network topology at a periodic interval (maximum 272 interval, 1sec.). This message includes the BSID and channel 273 information of neighbor BSs and is used to facilitate the MN's 274 synchronization with neighbor BSs. An MN can collect the necessary 275 information of the neighbor BSs for its future handover through this 276 message. 278 Another method for acquisition of network topology is scanning, which 279 is the process to seek and monitor available BS suitability as 280 targets for handover. While the MOB_NBR-ADV message includes static 281 information about neighbor BSs, scanning provides rather dynamic 282 parameters such as link quality parameters. Since the MOB_NBR-ADV 283 message delivers a list of neighbor BSIDs periodically and scanning 284 provides a way to sort out some adequate BSs, it is recommended that 285 when new BSs are found in the advertisement, the MN identifies them 286 via scanning and resolves their BSIDs to the associated network 287 information. The association, optional initial ranging procedure 288 occurring during scanning, is one of the helpful method to facilitate 289 the impending handover. An MN is able to get ranging parameters and 290 service availability information for the purpose of proper selection 291 of the target BS and expediting a potential future handover to it. 293 After learning about neighbors, the MN may compare them to find 294 another BS which can serve better than the serving BS. The target BS 295 may be determined considering various criteria such as required QoS, 296 cost, user preference, policy, etc. How to select the target BS is 297 not in the scope of this draft. 299 6. Interaction between FMIPv6 and IEEE 802.16e 301 In this section, we describe the desirable FMIPv6 handover procedure 302 in 802.16 networks. We introduce four primitives for the close 303 interaction between FMIPv6 and 802.16e, and the interaction is 304 presented with them. 306 6.1. Access Router Discovery 308 Once a new BS is detected through the reception of MOB_NBR-ADV, an MN 309 tries to learn the associated AR information. This procedure is 310 called AR discovery. With new BSID in MOB_NBR-ADV message, the MN 311 requests the associated AR information to the PAR (Previous AR). To 312 minimize the possible latency from new BS detection in link layer 313 (802.16) to the resolution in IP layer (fmip6), the link layer can 314 trigger the New_BS_Found primitive to the IP layer within the MN. 316 The result of resolving BSIDs is a list of [BSID, AR-Info] tuples. 317 AR-Info consists of the corresponding new AR's information including 318 its prefix, IP address and link layer address. The RtSolPr (Router 319 Solicitation for Proxy Advertisement) and PrRtAdv (Proxy Router 320 Advertisement) messages of FMIPv6 are used for the resolution. Note 321 that the AR discovery procedure is not necessarily involved with any 322 specific handover procedure and the MN may perform them at any 323 convenient time. 325 6.2. Handover Preparation 327 As mentioned in Section 4, an MN may initiate handover by sending 328 MOB_MSHO-REQ to the serving BS and receive MOB_BSHO-RSP from it. 329 Also, the BS can initiate handover by sending MOB_BSHO-REQ to the MN. 330 After receiving either MOB_BSHO-RSP or MOB_BSHO-REQ message, the MN 331 may send FBU (Fast Binding Update) to the PAR. At this time, the 332 Link_Going_Down (LGD) is introduced to signal IP layer of the arrival 333 of MOB_BSHO-REQ/MOB_BSHO-RSP in link layer as soon as possible. The 334 MN may be notified of the target BS as a parameter at the same time. 335 On receiving LGD, the MN's IP layer (fmip6) sends FBU to the PAR. 336 Before sending FBAck (Fast Binding Acknowledgement) to the MN, the 337 PAR sets up tunnel between PCoA (Previous CoA) and NCoA (New CoA) by 338 exchange of HI (Handover Initiate) and HAck (Handover Acknowledge) 339 messages, and forwards the packets destined for MN to NCoA. During 340 this time, an available NCoA is confirmed with HAck message. 342 After the MN sends a MOB_HO-IND to the serving BS, any packet data 343 transfer between MN and serving BS is not allowed any more even 344 though the resource retain timer does not expire in serving BS. 345 Therefore, if possible, the MN should exchange a FBU and a FBAck 346 message with the PAR before sending MOB_HO-IND to the serving BS so 347 as to operate as predictive mode. 349 6.3. Handover Execution 351 When the FBAck message arrives before handover, the MN runs 352 predictive mode. If the MN can not acquire FBAck message on the 353 current link, it should run reactive mode after handover. Note that 354 when MOB_HO-IND is sent prior to the arrival of FBAck, the MN should 355 operate as reactive mode since when the serving BS receives this 356 message, it releases MN's all connections and resources. The serving 357 BS may retain the resource until the resource retain timer expires. 359 If applicable, the primitive from IP layer to link layer can be used 360 to optimize the L2/L3 interaction. Link_Switch trigger (LSW) can be 361 issued from the IP layer to link layer within MN when FBAck message 362 arrives to make the possibility of predictive mode operation higher 363 or to promote the issue of MOB_HO-IND message immediately. Similar 364 concept has already introduced for the wireless LAN in [5] and IEEE 365 802.21 document [8] also provides MIH (Media Independent Handover) 366 command service for the same reason. 368 After switching links, the MN synchronizes with the target BS and 369 performs the 802.16e network entry procedure. The MN may exchange 370 the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages 371 with the target BS. Some of these messages may be omitted if the 372 (previously) serving BS transferred the context to the target BS over 373 the backbone before. As soon as completing the network entry, the 374 MN's link layer informs its IP layer of the fact with Link_Up (LUP) 375 trigger, forcing IP layer to send FNA (Fast Neighbor Advertisement) 376 to the NAR (New AR). In case of reactive mode, the MN should include 377 the FBU within the FNA message. 379 6.4. Handover Completion 381 Receiving the FNA, in predictive mode, the NAR should verify the 382 availability of NCoA. If the NAR detects the NCoA is already in use, 383 it MUST discard the FBU and reply with Router Advertisement with 384 Neighbor Advertisement Acknowledge (NAACK) option to the MN. 385 Otherwise, the NAR starts to flush the buffered packets to MN. In 386 reactive mode, the NAR should forward the inner FBU to the PAR, 387 establishing the tunnel, finally forwarding the packets destined to 388 the NCoA to the MN. 390 7. The Examples of Handover Scenario 392 In this section, the recommended handover procedure over 802.16 393 network is shown for both predictive mode and reactive mode. Note 394 that there is no need of IP mobility when the target BS is under same 395 subnet. Therefore FBU is sent conditionally depending on whether the 396 target BS is under different subnet or not. In following scenarios, 397 the MN is assumed to move to different subnet. 399 7.1. Predictive Mode 401 The procedure is described briefly as follows. 403 1. A BS broadcasts MOB_NBR-ADV periodically. 405 2. If the MN discovers a new neighbor BS in this message, it 406 may perform scanning for it. 408 3. When a new BS is found through the MOB_NBR-ADV or 409 scanning, the MN's link layer notifies it of the IP layer 410 (fmip6) by New_BS_Found primitive. 412 4. Then the MN may try to resolve new neighbor's BSID to the 413 associated AR by exchange of RtSolPr and PrRtAdv with the 414 PAR. 416 5. The MN initiates handover by sending MOB_MSHO-REQ to the 417 serving BS and receives MOB_BSHO-RSP from it. Also, the 418 serving BS can initiate handover by sending MOB_BSHO-REQ 419 to the MN. 421 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ 422 from BS, its link layer triggers Link_Going_Down to IP 423 layer. 425 7. On reception of LGD, the MN IP layer exchanges FBU and 426 FBAck with the PAR. Before sending the FBAck, the PAR 427 establishes tunnel with the NAR by exchange of HI and HAck 428 messages. During this time, the NAR confirms NCoA 429 availability in new link via HAck. 431 8. When the FBAck arrives before handover, the MN 432 operates as predictive mode. It sends MOB_HO-IND 433 as a final indication of handovers. 435 9. The MN conducts handover to the target BS and performs 436 802.16e network entry procedure. 438 10. When the network entry is completed, the MN's link layer 439 signals its IP layer with Link_Up and then the MN issues 440 FNA to the NAR. 442 11. When the NAR receives the FNA from the MN, it delivers 443 the buffered packets to the MN. 445 ---------- ---------- 446 MN L3 MN L2 | s-BS PAR | | NAR t-BS | 447 ---------- ---------- 448 | | | | | | 449 |<-NBF-|<-----MOB_NBR-ADV-------| | | | 450 | |( Scanning )| | | | 451 |--------------(RtSolPr)-------------->| | | 452 |<--------------PrRtAdv----------------| | | 453 | | | | | | 454 | | [MN initiation] | | | | 455 | |------MOB_MNHO-REQ----->| | | | 456 |<-LGD-|<-----MOB_BSHO-RSP------| | | | 457 | | or | | | | 458 | | [BS initiation] | | | | 459 |<-LGD-|<-----MOB_BSHO-REQ------| | | | 460 | | | | | | 461 |------------------FBU---------------->| | | 462 | | | |-----HI---->| | 463 | | | |<---HACK----| | 464 |<-----------------FBACK---------------|--> | | 465 |(LSW)>|-------MOB_HO-IND------>| forward========>| | 466 disconnect | packets | | 467 | connect | | | | 468 |<-LUP-|<--------------802.16 network reentry------------->| 469 connect | | | | 470 |-------------------------FNA---------------------->| | 471 |<===============================================deliver | 472 | | | | packets | 474 Figure 3. Predictive Fast Handover in 802.16 476 7.2. Reactive Mode 478 The procedure is described as follows in case of reactive mode. 480 1. A BS broadcasts MOB_NBR-ADV periodically. 482 2. If the MN discovers a new neighbor BS in this message, it 483 may perform scanning for it. 485 3. When a new BS is found through the MOB_NBR-ADV or 486 scanning, the MN's link layer notifies it of the IP layer 487 (fmip6) by New_BS_Found primitive. 489 4. Then the MN may try to resolve new neighbor's BSID to the 490 associated AR by exchange of RtSolPr and PrRtAdv with the 491 PAR. 493 5. The MN initiates handover by sending MOB_MSHO-REQ to the 494 BS and receives MOB_BSHO-RSP from the BS. Also, the BS 495 can initiate handover by sending MOB_BSHO-REQ to the MN. 497 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ 498 from the BS, its link layer triggers Link_Going_Down to 499 IP layer, thereby sending FBU if possible. 501 7. When the MN can not receive FBAck on the current link, it 502 runs the reactive mode. After conducting handover to the 503 target BS, the MN performs the 802.16e network entry 504 procedure. 506 8. As soon as the network entry procedure is completed, the 507 MN's link layer signals its IP layer with Link_Up and then 508 the MN issues the FNA encapsulating FBU to the NAR. 510 9. Receiving FNA, the NAR verifies the availability of NCoA 511 and forwards the inner FBU to the PAR, establishing the 512 tunnel. 514 10. If the NAR detects the NCoA is already in use, it MUST 515 discard the FBU and reply with Router Advertisement with 516 NAACK option to the MN. Otherwise, it delivers the 517 packets destined for NCoA to the MN. 519 ---------- ---------- 520 MN L3 MN L2 | s-BS PAR | | NAR t-BS | 521 ---------- ---------- 522 | | | | | | 523 |<-NBF-|<-----MOB_NBR-ADV-------| | | | 524 | |( Scanning )| | | | 525 |--------------(RtSolPr)-------------->| | | 526 |<--------------PrRtAdv----------------| | | 527 | | | | | | 528 | | [MN initiation] | | | | 529 | |------MOB_MSHO-REQ----->| | | | 530 |<-LGD-|<-----MOB_BSHO-RSP------| | | | 531 | | or | | | | 532 | | [BS initiation] | | | | 533 |<-LGD-|<-----MOB_BSHO-REQ------| | | | 534 | | | | | | 535 |-----------------(FBU)--------------->| | | 536 | |-------MOB_HO-IND------>| | | | 537 disconnect| | | | | 538 | connect | | | | 539 |<-LUP-|<--------------802.16 network reentry------------->| 540 connect | | | | 541 |-------------------------FNA[FBU]----------------->| | 542 | | | |<---FBU-----| | 543 | | | |----FBACK-->| | 544 | | | forward | | 545 | | | packets=========>| | 546 |<================================================deliver | 547 | | | | packets | 549 Figure 4. Reactive Fast Handover in 802.16 551 8. Security Considerations 553 The security consideration of the FMIPv6 specification [3] is 554 applicable to this document. Particularly, 802.16e architecture 555 supports a number of mandatory authorization mechanisms, for example, 556 EAP-TTLS, EAP-SIM and EAP-AKA, as well as, secure IP address 557 management between the MN and its network entity. That will allow 558 secure handover operation between the mobile node and the network 559 entity. 561 Further security considerations will be carefully studied along with 562 this document. 564 9. Acknowledgment 566 Many thanks IETF Mobility Working Group members of KWISF (Korea 567 Wireless Internet Standardization Forum) for their efforts on this 568 work. In addition, we would like to thank Alper E. Yegin, Jinhyeock 569 Choi and Misun Do who have provided the technical advice. 571 10. Normative References 573 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 574 Levels", BCP 14, RFC 2119, March 1997. 576 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 577 IPv6", RFC 3775, June 2004. 579 [3] Koodli, R., "Fast Handovers for Mobile IPv6", 580 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 581 October 2004. 583 [4] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", 584 draft-ietf-mipshop-80211fh-04 (work in progress), April 2005. 586 [5] Mitani, K., "Unified L2 Abstractions for L3-Driven Fast 587 Handover", draft-koki-mobopts-l2-abstractions-03 (work in 588 progress), October 2005. 590 [6] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment 591 for Physical and Medium Access Control Layers for Combined Fixed 592 and Mobile Operation in Licensed Bands", 802.16e/D12, October 2005. 594 [7] IEEE 802.21 Working Group Document (Draft Standard),"Draft IEEE 595 Standard for Local and Metropolitan Area Networks: Media 596 Independent Handover Services", IEEE P802.21/D00.05, January 2006. 597 March 2004. 599 [8] Kim, K., Kim, C., and T. Kim, "A Seamless Handover Mechanism 600 for IEEE 802.16e Broadband Wireless Access", International 601 Conference on Computational Science, vol. 2, pp. 527-534, 2005. 603 Authors' Addresses 605 Heejin Jang 606 Samsung Advanced Institute of Technology 607 P.O. Box 111 608 Suwon 440-600 609 Korea 611 Email: heejin.jang@samsung.com 613 Junghoon Jee 614 Electronics and Telecommunications Research Institute 615 161 Gajeong-dong, Yuseong-gu 616 Daejon 305-350 617 Korea 619 Email: jhjee@etri.re.kr 621 Youn-Hee Han 622 Korea University of Technology and Education 623 Korea 625 Email: yh21.han@gmail.com 627 Soohong Daniel Park 628 Samsung Electronics 629 416 Maetan-3dong, Yeongtong-gu 630 Suwon 442-742 631 Korea 633 Email: soohong.park@samsung.com 635 Jaesun Cha 636 Electronics and Telecommunications Research Institute 637 161 Gajeong-dong, Yuseong-gu 638 Daejon 305-350 639 Korea 641 Email: jscha@etri.re.kr 643 Intellectual Property Statement 645 The IETF takes no position regarding the validity or scope of any 646 Intellectual Property Rights or other rights that might be claimed to 647 pertain to the implementation or use of the technology described in 648 this document or the extent to which any license under such rights 649 might or might not be available; nor does it represent that it has 650 made any independent effort to identify any such rights. Information 651 on the procedures with respect to rights in RFC documents can be 652 found in BCP 78 and BCP 79. 654 Copies of IPR disclosures made to the IETF Secretariat and any 655 assurances of licenses to be made available, or the result of an 656 attempt made to obtain a general license or permission for the use of 657 such proprietary rights by implementers or users of this 658 specification can be obtained from the IETF on-line IPR repository at 659 http://www.ietf.org/ipr. 661 The IETF invites any interested party to bring to its attention any 662 copyrights, patents or patent applications, or other proprietary 663 rights that may cover technology that may be required to implement 664 this standard. Please address the information to the IETF at 665 ietf-ipr@ietf.org. 667 Disclaimer of Validity 669 This document and the information contained herein are provided on an 670 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 671 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 672 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 673 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 674 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 675 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 677 Copyright Statement 679 Copyright (C) The Internet Society (2006). This document is subject 680 to the rights, licenses and restrictions contained in BCP 78, and 681 except as set forth therein, the authors retain all their rights. 683 Acknowledgment 685 Funding for the RFC Editor function is currently provided by the 686 Internet Society.