Network Working Group J. Jee Internet-Draft ETRI Expires: March 16, 2006 S. Park Samsung Electronics J. Cha ETRI H. Jang Samsung AIT September 12, 2005 Mobile IPv4 Fast Handovers for 802.16e networks draft-jee-mip4-fh80216e-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes how a Mobile IPv4 Fast Handover can operate Jee, et al. Expires March 16, 2006 [Page 1] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 on link layers confirming to the IEEE 802.16e suite of specification. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Deployment Architectures for Mobile IPv4 on 802.16e . . . . . 4 5. 802.16e Handovers in Detail . . . . . . . . . . . . . . . . . 5 6. FMIPv4 Message Exchanges . . . . . . . . . . . . . . . . . . . 7 7. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Scenario 12ab34cdef5678g . . . . . . . . . . . . . . . . . 8 7.2. Scenario 12ab345678cdef . . . . . . . . . . . . . . . . . 9 7.3. Scenario 12ab345678deg . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Jee, et al. Expires March 16, 2006 [Page 2] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 1. Introduction Mobile IPv4 protocol [RFC3344] is currently available in order to provide sessions continuity for mobile nodes. Though this Mobile IPv4 is capable of handling IPv4 handovers between different subnets, in a transparent way for higher-level connections, it is not adequate in supporting real time application that requires low latency and packet loss. Fast Handovers for Mobile IPv4 [I-D.koodli-fmipv4] provides a mechanism to reduce latency and packet loss resulting from Mobile IPv4 handover operations to solve the performance problem of Mobile IPv4 in wireless mobile environments. Fast Handovers for Mobile IPv4 addresses movement detection, IP address configuration and location update latencies to meet the real time application requirements. This document gives a set of deployment examples for Mobile IPv4 Fast Handovers on 802.16e networks. As modeled on the [I-D.jang-mipshop- fh80216e], we begin with a brief overview of relevant aspects of basic 802.16e. We examine how and when 802.16e's handover related information might become available to the IP layers that implement Fast Handover, both in the network infrastructure and on the mobile node. Finally, we trace the protocol steps for Mobile IPv4 Fast Handover in this environment. 802.16e standard [IEEE802.16e] is only used in this document as a reference model since 802.16 standard is for fixed broadband wireless access systems, but no restriction is made by this document. 2. Terminology This document borrows all of the terminology from [RFC3344] and [I-D.koodli-fmipv4], with the following additional terms from the 802.16e specification: MOB_NBR-ADV : IEEE 802.16e neighbor advertisement message sent periodically by a BS(Base Station). MOB_MSHO-REQ : IEEE 802.16e handover initiation request message sent by a MS(Mobile Station). MOB_BSHO-RSP : IEEE 802.16e handover initiation response message sent by a BS. MOB_BSHO-REQ : IEEE 802.16e handover initiation request message sent by a BS. MOB_HO-IND : IEEE 802.16e handover indication message sent by a MS. Jee, et al. Expires March 16, 2006 [Page 3] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 BSID : IEEE 802.16e BS identifier. 3. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 4. Deployment Architectures for Mobile IPv4 on 802.16e The relationship between BSs(Base Stations), ARs(Access Routers) and IP subnets is almost the same as the case of Mobile IPv6 which is described in [I-D.jang-mipshop-fh80216e] except the existence of FA(Foreign Agent) which may be co-located with AR. We only provide figures for convenience. /-------------------------------------\ | IP Backbone | \-------------------------------------/ | | /-----------\ /-----------\ | AR1 | | AR2 | \-----------/ \-----------/ / / | \ \ / / | \ \ / / | \ \ / / | \ \ / | | | \ / | | | \ BS1 BS2 BS3 BS4 BS5 BS6 BS7 BS8 BS9 BS10 Figure 1: 802.16e deployment architecture in a centralized manner Jee, et al. Expires March 16, 2006 [Page 4] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 /------------------------------------------------\ | IP Backbone | \------------------------------------------------/ | | | | | | AR1 AR2 AR3 AR4 AR5 AR6 \ | / \ | / \ | / \ | / BS1 --(Subnet 1)--- BS5 BS6 --(Subnet 2)--- BS10 / | \ / | \ / | \ / | \ BS2 BS3 BS4 BS7 BS8 BS9 Figure 2: 802.16e deployment architecture in a distributed manner /------------------\ | IP Backbone | \------------------/ / | \ / | \ / | \ ----- ----- ----- | AR1 | | AR2 | | AR3 | | BS1 | | BS2 | | BS3 | ----- ----- ----- Figure 3: 802.16e deployment architecture with integrated BS and AR 5. 802.16e Handovers in Detail The 802.16e provides three handover modes, hard handover, fast BS switching and soft handover in IEEE 802.16e []. In this version of the draft, we first consider the hard handover mode because this is the default mode in 802.16e. An 802.16e handover provides the MS initiated handover and network initiated handover according to which entity initiates the L2 handover in this network. Even though the MS or network entity can initiate the L2 handover, the MS ultimately decides its target BS with its own criteria. When MS does not want to choose one of BSs which are suggested by the serving BS, MS can re-initiate L2 handover Jee, et al. Expires March 16, 2006 [Page 5] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 from its side. The L2 handover process in 802.16e networks consist of the following steps: 1. MS acquires network topology information and channel information for neighbor BSs by receiving MOB_NBR-ADV message which is periodically broadcasted by the serving BS. 2. MS may perform scanning/association with the neighbor BSs, and sends radio measurement reports to the serving BS. 3. 3. MS initiates handoff preparation by sending MOB_MSHO-REQ message to the serving BS and the BS replies with MOB_BSHO-RSP message containing the recommended target BSs. In case the serving BS sends MOB_BSHO-REQ to initiate handoff preparation, the recommended target BSs are included in MOB_BSHO-REQ message. 4. MS decides the target BS from the suggested BSs in MOB_BSHO-RSP or MOB_BSHO-REQ by performing the BS decision algorithm. 5. MS sends MOB_HO-IND to the serving BS to commit a L2 handover. 6. MS shall synchronize to downlink transmissions of target BS, and obtain DL and UL transmission parameters only if it did not receive MOB-NBR-ADV message from the serving BS. 7. MS shall conduct network re-entry procedure with the target BS. Network re-entry procedure is the same as the initial network entry except that it may be shortened by the possession of the MS information obtained from the serving BS over the backbone network. 8. MS completes the L2 handover by receiving the REG-RSP from the target BS. When a MS sends a MOB_HO-IND to the serving BS, any packet data transfer between the MN and the serving BS is not possible even though the resource retain timer does not expire in the serving BS. Therefore, MS SHOULD send a FBU message to the serving BS before sending the MOB_HO-IND to the serving BS to operate as the predictive mode. One possible way to operate as the predictive mode is to use the association information during the scanning procedure, which optionally supports the association procedure with neighbor BSs. This can increase the probability for the FMIPv6 predictive mode can happen. However, performing the association during the scanning interval is an optional feature. Jee, et al. Expires March 16, 2006 [Page 6] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 6. FMIPv4 Message Exchanges An FMIPv4 handover normally consists of the following messages: a. MN sends an RtSolPr (Router Solicitation for Proxy) to find out about neighboring ARs. b. MN receives a PrRtAdv (Proxy Router Advertisement) containing one or more [BS-ID, AR-Info] tuples. c. MN sends a FBU (Fast Binding Update) to PAR (Previous Access Router). d. PAR sends a HI (Handover Initiate) to NAR (New Access Router). e. NAR sends a HAck (Handover Acknowledge) to PAR. The HAck contains an NCoA that NAR assigns. f. PAR sends an FBAck (Fast Binding Acknowledgment) to MN. g. MN (re)sends FBU to NAR after attaching to it. In case of reactive handover, MN connects to NAR prior to sending FBU to PAR in the previous link. After step g, NAR forwards FBU to PAR then steps d, e and f would take place from there. 7. Scenarios In this section, we look at a few of the possible scenarios for using FMIPv4 in an 802.16e context. We label each scenario by the sequence of events that take place, where the numbered events are from Section 5 and the lettered events are from Section 6. We describe a brief description and discussion of the benefits and drawbacks for each scenario. Jee, et al. Expires March 16, 2006 [Page 7] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 7.1. Scenario 12ab34cdef5678g -------------- -------------- MN L3 MN L2 |serving BS PAR| |NAR target BS| -------------- -------------- | | | | | | | |<-----MOB_NBR-ADV-------| | | | | |( Scanning )| | | | |--------------(RtSolPr)-------------->| | | |<--------------PrRtAdv----------------| | | | | | | | | | | [MN initiation] | | | | | |------MOB_MSHO-REQ----->| | | | | |<-----MOB_BSHO-RSP------| | | | | | or | | | | | | [BS initiation] | | | | | |<-----MOB_BSHO-REQ------| | | | | | | | | | |------------------FBU---------------->| | | | | | |-----HI---->| | | | | |<---HAck----| | |<-----------------FBAck---------------|--> | | | |-------MOB_HO-IND------>| forward========>| | disconnect | packets | | | connect | | | | | |<--------------802.16 network reentry------------->| connect | | | | |-------------------------FBU---------------------->| | |<===============================================deliver | | | | | packets | Figure 4: Predictive mode in 802.16e This scenario is the predictive mode of operation from the FMIPv4 specification. In this scenario, MN's actual L2 handover commitment of sending MOB_HO-IND SHOULD happen only after sending FBU to PAR as shown in Figure 4: Predictive mode in 802.16e. This mode of operation requires that the decision of a target BS and handover commit operations (steps 4 and 5) happen separately and under MN control, so that step c can intervene between steps 4 and 5. Steps d, e, and f may operate simultaneously or lately with steps 6, 7, and 8. The most important point to operate as the predictive mode is to send FBU prior to sending MOB_HO-IND to the serving BS because MS's sending MOB_HO-IND to the serving BS results in disabling Jee, et al. Expires March 16, 2006 [Page 8] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 transferring any L3 packet between the MN and PAR. Steps a and b may happen after steps 3 to acquire fresh triplet information of NARs. In this case, MN expects to get only the NARs information that is related with the candidate target BSs. Step a may be omitted in case where PAR has a capability of actively sending PrRtAdv with the NARs information related with the suggested BSs list in MOB_BSHO-RSP or MOB_BSHO-REQ. This case requires the serving BS to notify the suggested BSs information to the PAR. 7.2. Scenario 12ab345678cdef -------------- -------------- MN L3 MN L2 |serving BS PAR| |NAR target BS| -------------- -------------- | | | | | | | |<-----MOB_NBR-ADV-------| | | | | |( Scanning )| | | | |--------------(RtSolPr)-------------->| | | |<--------------PrRtAdv----------------| | | | | | | | | | | [MN initiation] | | | | | |------MOB_MSHO-REQ----->| | | | | |<-----MOB_BSHO-RSP------| | | | | | or | | | | | | [BS initiation] | | | | | |<-----MOB_BSHO-REQ------| | | | | | | | | | | |-------MOB_HO-IND------>| | | | disconnect | | | | | connect | | | | | |<--------------802.16 network reentry------------->| connect | | | | |-------------------------FBU---------------------->| | | | | |<---FBU-----| | | | | |----FBAck-->| | | | | forward | | | | | packets=========>| | |<================================================deliver | | | | | packets | Figure 5: Reactive mode in 802.16e This scenario is the reactive mode from the FMIPv4 specification. Jee, et al. Expires March 16, 2006 [Page 9] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 This scenario does not require MN's intervention between steps 4 and 5 as shown in Figure 5: Reactive mode in 802.16e. Minimum requirement is to get an NAR's L2 information through steps a and b from the serving BS. Therefore, steps a and b SHOULD happen before the step 5. 7.3. Scenario 12ab345678deg -------------- -------------- MN L3 MN L2 |serving BS PAR| |NAR target BS| -------------- -------------- | | | | | | | |<-----MOB_NBR-ADV-------| | | | | |( Scanning )| | | | |--------------(RtSolPr)-------------->| | | |<--------------PrRtAdv----------------| | | | | | | | | | | [MN initiation] | | | | | |------MOB_MSHO-REQ----->| | | | | |<-----MOB_BSHO-RSP------| | | | | | or | | | | | | [BS initiation] | | | | | |<-----MOB_BSHO-REQ------| | | | | | | | | | | |-------MOB_HO-IND------>| | | | disconnect | |-----HI---->| | | | | |<---HAck----| | | | | | | | | | | forward========>| | | | | packets | | | connect | | | | | |<--------------802.16 network reentry------------->| connect | | | | |-------------------------FBU---------------------->| | | | | | | | |<================================================deliver | | | | | packets | Figure 6: Optimized Reactive mode in 802.16e This scenario is an optimized mechanism of the FMIPv4's reactive mode. The tunnel set-up between PAR and NAR is actively initiated at PAR without FBU from MN only using HI and HAck as shown in Figure 6: Optimized Reactive mode in 802.16e. Jee, et al. Expires March 16, 2006 [Page 10] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 When serving BS receives the MOB_HO_IND which contains the target BS information, it requests PAR to send HI message to NAR which serves the target BS. Basically, PAR is assumed to have the co-relation information between the target BS and NAR. This optimized mode has a benefit of reducing the packet forwarding delay from PAR to MN in the reactive mode. When MN sends FBU to NAR after attaching to the new access network, NAR just delivers the buffered packet to MN. Steps a and b may not require but helps MN to recognize the neighboring NARs' information in advance of handover. 8. Security Considerations The security consideration of the Fast Handovers for Mobile IPv4 specification [I-D.koodli-fmipv4] are also applicable to this document. Particularly, 802.16e architecture supports a number of mandatory authorization mechanisms, for example, EAP-TTLS, EAP-SIM and EAP-AKA, as well as, protects IP address management between the MN and its network entity. That will allow secure handover operation between the MN and network entity. We will describe security issues in more detail in the updated version of this document. 9. Acknowledgment Authors would like to express special thanks to IETF Mobility Working Group members of KWISF (Korea Wireless Internet Standardization Forum) for their efforts on this work. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-mipshop-80211fh] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", draft-ietf-mipshop-80211fh-04 (work in progress), April 2005. [I-D.jang-mipshop-fh80216e] Jee, et al. Expires March 16, 2006 [Page 11] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks", draft-jang-mipshop-fh80216e-00 (work in progress), July 2005. [I-D.koodli-fmipv4] Koodli, R. and C. Perkins, "Adapting Mobile IPv6 Fast Handovers for IPv4", draft-koodli-fmipv4-00 (work in progress), October 2004. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [IEEE802.16e] Draft IEEE Standard for Local and metropolitan area networks, "Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands", IEEE P802.16e/D10, Aug 2005 Jee, et al. Expires March 16, 2006 [Page 12] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 Authors' Addresses Junghoon Jee ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-5126 Email: jhjee@etri.re.kr Soohong Daniel Park Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon, 442-742 KOREA Phone: +82-31-200-4508 Email: soohong.park@samsung.com Jaesun Cha ETRI 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA Phone: +82-42-860-5587 Email: jscha@etri.re.kr Heejin Jang Samsung AIT P.O. Box 111 Suwon, 440-600 KOREA Email: heejin.jang@samsung.com Jee, et al. Expires March 16, 2006 [Page 13] Internet-Draft FMIPv4 for IEEE 802.16e networks September 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jee, et al. Expires March 16, 2006 [Page 14]