idnits 2.17.1 draft-ietf-mipshop-fh80216e-02.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 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. 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. ** 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 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 (July 8, 2007) is 6137 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'BSID' is mentioned on line 266, but not defined == Missing Reference: 'AR-Info' is mentioned on line 266, but not defined == Outdated reference: A later version (-07) exists of draft-irtf-mobopts-l2-abstractions-03 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (Obsoleted by RFC 5268) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 7 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: January 9, 2008 ETRI 6 Youn-Hee Han 7 KUT 8 Soohong Daniel Park 9 Samsung Electronics 10 Jaesun Cha 11 ETRI 12 July 8, 2007 14 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks 15 draft-ietf-mipshop-fh80216e-02.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 January 9, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 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 Handovers Overview . . . . . . . . . . . . . . . 6 57 4. Network Topology Acquisition and Cell 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 . . . . . . . . . . . . . . . . . . . 10 63 6. The Examples of Handover Scenario . . . . . . . . . . . . . . 11 64 6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 11 65 6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 13 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 67 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 16 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 70 Intellectual Property and Copyright Statements . . . . . . . . . . 19 72 1. Introduction 74 Mobile IPv6 (MIPv6) [RFC3775] is currently available to provide the 75 session continuity during handover. It is capable of handling IP 76 handovers between different subnets in a transparent way for higher- 77 level connections. However, the handover latency resulting from 78 MIPv6 is often unacceptable to real-time traffic such as Voice over 79 IP, and Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC4068] has 80 been proposed as a mechanism to reduce the handover latency by 81 predicting and preparing the impending handover in advance. 83 As [RFC4260] pointed out, FMIPv6 assumes the support from the link- 84 layer technology, but the specific link-layer information available, 85 as well as the timing of its availability (before, during or after a 86 handover occurs), differs according to the particular link-layer 87 technology in use. 89 This document describes Mobile IPv6 Fast Handovers over 802.16 90 networks. We begin with a summary of a handover procedure of 91 [802.16e], the amendment of 802.16 for mobility. Then the 92 interaction between 802.16e and FMIPv6 is presented with the 93 primitives proposed by IEEE 802.21 [802.21] for the close interaction 94 between Layer 2 and Layer 3. Lastly, the examples of handover 95 scenario are described for both predictive mode and reactive mode. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document is to be interpreted as described in [RFC2119]. 103 Most of terms used in this draft are defined in MIPv6 [RFC3775] and 104 FMIPv6 [RFC4068]. 106 The following terms come from IEEE 802.16e specification [802.16e]. 108 MOB_NBR-ADV 110 IEEE 802.16e neighbor advertisement message sent periodically 111 by a base station. 113 MOB_MSHO-REQ 115 IEEE 802.16e handover request message sent by a mobile node. 117 MOB_BSHO-RSP 119 IEEE 802.16e handover response message sent by a base station. 121 MOB_BSHO-REQ 123 IEEE 802.16e handover request message sent by a base station. 125 MOB_HO-IND 127 IEEE 802.16e handover indication message sent by a mobile node. 129 BSID 131 IEEE 802.16e base station identifier. 133 Additionally, the following primitives are proposed by [802.21] and 134 the standardization is in progress. We also referred to 135 [I-D.irtf-mobopts-l2-abstractions]. 137 Link_Detected (LD) 139 A trigger from the link layer to the IP layer in a mobile node 140 to report that a new link is detected. 142 Link_Going_Down (LGD) 143 A trigger from the link layer to the IP layer in a mobile node 144 to report that a link down event will be fired in the near 145 future. 147 Link_Up (LUP) 149 A trigger from the link layer to the IP layer in a mobile node 150 to report that the mobile node completes the link layer 151 connection establishment with a new BS. 153 Handover_Commit (HC) 155 A control command from the IP layer to the link layer in a 156 mobile node in order to force the mobile node to switch from an 157 old BS to a new BS. 159 3. IEEE 802.16e Handovers Overview 161 Compared with the handover in the wireless LAN, the 802.16e handover 162 mechanism consists of more steps since 802.16e embraces the 163 functionality for elaborate parameter adjustment and procedural 164 flexibility. 166 When an MN stays in a link, it listens to L2 neighbor advertisement 167 messages, named MOB_NBR-ADV, from its serving BS. A BS broadcasts 168 them periodically to identify the network and announces the 169 characteristics of neighbor BSs. Once receiving this, the MN decodes 170 this message to find out information about the parameters of neighbor 171 BSs for its future handover. With the provided information in 172 MOB_NBR-ADV, the MN may minimize the handover latency by obtaining 173 the channel number of neighbors and reducing the scanning time, or 174 may select the better target BS based on the signal strength, QoS 175 level, service price, etc. 177 In 802.16e, the handover procedure is conceptually divided into two 178 steps: ``handover preparation'' and ``handover execution'' 179 [SH802.16e]. The handover preparation can be initiated by either MN 180 or BS. During this period, neighbors are compared by the metrics 181 such as signal strength or QoS parameters and a target BS is selected 182 among them. If necessary, the MN may try to associate (initial 183 ranging) with candidate BSs to expedite a future handover. Once the 184 MN decides handover, it notifies its intent by sending a MOB_MSHO-REQ 185 message to the serving BS. The BS then replies with a MOB_BSHO-RSP 186 containing the recommended BSs to the MN after negotiating with 187 candidates. Optionally it may confirm handover to the target BS over 188 backbone when the target is decided. The BS alternatively may 189 trigger handover with a MOB_BSHO-REQ message. 191 After handover preparation, handover execution starts. When the MN 192 selects the target BS and is about to move to the new link, it sends 193 a MOB_HO-IND to the serving BS as a final indication for handover and 194 conducts handover. Once the MN makes a new attachment, it conducts 195 802.16e ranging through which it can acquire physical parameters from 196 the target BS, tuning its parameters to the target BS. After ranging 197 with the target BS successfully, the MN negotiates basic capabilities 198 such as maximum transmit power, modulator/demodulator type, etc. It 199 then performs authorization and key exchange procedures, and finally 200 registers with the target BS. If the target BS has already learned 201 some contexts such as authentication or capability parameters through 202 backbone, it may omit the corresponding procedures. For the detailed 203 procedures of the 802.16 network entry, refer to section 6.3.22 of 204 [802.16e]. After completing registration, the target BS starts to 205 serve the MN and communication via target BS is available. However, 206 when the MN moves to a different subnet, it should re-configure a new 207 IP address and re-establish IP connection. To resume the active 208 session of previous link, the MN should perform IP layer handover 209 additionally. 211 4. Network Topology Acquisition and Cell Selection 213 An MN can learn the network topology and acquire the link information 214 in two ways. One method is via L2 neighbor advertisements. A BS 215 supporting mobile functionality shall broadcast a MOB_NBR-ADV message 216 including the network topology periodically (maximum interval, 217 1sec.). This message includes the BSID and channel information of 218 neighbor BSs, and is used to facilitate the MN's synchronization with 219 neighbor BSs. An MN can collect the necessary information of the 220 neighbor BSs for its future handover through this message. 222 Another method for acquisition of network topology is scanning, which 223 is the process to seek and monitor available BSs in order to find 224 suitable handover targets. While a MOB_NBR-ADV message includes 225 static information about neighbor BSs, scanning provides rather 226 dynamic parameters such as link quality parameters. Since the 227 MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically 228 and scanning provides a way to sort out some adequate BSs, it is 229 recommended that when new BSs are found in the advertisement, the MN 230 identifies them via scanning and resolves their BSIDs to the 231 information of the subnet where the BS is connected. The 232 association, an optional initial ranging procedure occurring during 233 scanning, is one of the helpful methods to facilitate the impending 234 handover. The MN is able to get ranging parameters and service 235 availability information for the purpose of proper selection of the 236 target BS and expediting a potential future handover to it. The 237 detailed explanation of association is described in section 6.3.22 of 238 [802.16e]. 240 After learning about neighbors, the MN may compare them to find a BS 241 which can serve better than the serving BS. The target BS may be 242 determined by considering various criteria such as required QoS, 243 cost, user preference, policy, etc. How to select the target BS is 244 not in the scope of this draft. 246 5. Interaction between FMIPv6 and IEEE 802.16e 248 In this section, we describe the desirable FMIPv6 handover procedure 249 in 802.16 networks. We introduce four primitives proposed by IEEE 250 802.21 WG [802.21] for the close interaction between FMIPv6 and 251 802.16e, and present the detailed interaction procedures. 253 5.1. Access Router Discovery 255 Once a new BS is detected through the reception of a MOB_NBR-ADV and 256 scanning, an MN may try to learn the associated AR information as 257 soon as possible. In order to enable quick discovery of the 258 associated AR information in the IP layer, the link layer (802.16) 259 triggers a Link_Detected primitive to the IP layer (FMIPv6) on 260 detecting the new BS. 262 Receiving the Link_Detected from the link layer, the IP layer tries 263 to learn the associated AR information by exchanging the RtSolPr 264 (Router Solicitation for Proxy Advertisement) and PrRtAdv (Proxy 265 Router Advertisement) with the PAR. The result of resolving BSIDs is 266 a list of [BSID, AR-Info] tuple(s). AR-Info consists of AR's prefix, 267 IP address and link layer address. 269 5.2. Handover Preparation 271 As mentioned in section 4, an MN initiates handover by sending a 272 MOB_MSHO-REQ to the BS and receives a MOB_BSHO-RSP from the BS as a 273 response. Alternatively, the BS can initiate handover by sending a 274 MOB_BSHO-REQ to the MN. After receiving either MOB_BSHO-RSP or 275 MOB_BSHO-REQ message, the MN sends an FBU (Fast Binding Update) to 276 the PAR. At this time, the Link_Going_Down (LGD) is used to signal 277 the IP layer of the arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link 278 layer as soon as possible. According to 7.3.6 of [802.21], this 279 notification is designed to be triggered when the link layer 280 connection is expected to go down (Link_Down) within a certain time 281 interval, as a consequence, it can be used for making adequate a 282 priori preparation to before actual handover 284 On receiving LGD, the IP layer sends an FBU to the PAR. Before 285 sending an FBack (Fast Binding Acknowledgement) to the MN, the PAR 286 sets up tunnel between PCoA (Previous CoA) and NCoA (New CoA) by 287 exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) 288 messages with the NAR, and forwards the packets destined for the MN 289 to NCoA. During this time, an available NCoA is confirmed with a 290 HAck message. 292 After the MN sends a MOB_HO-IND to the serving BS, data packet 293 transfer between MN and BS is not allowed any more. Therefore, if 294 possible, the MN should exchange an FBU and an FBack message with the 295 PAR before sending a MOB_HO-IND to the BS so as to operate in 296 predictive mode. 298 5.3. Handover Execution 300 When an FBack message arrives before handover, an MN runs in 301 predictive mode. If the MN can not acquire an FBack message on the 302 current link, it should run in reactive mode after handover. Note 303 that when a MOB_HO-IND is sent before an FBack arrives, the MN will 304 operate in reactive mode because the serving BS releases MN's all 305 connections and resources after it receives a MOB_HO-IND The BS may 306 retain the resource until the resource retain timer expires. 308 When an FBack message arrives, a Handover_Commit (HC) may be issued 309 from the IP layer to the link layer so as to promote the issue of 310 MOB_HO-IND message immediately. Until the HC occurs, the link-layer 311 may keep the current link and postpone sending a MOB_HO-IND message 312 as long as possible to operate in predictive mode. Similar concept 313 has already introduced for the wireless LAN in 314 [I-D.irtf-mobopts-l2-abstractions]. An HC is provided by MIH (Media 315 Independent Handover) command service of the [802.21]. 317 After switching links, the MN synchronizes with the target BS and 318 performs the 802.16e network entry procedure. The MN exchanges the 319 RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages with 320 the target BS. Some of these messages may be omitted if the 321 (previously) serving BS transferred the context to the target BS over 322 the backbone beforehand. On completion of the network entry 323 procedure, according to WiMAX model, the initial connection between 324 the MN and the NAR such as initial service flow (ISF) needs to be 325 established by the network. For more detailed description, refer to 326 [WiMAX-NWG]. After that, the 802.16 layer informs the IP layer of 327 the fact with a Link_Up (LUP) primitive, forcing the IP layer to send 328 an FNA (Fast Neighbor Advertisement) to the NAR. In case of reactive 329 mode, the MN should include an FBU within an FNA message. 331 5.4. Handover Completion 333 When an MN establishes link connectivity with the NAR, it sends an 334 FNA message to the NAR. When an NCoA in the FNA is acceptable, in 335 predictive mode, the NAR stops defending the NCoA and delivers the 336 buffered packets to the MN. In reactive mode, the MN sends the FNA 337 containing the FBU. If the NAR detects the NCoA is already in use, 338 it MUST discard the FBU and reply with Router Advertisement with 339 Neighbor Advertisement Acknowledge (NAACK) option to the MN. 340 Otherwise, the NAR forwards the inner FBU to the PAR, establishes the 341 tunnel, and finally delivers packets destined for the NCoA to the MN. 343 6. The Examples of Handover Scenario 345 In this section, the recommended handover procedure over 802.16 346 network is shown for both predictive mode and reactive mode. In 347 following scenarios, an MN is assumed to move to a different subnet. 349 6.1. Predictive Mode 351 The procedure is described briefly as follows. 353 1. A BS broadcasts a MOB_NBR-ADV periodically. 355 2. If an MN discovers a new neighbor BS in this message, it 356 may perform scanning for the BS. 358 3. When a new BS is found through the MOB_NBR-ADV and 359 scanning, the MN's link layer notifies it to the IP layer 360 (FMIPv6) by a Link_Detected primitive. 362 4. Then the MN tries to resolve the new BS's BSID to the 363 associated AR by exchange of RtSolPr and PrRtAdv messages 364 with the PAR. 366 5. The MN initiates handover by sending a MOB_MSHO-REQ message 367 to the BS and receives a MOB_BSHO-RSP from the BS. 368 Alternatively, the BS may initiate handover by sending a 369 MOB_BSHO-REQ to the MN. 371 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ 372 from the BS, its link layer triggers a Link_Going_Down 373 primitive to the IP layer. 375 7. On reception of a Link_Going_Down, the MN's IP layer sends 376 an FBU message to the PAR. If the PAR receives this, it 377 establishes tunnel with the NAR by exchange of HI and HAck 378 messages. During this time, the NAR confirms NCoA 379 availability in the new link via HAck. 381 8. The MN receives an FBack message before its handover and 382 operates in predictive mode after handover. It sends a 383 MOB_HO-IND message as a final indication of handovers. 384 Issue of a MOB_HO-IND may be promoted by using a 385 Handover_Commit command from the IP layer. 387 9. The MN conducts handover to the target BS and performs 388 802.16e network entry procedure. 390 10. As soon as the network entry procedure is completed, the 391 MN's link layer signals the IP layer with a Link_Up and 392 the MN issues an FNA to the NAR. 394 11. When the NAR receives the FNA from the MN, it delivers 395 the buffered packets to the MN. 397 ---------- ---------- 398 MN L3 MN L2 | s-BS PAR | | NAR t-BS | 399 ---------- ---------- 400 | | | | | | 401 |<-LD--|<-----MOB_NBR-ADV-------| | | | 402 | | & Scanning | | | | 403 |--------------(RtSolPr)-------------->| | | 404 |<--------------PrRtAdv----------------| | | 405 | | | | | | 406 | | [MN initiation] | | | | 407 | |------MOB_MNHO-REQ----->| | | | 408 |<-LGD-|<-----MOB_BSHO-RSP------| | | | 409 | | or | | | | 410 | | [BS initiation] | | | | 411 |<-LGD-|<-----MOB_BSHO-REQ------| | | | 412 | | | | | | 413 |------------------FBU---------------->| | | 414 | | | |-----HI---->| | 415 | | | |<---HACK----| | 416 |<-----------------FBack---------------|--> | | 417 |(HC)>|--------MOB_HO-IND------>| forward========>| | 418 disconnect | packets | | 419 | connect | | | | 420 |<-LUP-|<-------------802.16 network entry---------------->| 421 connect | | | | 422 |-------------------------FNA---------------------->| | 423 |<===============================================deliver | 424 | | | | packets | 426 Figure 3. Predictive Fast Handover in 802.16 428 6.2. Reactive Mode 430 The procedure is described as follows in case of reactive mode. 432 1.~ 7. The same as the case of predictive Mode. 434 8. In case the MN cannot receive an FBack message before its 435 handover, it operates in reactive mode after handover. 436 It sends a MOB_HO-IND message as a final indication of 437 handovers. 439 9. The MN conducts handover to the target BS and performs 440 802.16e network entry procedure. 442 10. As soon as the network entry procedure is completed, the 443 MN's link layer signals the IP layer with a Link_Up and 444 the MN issues an FNA encapsulating an FBU to the NAR. 446 11. Receiving the FNA, the NAR verifies the availability of 447 NCoA and forwards the inner FBU to the PAR, establishing 448 the tunnel. If the NAR detects an NCoA is already in use, 449 it MUST discard the FBU and reply with Router Advertisement 450 with NAACK option to the MN. Otherwise, it delivers the 451 packets destined for NCoA to the MN. 453 ---------- ---------- 454 MN L3 MN L2 | s-BS PAR | | NAR t-BS | 455 ---------- ---------- 456 | | | | | | 457 |<-LD--|<-----MOB_NBR-ADV-------| | | | 458 | | & Scanning | | | | 459 |--------------(RtSolPr)-------------->| | | 460 |<--------------PrRtAdv----------------| | | 461 | | | | | | 462 | | [MN initiation] | | | | 463 | |------MOB_MSHO-REQ----->| | | | 464 |<-LGD-|<-----MOB_BSHO-RSP------| | | | 465 | | or | | | | 466 | | [BS initiation] | | | | 467 |<-LGD-|<-----MOB_BSHO-REQ------| | | | 468 | | | | | | 469 |-----------------(FBU)--------------->| | | 470 | |-------MOB_HO-IND------>| | | | 471 disconnect| | | | | 472 | connect | | | | 473 |<-LUP-|<-------------802.16 network entry---------------->| 474 connect | | | | 475 |-------------------------FNA[FBU]----------------->| | 476 | | | |<---FBU-----| | 477 | | | |----FBack-->| | 478 | | | forward | | 479 | | | packets=========>| | 480 |<================================================deliver | 481 | | | | packets | 483 Figure 4. Reactive Fast Handover in 802.16 485 7. Security Considerations 487 The security consideration of the FMIPv6 specification [RFC4068] is 488 applicable to this document. Particularly, 802.16e architecture 489 supports a number of mandatory authorization mechanisms, for example, 490 EAP-TTLS, EAP-SIM and EAP-AKA, as well as, secure IP address 491 management between the MN and its network entity. That will allow 492 secure handover operation between the MN and the network entity. 494 8. Acknowledgment 496 Many thanks IETF Mobility Working Group members of KWISF (Korea 497 Wireless Internet Standardization Forum) for their efforts on this 498 work. In addition, we would like to thank Alper E. Yegin, Jinhyeock 499 Choi, Yoshihiro Ohba and Behcet Sarikaya who have provided the 500 technical advice. 502 9. Normative References 504 [I-D.irtf-mobopts-l2-abstractions] 505 Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast 506 Handover", draft-irtf-mobopts-l2-abstractions-03 (work in 507 progress), May 2007. 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", BCP 14, RFC 2119, March 1997. 512 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 513 in IPv6", RFC 3775, June 2004. 515 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 516 July 2005. 518 [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 519 Networks", RFC 4260, November 2005. 521 [802.16e] IEEE 802.16 TGe Working Document, "Amendment 2: Physical 522 and Medium Access Control Layers for Combined Fixed and 523 Mobile Operation in Licensed Bands and Corrigendum 1", 524 IEEE Std 802.16e��-2005 and IEEE Std 802.16��-2004/ 525 Cor 1-2005, February 2006. 527 [802.21] IEEE 802.21 Working Group Document,"Draft IEEE Standard 528 for Local and Metropolitan Area Networks: Media 529 Independent Handover Services", IEEE P802.21/D05.00, 530 April 2007. 532 [SH802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover 533 Mechanism for IEEE 802.16e Broadband Wireless Access", 534 International Conference on Computational Science, 535 vol. 2, pp. 527-534, 2005. 537 [WiMAX-NWG] WiMAX Network Working Group, "WiMAX Forum Network 538 Architecture (Stage 3: Detailed Protocols and Procedures)", 539 Release 1.0.0, March 28, 2007. 541 Authors' Addresses 543 Heejin Jang 544 Samsung Advanced Institute of Technology 545 P.O. Box 111 546 Suwon 440-600 547 Korea 549 Email: heejin.jang@samsung.com 551 Junghoon Jee 552 Electronics and Telecommunications Research Institute 553 161 Gajeong-dong, Yuseong-gu 554 Daejon 305-350 555 Korea 557 Email: jhjee@etri.re.kr 559 Youn-Hee Han 560 Korea University of Technology and Education 562 Email: yh21.han@gmail.com 564 Soohong Daniel Park 565 Samsung Electronics 566 416 Maetan-3dong, Yeongtong-gu 567 Suwon 442-742 568 Korea 570 Email: soohong.park@samsung.com 572 Jaesun Cha 573 Electronics and Telecommunications Research Institute 574 161 Gajeong-dong, Yuseong-gu 575 Daejon 305-350 576 Korea 578 Email: jscha@etri.re.kr 580 Full Copyright Statement 582 Copyright (C) The IETF Trust (2007). 584 This document is subject to the rights, licenses and restrictions 585 contained in BCP 78, and except as set forth therein, the authors 586 retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 591 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 592 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 593 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Intellectual Property 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Acknowledgment 622 Funding for the RFC Editor function is provided by the IETF 623 Administrative Support Activity (IASA).