Network Working Group S. Daniel Park Internet-Draft Syam Madanapalli June 23, 2003 SAMSUNG Electronics Expires: December 22, 2003 Andrea Calvagna University of Catania 802.11 Mobility Framework Supporting GPRS Handover < draft-park-mobileip-wifi-handover-00.txt > Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved, Abstract In this draft, we describe a new mobility framework to extend 802.11 [WLAN] to seamlessly manage roaming into GPRS access network, whenever the mobile node is out of range from any 802.11 domain. Park, et. al. Expires December 22, 2003 [Page 1] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 3 2. Framework Description . . . . . . . . . . . . . . . . . . . 4 2.1. Framework Requirements . . . . . . . . . . . . . . . . 5 2.2. The Mobile Node . . . . . . . . . . . . . . . . . . . . 5 2.3. Gateway Functionalities . . . . . . . . . . . . . . . . 5 2.4. Roaming into GPRS domain . . . . . . . . . . . . . . . 6 2.5. Roaming into foreign 802.11 domain . . . . . . . . . . 6 3. GPRS/802.11 handover behavior . . . . . . . . . . . . . . . 6 3.1. 802.11 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. 802.11 to GPRS . . . . . . . . . . . . . . . . . . . . 7 3.3. GPRS . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. GPRS to 802.11 . . . . . . . . . . . . . . . . . . . . 7 3.5. handover Considerations . . . . . . . . . . . . . . . . 8 4. Comparison with IPv6 . . . . . . . . . . . . . . . . . . . . 8 5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Consideration . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 Park, et. al. Expires December 22, 2003 [Page 2] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 1. Introduction In order to provide IP mobility for wireless users several micro- mobility [Probstmt] protocols are currently available. These are capable of supporting this feature inside the scope of a LAN, by means of performing handovers between adjacent 802.11 radio-access cells in order to follow users' movements. Also, it is possible to achieve wireless mobility in a larger extent, i.e. across whole network domains. But, in order to do it these protocols have to be used in conjunction with a macro-mobility [Probstmt] protocol, like Mobile IP (both IPv4 and IPv6). In this context, a problem arises if such domains are so far away from each other that wireless-access gaps exist between them. In fact, this prevents wireless IP users from experiencing access continuity while traveling across these domains. In this draft, we describe a new mobility framework that extends it to seamlessly manage roaming into GPRS access network, whenever the mobile node is out of range from any 802.11 domain. At present, GPRS access is available almost everywhere, thus it can be used to fill the wireless access gap between disjunct 802.11 domains Indeed, in the considered scenario macro-mobility features MUST also be involved to enable roaming of MNs into the foreign 802.11 domains they traverse. 1.1 Terminology 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 RFC 2119 [2119]. Park, et. al. Expires December 22, 2003 [Page 3] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 2. Framework Description -------- / \ | Internet | \ / -------- | | | +------+--------+ # # # # # # # # # # # # # +---------------+ | Access Router | Tunnel | Access Router | +------+--------+ # # # # # # # # # # # # +-------+-------+ | # # | | # # | | # # Tunnel (GPRS) | | # # | +----+ | +----+ # # +-+--+ | AP |....+....| AP | # # | AP | +----+ +----+ * # # * +----+ . * # # * . . * # # * . . (A) * # # (B) * . (C) +----+ * +----+ * +----+ | MN |==============> * ====> | MN | =======> * | MN | +----+ movement * +----+ * +----+ * * AP coverage * * AP coverage * * * * * * * * * * * * * * * * * * Figure 1 : Considering framework scenario MN moves out from its home link (A) toward a distant foreign link (C) ,preserving connections to the Internet through GPRS meanwhile(B) Park, et. al. Expires December 22, 2003 [Page 4] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 2.1 Framework Requirements 2.2 The Mobile Node When the user brings its MN (IPv4 or IPv6 enabled) outside the radio boundaries of its home 802.11 domain the device will automatically detect a loss of signal and, as a consequence, will divert all IP connections to the GPRS access interface, In general, the connections are carried through the GPRS access network when 802.11 access is not available, but are seamlessly carried back to the 802.11 interface as soon as 802.11 access point signal is available. 2.3 Gateway Functionalities This section considers Gateway (or Access Router) functionalities as follows ; Registration Management A visiting MN MUST initiate a Registration procedure in order to obtain access in this domain. This is done by sending an appropriate request to Gateway, which will ask some information to the Gateway of the home network of MN. Therefore the generic Gateway, takes part in two types of Registration procedures : (1) The Registrations of the visiting MNs that want to obtain wirelsss access in 802.11 domain. (2) The Registrations of the MNs belonging to 802.11 domain that want to obtain wireless access in foreign domains. IP Tunnel Management 802.11 Bridge (temporary terminology) is based on IP tunneling. At least one of the end-point of any IP tunnel is always a Gateway. Packet Classification The Gateway MUST distinguish the packets : (1) coming from an IP tunnel, destined to a certain MN. (2) destined to a MN belonging to home domain which is currently visiting a foreign domain or is only reachable through GPRS. (3) generated by MNs visiting domain. Packet Forwarding The Gateway MUST forward the packets destined to MNs belonging to foreign domain which are currently outside original 802.11 domain and the packets generated by MNs visiting 802.11 domain towards the appropriate IP tunnel. Park, et. al. Expires December 22, 2003 [Page 5] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 2.4 Roaming into GPRS domain The MN receives a dynamic IP address (generally called Care-of Address) valid in the GPRS domain. This is done within the Registration procedure executed when the MN is turned on. This dynamic IP address is provided to the Gateway (Home Agent) which maintains updated an appropriate cache, containing information about the mapping between the static (Home Address) and dynamic IP (Care-of Address) addresses of the MN. A MN is outside any 802.11 domain when there are not 802.11 base stations in the proximity. This can be easily recognized because, according to Mobile IP, 802.11 base stations transmit a beacon signal. Therefore, the fact that the MN cannot listen any beacon signal (or the level of the signal is too low) is the evidence that the MN is outside any 802.11. In comparison with IPv4, IPv6 enabled MN can make its Care-of address by Auto Configuration mechanism [2462]. Of course there are some extra processing to make a care-of address, but many kinds of mechanisms can support the fast address auto configuration to provide fast handover. [MoveDetect] (this sentence will be considered in the next version) 2.5 Roaming into foreign 802.11 domain When the MN is visiting a foreign 802.11 domain, another IP tunnel is established between the home and foreign Gateway of the two involved networks. This tunnel set-up is triggered by the first MN (re-) entering in the considered foreign 802.11 domain. Obviously, before such a tunnel is set-up the registration of the MN in the foreign 802.11 domain occurs, involving an authentication procedure which is based on MN's MAC address validation (by querying the Home Agent). In comparison with IPv4, IPv6 enabled MN do not need IP tunnel (is generally called reverse tunnel in the mobile IPv4) between the home and foreign agent by Route Optimization. Moreover, the new Mobile IPv6 mechanism can provide secure path between Home Agent and MN. (this sentence will be considered in the next version) 3. GPRS/802.11 handover behavior In this section, we explain the system behavior when a MN performs a handover from its home 802.11 domain to GPRS, and back on. There are four main connection phases the MN experiences, which we are going to highlight in the following; Park, et. al. Expires December 22, 2003 [Page 6] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 3.1 802.11 In this phase the MN is located inside its own home 802.11 domain, and its mobile connectivity is managed by the domain's Gateway normally, as in Mobile IP. MN sends and receives packets through the 802.11 interface and, moreover, periodically sends paging-update messages toward the local Gateway to let it constantly track its current location inside the domain. 3.2 802.11 to GPRS Here the mobile host steps outside of its home 802.11 domain radio range. No other 802.11 domain is present to offer connectivity, so it sets as default route for outgoing packets the GPRS tunnel interface to its Home Agent, actually performing a hard handover from 802.11 to GPRS access network. The MN sends as first message on the GPRS tunnel a gprs-solicit message, followed by its up-link IP date traffic. In response to the solicit message, the Home Agent sets also its endpoint of the GPRS tunnel as default forwarding interface for MN's down-link packets. 3.3 GPRS In this phase the IP tunnel interface, linking the MN and its home agent through GPRS network, is used by the MN as forwarding interface, so packets may flow normally to their destination. During this phase the state of the 802.11 Mobility Management thread on the MN is freezed, including its internal paging-update timer, to be waken later when stepping back inside the 802.11 domain. 3.4 GPRS to 802.11 This phase of the cycle represents the MN stepping back inside its home 802.11 domain. Start of this phase is triggered in the MN by the reception of the first beacon advertisement message , coming from the nearest in-range base station (or access point) of the 802.11 domain. This message provokes the awakening of the MM thread inside MN, that resumes its execution and consequently sets the advertising base station' IP address as default route from its uplink packet. After this, the MN still keeps on receiving UDP packets from the GPRS tunnel. In fact, it still has to wait for the expiration of last resumed paging-update timer before it can expressly signal its presence to the 802.11 home agent, sending a paging-update message. As soon as the home agent receives the paging-update message it sets -up default route toward the MN back to the 802.11 domain route. Due to the fact that a soft handover is actually performed, the MN receives IP packets from both access interfaces, 802.11 and GPRS, for the brief period of time intervening between the awakening of the 802.11 mobility management thread in the MN and the actual update in the gateway of the routing path to MN. Park, et. al. Expires December 22, 2003 [Page 7] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 3.5 handover Considerations Generally, we can show that a service degradation occurs in terms of lost packets when the MN moves from 802.11 access domain to GPRS access domain. This is basically due to the bandwidth mismatch between the two environments and the hard type of handover performance, and could be improved by reducing duration of beacon interval timer or Fast movement detection mechanism [MoveDetect]. 4. Comparison with IPv6 One big advantage we get with IPv6 is its inherent mobility support, which is a fundamental feature in a wireless access environment. In fact, user's expectations are for seamless support of wireless mobility, even across etherogeneous access networks. IPv4 do support mobility, but at the extra cost of tunneling and signaling between software agents running in the routers. Also, the signaling cost increase proportionally with the number of mobile users and their "speed", thus, a performance limit may be easily reached. If so, users start experiencing long delays and/or temporary disconnections, that is, poor performance of the seamless mobile environment, which is actually due to poor performance of the "wired" only part of the environment! The main mistake is that IPv4 "addresses" are logical IDs which are used to represent at the same time the "destination host" and "its topological position" on the whole network. This simplifies routing, but only in a fixed network environment. It becomes a big limit in a mobile one... IPv6 overcomes this problem. (this section also should be discussed more detail.) 5. Future Work Fast movement detection when mobile node is attached to the GPRS and vice versa. (supporting fast handover to solve a limitation of section 3.5) Comparison between MIPv4 and MIPv6. Mobile node authentication. Consideration of Gateway functionality. 802.11 mobility management. (to manage the task of relating IP to the most appropriate access solution which is chosen analyzing the information gathered by the protocol.) Park, et. al. Expires December 22, 2003 [Page 8] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 6. Security Consideration TBD 7. Acknowledgements A major portion of the text in this draft was stolen from A.Calvagna, G.Morabito, A.Pappalardo' document [WiFi&GPRS]. Thanks to Pyungsoo Kim for his careful revisions on this draft. 8. Author's Address Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics Email:soohong.park@samsung.com Syam Madanapalli Network Systems Division, SAMSUNG India Software Operations, INDIA Email:syam@samsung.com Andrea Calvagna University of Catania Email:andrea.calvagna@unict.it 9. References [WiFi&GPRS] A. Calvagna, G. Morabito, A. Pappalardo, "WiFi mobility framework supporting GPRS roaming : Design and Implementation, November, 2002. [CellularIP] A. Campbell, et. al., "Cellular IP", Internet Draft, October, 1999. [Probstmt] C, Williams, et. al., "Micromobility Problem Statement" Internet Draft, December 2002. [2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [MoveDetect] G. Delay, J. Choi, "Movement Detection Optimization in Mobile IPv6", Internet Draft, May 2003. Park, et. al. Expires December 22, 2003 [Page 9] 802.11 Mobility Framework Supporting GPRS handover June 23, 2003 [WLAN] "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition. [2462] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration" RFC 2462 December 1998. 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Park, et. al. Expires December 22, 2003 [Page 10]