INTERNET DRAFT Satish Jamadagni July 2002 Satish D Sasken Communication Technologies Ltd Mobile IP considerations for Inter-technology handovers draft-satish-mobileip-inter-technology-00.txt Status of This Memo This document is an individual submission for consideration by the Mobile IP working group. This 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 Distribution of this memo is unlimited. Abstract Multi mode terminals are becoming pervasive. In a multi mode environment, Mobile Terminals (MTs) move from the coverage of one radio access network to another. There is a need to maintain ongoing network sessions to support seamless services. For example, a MT may roam between a 3G cellular network and a wireless LAN seamlessly with session continuity. It is possible for a single service provider to support multiple modes but it is expected that different modes will be supported by different service providers. For example WLAN support can be enterprise supported where as 3G services are supported by a wide area service provider. In this draft we discuss handover support between multiple domains (modes) where a MT can use different IP addresses or can use a global IP address. Handover between different modes will then require greater federation capabilities between the different IP domains. In this draft we discuss Home Agent federation capabilities over Mobile IP so that inter-technology, inter-domain handovers are better supported. Satish et al [Page 1] Internet Draft Inter-technology handovers Jul 2002 Contents Status of This Memo Abstract 1. Introduction 2. Terminology 3. Federation of mode domains 3.1. Federation Messages 4. Tunneling support 5. Paging support within the federation 6. Fast handover support within a federation 7. Federation level QoS agreements 8. The HA considerations 9. References 10. Author's Addresses Introduction We propose a mobility solution to satisfy the problem of inter- technology handovers where the Mobile Terminal (MT) may have one or multiple IP addresses. The solution employs the concept of "a federation of Home Agents" for more efficient mobility handling for multi-mode terminals (with or without multiple IP addresses). For example, when a MT is capable of 3G and WLAN modes, the wireless LAN HA and the 3G network HA can form a federation to serve the terminal better. One or many home networks can maintain the mobile userĘs account based on the number of service providers involved in providing the number of L2 services. Each home network will be responsible for the sessions started from within the network domain (L2 domain). For example the WLAN HA will be responsible for the sessions started either by the MT or by a CN when the MT is accessing the external world through the WLAN interface. A single service provider can be responsible for the services of WLAN, 3G or any other services. In such a case a single IP address would be sufficient. When more than one service provider is involved, for example WLAN services being provided by an enterprise network and wide area services being provided by a service provider, the MT is forced to use domain specific IP address from HAs of the respective domains. Unlike in mobile IP this IP address is used not only for tunneling from home agent but also as the source address for all subsequent sessions initiated in wireless LAN. In the above case the handover will be basically from one HA to another HA. Satish et al [Page 2] Internet Draft Inter-technology handovers Jul 2002 {~~~~~~~~~~~~~~~~~~~~} ( ) ( ) { INTERNET } ( ) ( ) {~~~~~~~~~~~~~~~~~~~~} / \ / \ / \ +----------------------+ +----------------------+ | DOMAIN A | | DOMAIN B | | | | | | +-------------+ | Federation | +-------------+ | | |ACCESS N/W A | |<- - - - ->| |ACCESS N/W B | | | +-------------+ | | +-------------+ | | | | | | | | | +----------------------+ +----------------------+ ^ Declare modes | Supported | (Modes A and B)| | | | +-+ Movement +-+ Mobile | | - - - - - - - - - - - - > | | Terminal +-+ +-+ Figure 1: Supporting federation of mode domains Inter technology handovers can be facilitated if the mode domains that a MT supports can form a federation in support of handover requirements. In this draft we suggest that such a federation capability be built over L3 (IP layer). Existing Mobile IP drafts do not support federation of domains (HAs), which can greatly enhance inter-technology through fast handover support with QoS transfer considerations. The notion of a federation based on a per MT capability goes beyond just domain awareness. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" and "silently ignore" in this document are to be interpreted as described in RFC 2119. We define the following terms for use in this document. We also use Figure 1 as the basis for our handover discussion. Satish et al [Page 3] Internet Draft Inter-technology handovers Jul 2002 ICMP Internet Control Message Protocol IP Access Address An IP address useful for routing packets to a mobile node while it is attached to an access network. Target Home agent (tHA) Current Home Agent (cHA) Federation ID (FID) A temporary federation wide ID for mobility among federation HAs. 3. Federation of mode domains Inter-technology handover support requires that seamless handovers be supported between the different modes that the MT supports. Different mode domains can be supported by a single service provide or can be supported by multiple service providers. It is visualized that the case of multiple service providers supporting the different modes of a MT will be prevalent. Mobile IP does not support seamless handovers between different technologies governed by different domains. In this draft Mobile IP (RFC 3220) is extended to include "federation capabilities", where multiple domain HAs identify each other to support handovers between them. Federation here means pre-association between multiple L2 domains where the HAs form a pre-association between themselves. Federation capabilities are built over the MT registration messages. This is equally applicable to scenarios when the MT can have one or more global IP addresses. The formation of a federation among the different domains involves handshake messages between multiple Home agents of the different domains supports the following: 1. Tunneling (among different HAs of different domains) 2. Paging between the multiple HAs when more than one IP address is published to CNs 3. Fast Handover support 4. QoS (Context Transfer) support through prior QoS guarantees or associations A federation of HAs is formed once the MT declares the modes that it supports. The MT declares the modes supported over the MIP MT registration (MT to HA) message. The message formats are described in section 8. Satish et al [Page 4] Internet Draft Inter-technology handovers Jul 2002 +----------------------+ 2. Federation +----------------------+ | HA of DOMAIN A | request message | HA of DOMAIN B | | |- - - - - - - - - ->| | | +-------------+ | | +-------------+ | | |ACCESS N/W A | | | |ACCESS N/W B | | | +-------------+ | 3. Federation | +-------------+ | | | Confirm message | | | |<- - - - - - - - - -| | +----------------------+ +----------------------+ ^ | 1. MT | | 4. Registration registration | | Response (Temp FID) (Declaring | | modes) | | | v | | +-+ Movement +-+ Mobile | | - - - - - - - - - - - - > | | Terminal +-+ +-+ Figure 2: Federation message sequence The message sequence is shown in the figure above. The MT registration can be one time or periodic. It can be periodic to facilitate any addition in mode support at the MT. In this case a new federation is formed with the addition or deletion of any mode support. This could happen as the user could buy new services or terminate access services of a particular mode. 3.1 Federation Messages The new messages introduced are the federation request, federation Confirm and the MT registration message. These messages are modified ICMP messages. Federation messages basically achieve pre authorization and authentication. A temporary federation authorization-authentication ID (FID) is used. Once a MT identifies itself with one of the HAs over a mode, that HA will contact all the other HAs listed in that message. Once all the HAs have been contacted, a global (Federation wide) authorization and authentication ID is provided to the MT. The MT uses this ID in all subsequent registrations. This ID has an associated validity time after which the MT has to renew the registration. The message format is shown below and can be used in conjunction with other mobile IP messages. The federation values include flags to indicate need for federation level QoS establishment, paging support as elaborated in the following sections. Satish et al [Page 5] Internet Draft Inter-technology handovers Jul 2002 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Federation values.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Federation message extension 4. Tunneling support Tunneling from one domain to another is essential for any viable inter- technology handover support. Sessions created in one domain will have to be supported by that domain. If a handover occurs during a running session, that HA will have the responsibility of tunneling packets to the other HA to which the MT has handed off. +----------------------+ +----------------------+ | HA of DOMAIN A | | HA of DOMAIN B | | |< - - - - - - - - ->| | | +-------------+ | Tuneling between | +-------------+ | | |ACCESS N/W A | | federation HAs | |ACCESS N/W B | | | +-------------+ | | +-------------+ | | | | | | | | | +----------------------+ +----------------------+ ^ | | | | | +-+ Movement +-+ Mobile | | <- - - - - - - - - - - > | | Terminal +-+ +-+ 5. Paging support within the federation The need for paging within the federation arises when multi-mode terminals can possess and publish multiple IP addresses. When correspondent nodes (CNs) attempt to contact the MT over any of the MTs published IP address, the HA contacted is expected to page the federation to find the domain where the MT is presently in. The contacted HA can then decide to tunnel the packets intended for the MT or can notify the CN of the present MTs IP address. Satish et al [Page 6] Internet Draft Inter-technology handovers Jul 2002 6. Fast handover support within a federation Fast handover support is realized through the removal of the need for registration confirmation when the MT registers with the federation ID (FID). FID uniquely identifies the MT. +----------------------+ +----------------------+ | HA of DOMAIN A | | HA of DOMAIN B | | |< - - - - - - - - ->| | | +-------------+ | | +-------------+ | | |ACCESS N/W A | | Federation | |ACCESS N/W B | | | +-------------+ | | +-------------+ | | | | | | | | | +----------------------+ +----------------------+ ^ | MT registration | with FID | | | | +-+ Movement +-+ Mobile | | - - - - - - - - - - - > | | Terminal +-+ +-+ 7. Federation level QoS agreements With the identification of a federation, a federation level base QoS can be agreed upon by the HAs. This reduces the need for a handoff time QoS or context transfer providing for fast handovers. QoS agreements can be pre-arrived at between the different HAs through negotiations. 8. The HA considerations The HAs should support association tables for each MT. The tables will have to maintain the association profiles as well as the base QoS profiles negotiated within the federation for that MT. There will be additional overheads in terms of memory. Satish et al [Page 7] Internet Draft Inter-technology handovers Jul 2002 9. References [1] C Perkins, IP Mobility Support for IPv4, RFC 3220. [2] 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. [3] D. Johnson, C. Perkins and Jari Arkko, Mobility Support in IPv6, work in progress, draft-ietf-mobileip-ipv6-17.txt, May 2002. [4] Karim El Malki et al, Low Latency Handoffs in Mobile IPv4, work in progress, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, Nov 2001. [5] X. Zhang et al, P-MIP: Minimal Paging Extensions for Mobile IP, draft-zhang-pmip-00.txt, July 2000. [6] P. Calhoun, C. Perkins, Mobile IP Network Access Identifier Extension for IPv4, RFC 2794. 10. Author's Addresses Satish Jamadagni, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 5355501 Ext:3029 Fax: +91 80 5351133 Email: satishj@sasken.com Satish D, Sasken Communication Technologies Ltd, #139/25, Amar Jyoti Layout, Ring Road, Domlur P.O, Bangalore 560071, India Phone:+91 80 5355501 Ext:3164 Fax: +91 80 5351133 Email: satishd@sasken.com Satish et al [Page 8]