idnits 2.17.1 draft-ietf-mipshop-fh80216e-04.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 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document 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 (November 11, 2007) is 6005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'BSID' is mentioned on line 287, but not defined == Missing Reference: 'AR-Info' is mentioned on line 287, but not defined == Outdated reference: A later version (-07) exists of draft-irtf-mobopts-l2-abstractions-04 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (Obsoleted by RFC 5268) Summary: 4 errors (**), 0 flaws (~~), 5 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: May 14, 2008 ETRI 6 Youn-Hee Han 7 KUT 8 Soohong Daniel Park 9 Samsung Electronics 10 Jaesun Cha 11 ETRI 12 November 11, 2007 14 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks 15 draft-ietf-mipshop-fh80216e-04.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 May 14, 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 Handover Overview . . . . . . . . . . . . . . . . 6 57 4. Network Topology Acquisition and Network Selection . . . . . . 8 58 5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 9 59 5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 9 60 5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 9 61 5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 10 62 5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 10 63 6. The Examples of Handover Scenario . . . . . . . . . . . . . . 12 64 6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 12 65 6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 13 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 67 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 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 Mobile IPv6 (MIPv6) [RFC3775] is currently available to provide the 76 session continuity during handover. It is capable of handling IP 77 handover between different subnets in a transparent way for higher- 78 layer connections. However, the handover latency resulting from 79 MIPv6 is often unacceptable to real-time traffic such as Voice over 80 IP, and Mobile IPv6 Fast Handover protocol (FMIPv6) [RFC4068] has 81 been proposed as a mechanism to reduce the handover latency by 82 predicting and preparing the impending handover in advance. 84 As [RFC4260] pointed out, FMIPv6 assumes the support from the link- 85 layer technology, but the specific link-layer information available, 86 as well as the timing of its availability (before, during or after a 87 handover occurs), differs according to the particular link-layer 88 technology in use. This document is proposed to provide 89 informational guide to the developers about how to optimize the 90 FMIPv6 handover procedure, specifically in the 802.16 networks. 92 To provide the seamless handover, this proposal tries to maximize the 93 benefits of synchronizing the link layer handover with the fast IP 94 handover procedure by exploiting the link-layer handover indicators 95 when available. In this proposal, the Media Independent Handover 96 (MIH) services being defined in the IEEE 802.21 working group 97 [802.21] is used as an example of link-layer specific indicators for 98 this purpose. This document introduces a set of useful messages 99 among primitives proposed by IEEE 802.21 which can be cooperated with 100 802.16 handover and FMIPv6 procedures, and provides the most 101 appropriate timing for the trigger of each selected primitive during 102 802.16 handover procedure. 104 We begin with a summary of a handover procedure of [802.16e] which is 105 the amendment of 802.16 for mobility. Then the interaction between 106 802.16e and FMIPv6 is presented with the primitives proposed by IEEE 107 802.21 [802.21] for the close interaction between Layer 2 and Layer 108 3. Lastly, the examples of handover scenarios are described for both 109 predictive mode and reactive mode. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document is to be interpreted as described in [RFC2119]. 117 Most of terms used in this document are defined in MIPv6 [RFC3775] 118 and FMIPv6 [RFC4068]. 120 The following terms come from IEEE 802.16e specification [802.16e]. 122 MOB_NBR-ADV 124 An IEEE 802.16e neighbor advertisement message sent 125 periodically by a base station. 127 MOB_MSHO-REQ 129 An IEEE 802.16e handover request message sent by a mobile node. 131 MOB_BSHO-RSP 133 An IEEE 802.16e handover response message sent by a base 134 station. 136 MOB_BSHO-REQ 138 An IEEE 802.16e handover request message sent by a base 139 station. 141 MOB_HO-IND 143 An IEEE 802.16e handover indication message sent by a mobile 144 node. 146 BSID 148 An IEEE 802.16e base station identifier. 150 Additionally, the following primitives are proposed by [802.21] and 151 the standardization is in progress. 153 Link_Detected (LD) 155 A trigger from the link layer to the IP layer in a mobile node 156 to report that a new link is detected. 158 Link_Handover_Imminent (LHI) 160 A trigger from the link layer to the IP layer in a mobile node 161 to report that a native link layer handover/switch decision has 162 been made and its execution is imminent. 164 Link_Up (LUP) 166 A trigger from the link layer to the IP layer in a mobile node 167 to report that the mobile node completes the link layer 168 connection establishment with a new BS. 170 Handover_Commit (HC) 172 A control command from the IP layer to the link layer in a 173 mobile node in order to force the mobile node to switch from an 174 old BS to a new BS. 176 3. IEEE 802.16e Handover Overview 178 Compared with the handover in the wireless LAN, the 802.16e handover 179 mechanism consists of more steps since 802.16e embraces the 180 functionality for elaborate parameter adjustment and procedural 181 flexibility. 183 When a mobile node (MN) stays in a link, it listens to L2 neighbor 184 advertisement messages, named a MOB_NBR-ADV, from its serving base 185 station (BS). A BS broadcasts them periodically to identify the 186 network and announces the characteristics of neighbor BSs. Once 187 receiving this, the MN decodes this message to find out information 188 about the parameters of neighbor BSs for its future handover. With 189 the provided information in a MOB_NBR-ADV, the MN may minimize the 190 handover latency by obtaining the channel number of neighbors and 191 reducing the scanning time, or may select the better target BS based 192 on the signal strength, QoS level, service price, etc. 194 The handover procedure is conceptually divided into two steps: 195 ``handover preparation'' and ``handover execution'' [SH-802.16e]. 196 The handover preparation can be initiated by either the MN or the BS. 197 During this period, neighbors are compared by the metrics such as 198 signal strength or QoS parameters and a target BS is selected among 199 them. If necessary, the MN may try to associate (initial ranging) 200 with candidate BSs to expedite a future handover. Once the MN 201 decides handover, it notifies its intent by sending a MOB_MSHO-REQ 202 message to the serving BS. The BS then replies with a MOB_BSHO-RSP 203 containing the recommended BSs to the MN after negotiating with 204 candidates. Optionally it may confirm handover to the target BS over 205 backbone when the target is decided. The BS alternatively may 206 trigger handover with a MOB_BSHO-REQ message. 208 After handover preparation, handover execution starts. When the MN 209 is about to move to the new link after deciding the target BS, it 210 sends a MOB_HO-IND message to the serving BS as a final indication 211 for its handover. Once the MN makes a new attachment, it conducts 212 802.16e ranging through which it can acquire physical parameters from 213 the target BS, tuning its parameters to the target BS. After ranging 214 with the target BS successfully, the MN negotiates basic capabilities 215 such as maximum transmit power and modulator/demodulator type. It 216 then performs authentication and key exchange procedure, and finally 217 registers with the target BS. If the target BS has already learned 218 some contexts such as authentication or capability parameters through 219 backbone, it may omit the corresponding procedures. For the detailed 220 procedure of the 802.16 network entry, refer to section 6.3.22 of 221 [802.16e]. After completing registration, the target BS starts to 222 serve the MN and communication via target BS is available. However, 223 when the MN moves to a different subnet, it should re-configure a new 224 IP address and re-establish an IP connection. To resume the active 225 session of the previous link, the MN should perform IP layer handover 226 additionally. 228 4. Network Topology Acquisition and Network Selection 230 This section describes how discovery of adjacent networks and 231 selection of target network work in 802.16e for background 232 information. 234 An MN can learn the network topology and acquire the link information 235 in two ways. One method is via L2 neighbor advertisements. A BS 236 supporting mobile functionality shall broadcast a MOB_NBR-ADV message 237 including the network topology periodically (maximum interval, 238 1sec.). This message includes BSIDs and channel information of 239 neighbor BSs, and is used to facilitate the MN's synchronization with 240 neighbor BSs. An MN can collect the necessary information of the 241 neighbor BSs through this message for its future handover. 243 Another method for acquisition of network topology is scanning, which 244 is the process to seek and monitor available BSs in order to find 245 suitable handover targets. While a MOB_NBR-ADV message includes 246 static information about neighbor BSs, scanning provides rather 247 dynamic parameters such as link quality parameters. Since the 248 MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically 249 and scanning provides a way to sort out some adequate BSs, it is 250 recommended that when new BSs are found in the advertisement, the MN 251 identifies them via scanning and resolves their BSIDs to the 252 information of the subnet where the BS is connected. The 253 association, an optional initial ranging procedure occurring during 254 scanning, is one of the helpful methods to facilitate the impending 255 handover. The MN is able to get ranging parameters and service 256 availability information for the purpose of proper selection of the 257 target BS and expediting a potential future handover to it. The 258 detailed explanation of association is described in section 6.3.22 of 259 [802.16e]. 261 After learning about neighbors, the MN may compare them to find a BS 262 which can serve better than the serving BS. The target BS may be 263 determined by considering various criteria such as required QoS, 264 cost, user preference, and policy. How to select the target BS is 265 not in the scope of this document. 267 5. Interaction between FMIPv6 and IEEE 802.16e 269 In this section, we describe the desirable FMIPv6 handover procedure 270 in 802.16 networks. We introduce four primitives proposed by 271 [802.21] for the close interaction between FMIPv6 and 802.16e, and 272 present the detailed interaction procedure. 274 5.1. Access Router Discovery 276 Once a new BS is detected through the reception of a MOB_NBR-ADV and 277 scanning, an MN may try to learn the associated AR information as 278 soon as possible. In order to enable quick discovery of the 279 associated AR information in the IP layer, the link layer (802.16) 280 triggers a Link_Detected primitive to the IP layer (FMIPv6) on 281 detecting the new BS. 283 Receiving the Link_Detected from the link layer, the IP layer tries 284 to learn the associated AR information by exchanging the RtSolPr 285 (Router Solicitation for Proxy Advertisement) and the PrRtAdv (Proxy 286 Router Advertisement) with the PAR. The result of resolving BSIDs is 287 a list of [BSID, AR-Info] tuple(s). AR-Info consists of AR's prefix, 288 IP address and link layer address. 290 5.2. Handover Preparation 292 As mentioned in section 4, an MN initiates handover by sending a 293 MOB_MSHO-REQ to the BS and receives a MOB_BSHO-RSP from the BS as a 294 response. Alternatively, the BS can initiate handover by sending a 295 MOB_BSHO-REQ to the MN. After receiving either MOB_BSHO-RSP or 296 MOB_BSHO-REQ message, the MN sends an FBU (Fast Binding Update) to 297 the PAR. 299 After receiving either a MOB_BSHO-RSP or MOB_BSHO-REQ, the MN 300 triggers the Link_Handover_Imminent (LHI) in order to signal the IP 301 layer of the arrival of MOB_BSHO-REQ/MOB_BSHO-RSP in the link layer 302 as soon as possible. According to [802.21], the LHI primitive is 303 used to report that a native link layer handover/switch decision has 304 been made and its execution is imminent. At this time, the target 305 network decided in the link layer is notified to the IP layer by 306 using the MAC_access_router parameter (MAC address of the target AR) 307 of the LHI primitive. 309 On receiving the LHI, the IP layer sends an FBU to the PAR. Before 310 sending an FBack (Fast Binding Acknowledgement) to the MN, the PAR 311 sets up a tunnel between the PCoA (Previous CoA) and the NCoA (New 312 CoA) by exchanging HI (Handover Initiate) and HAck (Handover 313 Acknowledge) messages with the NAR, and forwards the packets destined 314 for the MN to NCoA. During the tunnel set-up procedure, the NAR 315 checks the availability of the NCoA and confirms it in the HAck 316 message. 318 After the MN sends a MOB_HO-IND to the serving BS, data packet 319 transfer between the MN and the BS is not allowed any more. 320 Therefore, if possible, the MN should exchange an FBU and an FBack 321 message with the PAR before sending a MOB_HO-IND to the BS so as to 322 operate in predictive mode. 324 5.3. Handover Execution 326 When an FBack message arrives before handover, an MN runs in 327 predictive mode. If the MN can not acquire an FBack message on the 328 current link, it should run in reactive mode after handover. Note 329 that when a MOB_HO-IND is sent before an FBack arrives, the MN will 330 operate in reactive mode because the serving BS releases the MN's all 331 connections and resources after it receives a MOB_HO-IND. The BS may 332 retain the resource until the resource retain timer expires. 334 When an FBack message arrives, a Handover_Commit (HC) may be issued 335 from the IP layer to the link layer optionally so as to promote 336 sending the MOB_HO-IND message immediately. Until the HC occurs, the 337 link-layer keeps the current link if possible and postpone sending a 338 MOB_HO-IND message as long as possible to operate in predictive mode. 339 Similar concept has already introduced for the wireless LAN in 340 [I-D.irtf-mobopts-l2-abstractions]. An HC is also a command service 341 provided by [802.21]. 343 After switching links, the MN synchronizes with the target BS and 344 performs the 802.16e network entry procedure. The MN exchanges the 345 RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP and REG-REQ/RSP messages with 346 the target BS. Some of these messages may be omitted if the 347 (previously) serving BS transferred the context to the target BS over 348 the backbone beforehand. When the network entry procedure is 349 completed and the link layer is ready for data transmission, it 350 informs the IP layer of the fact with a Link_Up (LUP) primitive, 351 forcing the IP layer to send an FNA (Fast Neighbor Advertisement) to 352 the NAR. In case of reactive mode, the MN should include an FBU 353 within an FNA message. 355 5.4. Handover Completion 357 When an MN establishes link connectivity with the NAR, it sends an 358 FNA message to the NAR. When an NCoA in the FNA is acceptable, in 359 predictive mode, the NAR stops defending the NCoA and delivers the 360 buffered packets to the MN. In reactive mode, the MN sends the FNA 361 containing the FBU. If the NAR detects the NCoA is already in use, 362 it MUST discard the FBU and reply with Router Advertisement with 363 Neighbor Advertisement Acknowledge (NAACK) option to the MN. 364 Otherwise, the NAR forwards the inner FBU to the PAR, establishes the 365 tunnel, and finally delivers packets destined for the NCoA to the MN. 367 6. The Examples of Handover Scenario 369 In this section, the recommended handover procedure over the 802.16e 370 network is shown for both predictive mode and reactive mode. 372 6.1. Predictive Mode 374 The procedure is described briefly as follows. 376 1. A BS broadcasts a MOB_NBR-ADV periodically. 378 2. If an MN discovers a new neighbor BS in this message, it 379 may perform scanning for the BS. 381 3. When a new BS is found through the MOB_NBR-ADV and 382 scanning, the MN's link layer notifies it to the IP layer 383 (FMIPv6) by a Link_Detected primitive. 385 4. Then the MN tries to resolve the new BS's BSID to the 386 associated AR by exchange of RtSolPr and PrRtAdv messages 387 with the PAR. 389 5. The MN initiates handover by sending a MOB_MSHO-REQ message 390 to the BS and receives a MOB_BSHO-RSP from the BS. 391 Alternatively, the BS may initiate handover by sending a 392 MOB_BSHO-REQ to the MN. 394 6. When the MN receives either MOB_BSHO-RSP or MOB_BSHO-REQ 395 from the BS, its link layer triggers a 396 Link_Handover_Imminent primitive to the IP layer. 398 7. On reception of a Link_Handover_Imminent, the MN's IP layer 399 sends an FBU message to the PAR. On receiving this message, 400 the PAR establishes tunnel with the NAR by exchange of HI 401 and HAck messages. During this time, the NAR confirms NCoA 402 availability in the new link via HAck. 404 8. The MN receives an FBack message before its handover and 405 operates in predictive mode after handover. It sends a 406 MOB_HO-IND message as a final indication of handover. 407 Issue of a MOB_HO-IND may be promoted by using a 408 Handover_Commit command from the IP layer. 410 9. The MN conducts handover to the target BS and performs 411 the 802.16e network entry procedure. 413 10. As soon as the network entry procedure is completed, the 414 MN's link layer signals the IP layer with a Link_Up and 415 the MN issues an FNA to the NAR. 417 11. When the NAR receives the FNA from the MN, it delivers 418 the buffered packets to the MN. 420 (MN L3 MN L2) s-BS PAR NAR t-BS 421 | | | | | | 422 1-2. | |<---MOB_NBR-ADV --------| | | | 423 | |<-------Scanning------->| | | | 424 3. |<-LD--| | | | | 425 4. |--------------(RtSolPr)-------------->| | | 426 |<--------------PrRtAdv----------------| | | 427 | | | | | | 428 5. | |------MOB_MSHO-REQ----->| | | | 429 | |<-----MOB_BSHO-RSP------| | | | 430 | | or | | | | 431 | |<-----MOB_BSHO-REQ------| | | | 432 6. |<-LHI-| | | | | 433 7. |------------------FBU---------------->| | | 434 | | | |-----HI---->| | 435 | | | |<---HACK----| | 436 |<-----------------FBack---------------|--> | | 437 | | | forward pkt=====>| | 438 8. |(HC)->|-------MOB_HO-IND------>| | | | 439 disconnect| | | | | 440 connect | | | | | 441 9. | |<-------------802.16 network entry---------------->| 442 10. |<-LUP-| | | | | 443 |-------------------------FNA---------------------->| | 444 11. |<=============================================deliver pkt | 445 | | | | | 447 Figure 3. Predictive Fast Handover in 802.16e 449 6.2. Reactive Mode 451 The procedure is described as follows in case of reactive mode. 453 1.~ 7. The same as the case of predictive Mode. 455 8. In case the MN cannot receive an FBack message before its 456 handover, it operates in reactive mode after handover. 457 It sends a MOB_HO-IND message as a final indication of 458 handover. 460 9. The MN conducts handover to the target BS and performs 461 the 802.16e network entry procedure. 463 10. As soon as the network entry procedure is completed, the 464 MN's link layer signals the IP layer with a Link_Up and 465 the MN issues an FNA encapsulating an FBU to the NAR. 467 11. Receiving the FNA, the NAR verifies the availability of 468 NCoA and forwards the inner FBU to the PAR, establishing 469 the tunnel. If the NAR detects an NCoA is already in use, 470 it MUST discard the FBU and reply with Router Advertisement 471 with NAACK option to the MN. Otherwise, it delivers the 472 packets destined for NCoA to the MN. 474 (MN L3 MN L2) s-BS PAR NAR t-BS 475 | | | | | | 476 1-2. | |<---MOB_NBR-ADV & Scan--| | | | 477 | |<-------Scanning------->| | | | 478 3. |<-LD--| | | | | 479 4. |--------------(RtSolPr)-------------->| | | 480 |<--------------PrRtAdv----------------| | | 481 | | | | | | 482 5. | |------MOB_MSHO-REQ----->| | | | 483 | |<-----MOB_BSHO-RSP------| | | | 484 | | or | | | | 485 | |<-----MOB_BSHO-REQ------| | | | 486 6. |<-LHI-| | | | | 487 7. |--------FBU----X---> | | | | 488 8. | |-------MOB_HO-IND------>| | | | 489 disconnect| | | | | 490 connect | | | | | 491 9. | |<-------------802.16 network entry---------------->| 492 10. |<-LUP-| | | | | 493 |-------------------------FNA[FBU]----------------->| | 494 11. | | | |<---FBU-----| | 495 | | | |----FBack-->| | 496 | | | forward pkt=====>| | 497 |<=============================================deliver pkt | 498 | | | | | | 500 Figure 4. Reactive Fast Handover in 802.16e 502 7. Security Considerations 504 The security consideration of the FMIPv6 specification [RFC4068] is 505 applicable to this document. Particularly, the 802.16e architecture 506 supports a number of mandatory authentication mechanisms, for 507 example, EAP-TTLS, EAP-SIM and EAP-AKA, as well as, secure IP address 508 management between the MN and its network entity. That will allow 509 secure handover operation between the MN and the network entity. 511 8. IANA Consideration 513 This document does not require any new number assignment from IANA. 515 9. Acknowledgment 517 Many thanks IETF Mobility Working Group members of KWISF (Korea 518 Wireless Internet Standardization Forum) for their efforts on this 519 work. In addition, we would like to thank Alper E. Yegin, Jinhyeock 520 Choi, Rajeev Koodli, Soininen Jonne, Gabriel Montenegro, Singh Ajoy, 521 Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli and Ved Kafle who 522 have provided the technical advice. 524 10. Normative References 526 [I-D.irtf-mobopts-l2-abstractions] 527 Teraoka, F., "Unified L2 Abstractions for L3-Driven Fast 528 Handover", draft-irtf-mobopts-l2-abstractions-04 (work in 529 progress), August 2007. 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 535 in IPv6", RFC 3775, June 2004. 537 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 538 July 2005. 540 [RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 541 Networks", RFC 4260, November 2005. 543 [802.16e] IEEE 802.16 TGe Working Document, "Amendment 2: Physical 544 and Medium Access Control Layers for Combined Fixed and 545 Mobile Operation in Licensed Bands and Corrigendum 1", 546 IEEE Std 802.16e-2005 and IEEE Std 802.16-2004/ 547 Cor 1-2005, February 2006. 549 [802.21] IEEE 802.21 Working Group Document,"Draft IEEE Standard 550 for Local and Metropolitan Area Networks: Media 551 Independent Handover Services", IEEE P802.21/D7.1, 552 August 2007. 554 [SH-802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover 555 Mechanism for IEEE 802.16e Broadband Wireless Access", 556 International Conference on Computational Science, 557 vol. 2, pp. 527-534, 2005. 559 Authors' Addresses 561 Heejin Jang 562 Samsung Advanced Institute of Technology 563 P.O. Box 111 564 Suwon 440-600 565 Korea 567 Email: heejin.jang@samsung.com 569 Junghoon Jee 570 Electronics and Telecommunications Research Institute 571 161 Gajeong-dong, Yuseong-gu 572 Daejon 305-350 573 Korea 575 Email: jhjee@etri.re.kr 577 Youn-Hee Han 578 Korea University of Technology and Education 580 Email: yhhan@kut.ac.kr 582 Soohong Daniel Park 583 Samsung Electronics 584 416 Maetan-3dong, Yeongtong-gu 585 Suwon 442-742 586 Korea 588 Email: soohong.park@samsung.com 590 Jaesun Cha 591 Electronics and Telecommunications Research Institute 592 161 Gajeong-dong, Yuseong-gu 593 Daejon 305-350 594 Korea 596 Email: jscha@etri.re.kr 598 Full Copyright Statement 600 Copyright (C) The IETF Trust (2007). 602 This document is subject to the rights, licenses and restrictions 603 contained in BCP 78, and except as set forth therein, the authors 604 retain all their rights. 606 This document and the information contained herein are provided on an 607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 609 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 610 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 611 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 614 Intellectual Property 616 The IETF takes no position regarding the validity or scope of any 617 Intellectual Property Rights or other rights that might be claimed to 618 pertain to the implementation or use of the technology described in 619 this document or the extent to which any license under such rights 620 might or might not be available; nor does it represent that it has 621 made any independent effort to identify any such rights. Information 622 on the procedures with respect to rights in RFC documents can be 623 found in BCP 78 and BCP 79. 625 Copies of IPR disclosures made to the IETF Secretariat and any 626 assurances of licenses to be made available, or the result of an 627 attempt made to obtain a general license or permission for the use of 628 such proprietary rights by implementers or users of this 629 specification can be obtained from the IETF on-line IPR repository at 630 http://www.ietf.org/ipr. 632 The IETF invites any interested party to bring to its attention any 633 copyrights, patents or patent applications, or other proprietary 634 rights that may cover technology that may be required to implement 635 this standard. Please address the information to the IETF at 636 ietf-ipr@ietf.org. 638 Acknowledgment 640 Funding for the RFC Editor function is provided by the IETF 641 Administrative Support Activity (IASA).