Mobile IP Working Group Claude Castelluccia INTERNET-DRAFT Lubovic Bellier INRIA, FRANCE 25 June 1999 Toward a Unified Hierarchical Mobility Management Framework draft-castelluccia-uhmm-framework-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. Abstract As the number of mobile hosts increases in the Internet, it becomes clear that a hierarchical mobility management protocol is necessary. The macro-mobility is the mobility between domains. The micro- mobility is the mobility within one domain. Several proposals that separate macro and micro mobility as been proposed recently (CellularIP[4], HAWAI[3], HMIP[1],...). All these proposals agree that Mobile IP is suitable to handle macro-mobility (inter-domain mobility) but they all propose a different micro-mobility scheme. As a result, a mobile host won't be able to roam seamlessly if it does not understand the different Castelluccia Bellier Expires 26 December 1999 [Page 1] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 micro-mobility management protocols of the site that it visits. In this document, we present a framework that allows the deployement of diverses micro mobility management protocols in different parts of the Internet while still providing connectivity to mobile hosts. We propose to decompose the Internet mobility management protocol into three components. The first one, the access protocol, specifies the registration procedures between the Mobile and the Proxy/Base Station it is attached to. It is standard and unique. The second one, the micro-mobility protocol, manages local mobility and varies from one domain to another. The third one, the macro-mobility protocol, manages mobility across domains. We suggest to use Mobile IP as the macro-mobility protocol. 1- Introduction There have been several hierarchical and cellular Mobile IP proposals recently. This shows a huge interest for a scalable mobility management scheme. There are at least 3 proposals that we know of : - Ericsson/Columbia Cellular IP [4] (http://comet.ctr.columbia.edu/cellularip/) - Lucent HAWAII [3] (http://www.bell- labs.com/user/ramjee/papers/draft-ramjee-micro-mobility-hawaii- 00.txt) - INRIA HMIPv6 [1] (http://sirac.inrialpes.fr/Infos/Personnes/Claude.Castelluccia/hmip.ps.gz) All these proposals agree that Mobile IP is suitable to handle macro-mobility (inter-domain mobility), but they all propose a different micro-mobility scheme. From then, 2 directions are possible : 1- A single micro-mobility protocol is defined and standardized from the existing and forthcoming proposals. 2- A framework that allows each proposal to be deployed and that provides inter-operability is defined. We argue that the second solution is preferable for the following reasons. First we believe that there is probably not an "optimal" micro-mobility scheme for every networks. Different protocols might be necessary for different networks' needs. Second, defining an open system leads to more competition and flexibility. Each network operator is then free to deploy its own micro-mobility protocol (and to patent it:-)). New protocols can be deployed very easily. Last but not least it eases drastically the standardization process ; the Castelluccia Bellier Expires 26 December 1999 [Page 2] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 different proposals do not have to be merged into a single one. In this document, we propose a framework that allows the deployment of different micro-mobility proposals. We assume that Mobile IP is used as the macro-mobility protocol (inter-domain protocol). Our final goal is to define a framework that allows a Mobile to roam seamlessly from one network to another, from one domain to another... One condition to achieve this goal is to make sure that the mobility management procedures performed by the Mobile Hosts are independent of the mobility management protocols used in the core of the network. 2- General principles In this document, we define a site as an arbitrary structure. A site can be an ISP network, a campus network, a company network, a set of LANs or even a single LAN. A site is connected to the rest of the Internet via one or several interconnection routers that we call Border Routers in this document. Our proposal differentiates the macro (inter-site) mobility from the micro (intra-site) mobility. As a result, a host communicating with a Mobile is only aware of its inter-site mobility. The Mobile's intra- site mobility is completely hidden. It also defines a standard Mobile registration protocol that is independent of the mobility management protocols used in the core network. As a result, different mobility management protocols can be used in the different parts of the Internet while still providing connectivity to the Mobile Hosts. We propose a mobility management framework which uses Mobile IP for the inter-site mobility but allows the deployement of any micro- mobility protocols. As a matter of fact, different sites can deploy different micro-mobility protocols. 2.1 Design Goals/Constraints The goals of our work is to propose a hierarchical mobility management that : 1- does not require any modifications at the Correspondents (Correspondents are running Mobile IP). 2- allows the deployment of different micro-mobility schemes transparently to the Correspondents and the Mobile Hosts. 3- does not degrade routing performance. 4- is as secure as Mobile IP. 6- works in IPv4 and IPv6. 7- is power-efficient (i.e. minimizes the power). Castelluccia Bellier Expires 26 December 1999 [Page 3] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 2.2 Conceptual Model In the proposed framework, the mobility management protocol is composed of three components as illustrated in Figure 1. - The first one, the access mobility management protocol, specifies the registration procedures between the Mobile and the site it is attached to. It is standard and independent of the micro and macro mobility management protocols used in the core of the network. This protocol is ``light'', i.e. minimises the operations performed by the Mobile Hosts (which probably have limited capacity and power). - The second one, the micro mobility management protocol, is the protocol that handles the local mobility (within the domain) of the Mobile. - The third one, the macro-mobility management protocol, is the protocol that handle the macro-mobility (inter-domain) of the Mobile. We propose to use Mobile IP as macro-mobility management protocol. 3- Proposed Framework 3.1 Overview Our proposal is based on the deployment of Mobility Supports. A Mobility Support is a router or a set of routers that maintains a binding per mobile hosts currently visiting the site. The Mobility Support plays a central role in our proposal. It is involved in the macro and micro mobility management. For example, the Mobility Support sends Binding Updates on behalf of the Mobile Hosts it is serving (macro-mobility management). It also intercepts packets addressed to the Mobile Hosts it is serving and is in charge of redirecting them to their current location (micro-mobility management). Note that there is no constraint on the physical location of the Mobility Support. However for efficiency reasons, it is preferable to connect it as close as possible to the border router of the network that it is serving. In our proposal, the Mobile registration protocol is unique and independent of the micro-mobility management protocol of the site. The nature and the position of the Mobility Support depends on the micro-mobility management protocol. The only requirements that we impose on the Mobility Support are : Castelluccia Bellier Expires 26 December 1999 [Page 4] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 (1) they should process registration messages coming from the mobile hosts (the processing depends of the micro-mobility protocols), (2) they should send Mobile IP Binding Updates to the Mobile's Home Agent and Correspondents (according to the Mobile IP specification) and (3) they should intercept and redirect the packets addressed to the Mobile Hosts (the way packets are forwarded to the Mobile Hosts depends of the local micro-mobility protocol. _____Site__________ ____Internet_______ __ / / --|HA| ------- | Mobility Support | ___ | | -- |Mobile |---| O |_|BR |_| | ------- | | | --- | | __ | __________|________/ ___________________/--|CH| | | -- |===============>|<===========================================> access protocol macro-mobility:Mobile IP Figure1 : Registration _____Site__________ ____Internet_______ __ / / --|HA| ------- | Mobility Support | ___ | | -- |Mobile |---| O |_|BR |_| | ------- | | | --- | | __ | __________|________/ ___________________/--|CH| | | -- |<============== |<===========================================> micro-mobility macro-mobility:Mobile IP Figure2 : Routing In summary, 1- the protocol between the Mobile and the Mobility Support is unique 2- the intra-site mobility management and routing is managed by the local micro-mobility management protocol 3- the inter-site mobility and routing is managed by Mobile IP 3.2 Main operations Castelluccia Bellier Expires 26 December 1999 [Page 5] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 The main operations of the proposed architecture are the following : 3.2.1 Common operations : the Mobile-Mobility Support registration When the Mobile detects a new Base Station, it gets a CoA (we call it PCoA, for Physical Care-of Address) and registers to the Mobility Support. This registration is performed by sending a (Home Address, Home Agent, PCoA, MS_p), where MS_p is the Mobility Support of the Mobile is the previous site. This registration is acknowledged by the Mobility Support. This registration phase is independent of the type of movement (inter or intra site). 3.2.2 Inter-site movement When a Mobile moves into a new site, the Mobile registers to the new Mobility Support and the Mobility Support performs the following registration operations : 3.2.2.1 Macro mobility registration : Upon reception of a registration message from a Mobile, the Mobility Support must : * get a VCoA (Virtual CoA-this could be the Mobility Support's address or an address on its subnet) for the Mobile and registers it to its Home Agent on behalf of the Mobile. This Binding Update must be acknowledged. This acknowledgement is forwarded to the Mobile. * acknowledge the reception of the Mobile-Mobility Support registration message to the Mobile (this acknowlegement contains the VCoA). * ask the previous Mobility Support (the Mobility Support of the previous site. We note it MS_p) to redirect all packets addressed to the Mobile to it. MS_p must acknowledge this request and send the list of current Correspondents and the list of the sequence numbers of the lattest Binding Updates sent. * create a entry that contains the binding between the Mobile's Home address, its home agent and its VCoA + list of (Correspondents, Sequence Numbers) * send a (Home Address, VCoA) Binding Update to each Castelluccia Bellier Expires 26 December 1999 [Page 6] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 Correspondent Note : a Mobile must receive two ackowledgements after an inter-site movement : one from its Home Agent and one from its current Mobility Support otherwise it must assume that the registration has failed. Upon reception of packets coming from the Home Agent or the previous Mobility Support, the new Mobility Support sends Binding Updates to the Mobile's Correspondents. These Binding Updates contain the Mobile's PCoA if the Correspondent is local (i.e. within the visiting site) or the Mobile's VCoA if the Correspondent is distant (outside the visiting site). 3.2.2.2 Micro mobility registration : Upon reception of a registration message from a Mobile, the Mobility Support must : * create a entry that contains the binding between the Mobile's PCoA and VCoA. This information is used by the Mobility Support to redirect the packets addressed to the Mobile (VCoA) to its current point of attachment (PCoA). 3.2.3 Intra-site movement : When a Mobile moves within a site (i.e it changes of Base Station and/or subnet), the Mobile registers its new point of attachement to the Mobility Support. The Mobility Support then performs the following operations : - macro-mobility registration * no operation is required. - micro mobility registration Upon reception of a registration message from the Mobile, the Mobility Support : * updates the corresponding entry in its cache, * possibly sends Binding Updates to the Mobile's local Correspondents. Note that authentication is only necessary between the Mobile and the Mobility Support, the Mobility Support and the Home Agent, successive Mobility Supports, the Mobility Support and the Castelluccia Bellier Expires 26 December 1999 [Page 7] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 Correspondents. The Base Stations are just relays and therefore do not need to be authenticated. The Mobile must periodically send registration messages to the Mobility Support to refresh its entry in the cache. Identically the Mobility Support must refresh the Mobile's VCoA to its Home Agent and Correspondents by sending Binding Updates. Note that the refresh periods might not have the same value. 3.3 Packet delivery When a (external) Correspondent first sends packets to a Mobile, these packets are addressed to the Mobile's Home address. These packets are intercepted by the Mobile's Home Agent (if the Mobile is away) and forwarded (by encapsulation) to the Mobile's current VCoA. The encapsulated packets are intercepted by the Mobile's current Mobility Support and forwarded to the current Mobile's PCoA. The Mobility Support also sends a (Home Address, PCoA) or a (Home Address, VCoA) Binding Update to the Correspondent according to whether it is local or distant, and records the Correspondent in the Mobile's list of Correspondents. Upon reception of this Binding Update, the Correspondent updates the Mobile's (Home Address, CoA) entry and sends the forthcoming packets to the Mobile's new CoA. If the CoA is a VCoA, the packets are intercepted by the Mobile's Mobility Support and forwarded to the Mobile current PCoA. If the CoA is a PCoA, the packets are routed directly to the Mobile's current location. Note that the forwarding method from the Mobility Support to the Mobile's current PCoA is dependent of the micro-mobility in use. When a Mobile sends a packet to a Correspondent, it must include a HomeAddress option and use its VCoA as source address (except if the Correspondent is local. In this case, it uses its PCoA). 4 Examples In this section, we describe in more details the architecture and operations that are performed with different micro-mobility management protocols. We consider two micro-mobility management protocols namely micro Mobile IP and Cellular IP. 4.1 Mobile-Mobility Support registrations This phase is common to all proposals. When the Mobile detects a Base Station, it possibly gets a CoA Castelluccia Bellier Expires 26 December 1999 [Page 8] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 (we call it, PCoA, for Physical Care-of Address) and registers to the Mobility Agent. This registration is performed by sending a (Home address, Home Agent, PCoA, MS_p), where MS_p is the previous Mobility Support of the Mobile. If the Mobile did not change of Mobility Support, the MS_p field is then set to Mobility Support. The serving Mobility Support and the CoA is obtained via some kind of DHCP server or auto-configuration mechanisms. Note also that the Mobile's operations are independent of the mobility type (whether is intra or inter-site). This registration must be acknowledged. 4.2 micro Mobile IP (HMIP) The INRIA uMIP proposal [Cast98] is based on the deployment of Mobility Networks (MN). A MN of a site is a LAN that defines an address space for the mobile hosts roaming within this site. A Mobility Network contains one or several Mobility Supports. In HMIP, the Mobility Supports are called Mobility Agents. A Mobility Agent is a router of the MN that maintains a binding per Mobile Host currently visiting the site and sends Binding Updates on behalf of these Mobile Hosts. Note that there is no constraint on the physical location of the Mobility Network. However for efficiency reasons, it is preferable to connect it to the border router of the network that it is serving. The mobility Network can actually be any sub-network of the site. It does not have to be dedicated to Mobile Hosts but instead can support ordinary (fixed) hosts. Deploying a Mobility Agent in a separate Mobility Network instead of implementing it on the Border Router has two main advantages. First, it does not require any modification to the routers and is therefore easier to deploy. Second, it is more scalable since (1) it does not add additional processing constraints on the Border Router and (2) several Mobility Agents could be deployed for scalability and/or robustness motivations. However the Mobility Agent can be implemented within the Border Router if this is desirable. The main operations of the proposed architecture are the following. 4.2.1 Inter-site mobility When a Mobile moves into a new site, the following registrations are performed : Castelluccia Bellier Expires 26 December 1999 [Page 9] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 The Mobile registers to the Mobility Agent as described in section 4.1. - macro mobility registration operations : Upon reception of the Mobile-Mobility Support registration message, the Mobility Agent : * gets a VCoA (an address belonging to the MN) for the Mobile and registers it to its Home Agent on behalf of the Mobile. This Binding Update is acknowledged by the Home Agent and forwarded to the Mobile. * acknowledges the reception of the Mobile-Mobility Support registration message to the Mobile (this acknowlegement contains the VCoA). * asks the previous Mobility Agent to redirect all packets addressed to the Mobile to it. The Previous Mobility Agent acknowledges this request and sends the list of current Correspondents and the sequence numbers of the lattest Binding Updates that were sent. * creates an entry that contains the binding between the Mobile's Home address, its home agent and its VCoA + list of (Correspondents, Sequence numbers). * sends a (Home Address, VCoA) Binding Update to each Correspondent. - micro mobility registration operations : Upon reception of a registration message from a Mobile, the Mobility Agent : o creates an entry that contains the binding between the Mobile's PCoA and VCoA. This information is used by the Mobility Agent to redirect the packets addressed to the Mobile (VCoA) to its current point of attachment (PCoA). o sends a (Home Address, PCoA) to the site's Correspondents to optimize the Correspondent-Mobile routing. 4.2.2 Intra-site mobility : When a Mobile moves within a site (i.e it changes of Base Station and/or subnet), the following registrations are performed : Mobile-Mobility Support registration : Castelluccia Bellier Expires 26 December 1999 [Page 10] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 - macro-mobility : nothing is sent except the periodic registration refresh messages. - micro mobility registration : * The Mobility Agent updates the Mobile entry. * The Mobility Agent sends a (Home Address, PCoA) Binding Update to each of the Mobile's local Correspondents. 4.2.3 Packet delivery When a (external) Correspondent first sends packets to a Mobile, these packets are addressed to the Mobile's Home address. These packets are intercepted by the Mobile's Home Agent (if the Mobile is away) and forwarded (by encapsulation) to the Mobile's current VCoA. The encapsulated packets are intercepted by the Mobile's current Mobility Agent and forwarded (via encapsulation) to the current Mobile's PCoA. The Mobility Agent adds an entry in its cache and sends a (Home Address, PCoA) or a (Home Address, VCoA) Binding Update to the Correspondent according whether it is local or distant. Upon reception of this Binding Update, the Correspondent updates the Mobile's binding(Home Address, CoA) entry and sends the forthcoming packets to the Mobile's current position. If the CoA is the Mobility Agent's address, the packets are intercepted by the Mobility Agent and forwarded to the Mobile current PCoA (via encapsultion). If the CoA is a PCoA, the packets is routed directly to the Mobile's current location... 4.3 Cellular IP When Cellular IP is used as micro-mobility protocol, the Mobility Support is located within the Border Router of the site. The VCoA assigned to the Mobile Hosts is the address of the Mobility Support/Border Router. The main operations of the proposed architecture are the following : 4.3.1 Inter-site movement When a Mobile moves into a new site, the following registrations are performed : Castelluccia Bellier Expires 26 December 1999 [Page 11] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 Mobile-Mobility Support registration : The Mobile sends a registration message to the Mobility Support (Border Router) as specified in 4.1. - micro mobility registration : This registration message is intercepted by the Base Station, the Mobile is attached to. The Base Station encapsulates the message within a Route-Update packet as described in [CellIP] and forwards it to the Border Router/Mobility Support. The Route-Update packet creates and updates entries in each node's cache from the Mobile to the Mobility Support. This registration is acknowledged. (The current Mobility Support is broadcast by the local router using a router advertissement). - macro mobility registration : Upon reception of the Mobile-Mobility Support registration message, the Mobility Support/Border Router : * registers the Mobile to its Home Agent using its address (the Mobility Support's address). This is performed by sending a (Home Address, Mobility Support) Binding Update. This Binding Update is acknowledged. The acknowledgement is forwarded back to the Mobile's PCoA (via the Cellular IP routing process). * acknowledges the reception of the Mobile-Mobility Support registration message to the Mobile (this acknowlegement contains the VCoA). * asks the previous Mobility Support (the Mobility Support of the previous site. We note it MS_p) to redirect all packets addressed to the Mobile to it. MS_p acknowledges this request and sends the list of current Correspondents and the sequence numbers of the lattest Binding Updates that were sent. * creates a entry that contains the binding between the Mobile's Home address, its home agent and its VCoA + list of (Correspondents, Sequence Number). * sends a (Home Address, VCoA) Binding Update to each Correspondent. These Binding Updates contain the Mobile's PCoA if the Correspondent is local (i.e. within the visiting Castelluccia Bellier Expires 26 December 1999 [Page 12] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 site) or the Mobility Support/Border Router's address if the Correspondent is distant (outside the visiting site). 4.3.2 Intra-site movement : When a Mobile moves within a site (i.e it changes of Base Station and/or subnet), the following registrations are performed : Mobile-Mobility Support registration : The Mobile sends a registration message to the Mobility Support (Border Router) as specified in 4.1. - micro-mobility This registration message is intercepted by the Base Station, the Mobile is attached to. The Base Station encapsulates the message within a Route-Update packet as described in [CellIP] and forwards it to the Border Router/Mobility Support. The Route-Update packet creates and updates entries in each node's cache from the Mobile to the Mobility Support. - macro-mobility No macro-mobility registration is necessary....besides the regular Binding Update refresh Binding Update messages. 4.3.3 Packet delivery When a (external) Correspondent first sends packets to a Mobile, these packets are addressed to the Mobile's Home address. These packets are intercepted by the Mobile's Home Agent (if the Mobile is away) and forwarded (by encapsulation) to the Mobile's current Mobility Support/Border Router. The encapsulated packets are interceptedreceived by the Mobile's current Mobility Support/Border Router, decapsulated and forwarded (via the CellularIP routing mechanisms) to the current Mobile's PCoA. The Mobility Support/Border Router also sends a (Home Address, Border Router) to the external Correspondents. Upon reception of this Binding Update, the Correspondent updates the Mobile's (Home Address, CoA) entry and sends the forthcoming packets to the Mobile's current Mobility Support. The packets are received/intercepted by the Mobility Support, and forwarded to the Mobile current PCoA. Castelluccia Bellier Expires 26 December 1999 [Page 13] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 5. Security Considerations As in Mobile IP, all registration messages have to be authenticated. As in Mobile IP, we propose to use IPSEC to authenticate the registration messages and the binding updates. There is two levels of security : - The macro-mobility registration messages must be authenticated between the Mobility Support and the Correspondents. - The micro-mobility registration messages must be authenticated between the Mobility Support and the Mobile Hosts. Our proposal does not introduce more security problems that those introduced by Mobile IP. 6. Conlusion We propose a framework that allows the deployement of various micro mobility management protocols in different parts of the Internet while still providing connectivity to mobile hosts. In the proposed framework, the mobility management protocol is composed of 3 components: - The first one, the access mobility management protocol, specifies the registration procedure between the Mobile and the site it is attached to. It is standard and independent of the micro and macro mobility management protocols used in the core of the network. This protocol is ``light'', i.e. minimises the operations performed by the Mobile Hosts (which probably have limited capacity and power). - The second one, the micro mobility management protocol, is the protocol that handles the local mobility (within the domain) of the Mobile. - The third one, the macro-mobility management protocol, is the protocol that handles the macro-mobility (inter-domain) of the Mobile. We propose to use Mobile IP as macro-mobility management protocol. The complete specification of these different components are on its way and will be published soon. The access protocol uses Mobile IPv6 registration messages. 7. References [1] Castelluccia C., "An Hierarchical Mobile IPv6 Proposal", INRIA Castelluccia Bellier Expires 26 December 1999 [Page 14] INTERNET-DRAFT UNIFIED HIERARCHICAL MOBILITY 25 June 1999 TR-0226, November 1998. [2] Perkins, C., Editor: "IP Mobility Support", RFC 2002, October 1996. [3] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro- mobility support using HAWAII", draft-ramjee-micro-mobility-hawaii- 00.txt, 19 February 1999. Work in progress. [4] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet draft, draft-valko-cellularip-00.txt, November 1998. Work in progress. Author's Address Claude Castelluccia and Ludovic Bellier INRIA PLANETE team ZIRST-655 avenue de l'Europe 38330 Montbonnot Saint Martin FRANCE Claude.Castelluccia@inria.fr Ludovic.Bellier@inria.fr draft-castelluccia-uhmm-framework-00.txt Castelluccia Bellier Expires 26 December 1999 [Page 15]