Mobile IP Working Group B. Sarikaya Internet Draft Document:draft-sarikaya-mobileip-lmmframework-00.txt Category: Standards track Alcatel September 2002 Architectural Framework for Localized Mobility Management draft-sarikaya-mobileip-lmmframework-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. Distribution of this memo is unlimited. Abstract This document defines an architectural framework for localized mobility management (LMM) in Mobile IPv4 and Mobile IPv6. LMM requires new architectural entities to be added to the architectures of Mobile IPv4 and v6. Also the availability of localized mobility management must be advertised by the localized mobility agents. The document defines these entities and their interactions with the existing entities and changes required to router/agent advertisements. The document also identifies a number of open issues whose resolution is crucial to the standardization of LMM protocols. Sarikaya 1 Architectural Framework for LMM September 2002 Table of Contents Status of this Memo............................................1 Abstract.......................................................1 Table of Contents..............................................2 1. Introduction................................................3 2. Terminology.................................................3 3. LMM Architecture............................................4 3.1 Generic Architecture.......................................5 3.2 LMA Architectures..........................................5 3.3 Domain Change Detection....................................6 3.4 Route Optimization ....................................6 4. Mobile IPv4 Considerations .................................8 5. Open Issues ................................................8 6. Security Considerations ....................................9 7. References..................................................9 8. AuthorsÆ Addresses ........................................9 Sarikaya Expires March 2003 2 Architectural Framework for LMM September 2002 1. Introduction Terminal mobility in the Internet is handled by Mobile IP version 4 [3] and version 6 [2]. Base Mobile IP protocols define handover procedures to be used in case the mobile node changes subnets. The mobile node (MN) has to register its care of address with the home agent (HA) and corresponding nodes (CN) in order to divert the data flow into the new subnet. As the number of roaming users increases, e.g. in wireless networks, the ways must be found to decrease the latency involved in registering with far away HA and CNs and to increase the efficiency of handovers by localizing mobility management. Localized mobility management is used for reducing registration signaling with the home agent and correspondent nodes. In a local domain new entities called localized mobility agents (LMA) are introduced to act as local home agents. The mobile node gets a domain or regional care of address and registers it with HA and CNs (if route optimization is used). The present and any future local care of addresses are registered only with LMAs. Therefore LMM reduces the latency of the registration messages sent in the Internet and also leads to increase the handover speed. Registration with HA and CNs occurs again only if MN moves out to a new domain. The document continues as follows: Section 2 defines the terminology. Section 3 gives a generic architecture for LMM placing various entities such as the layer 2 entities of access points, access routers, localized mobility agents and the corresponding node and the home agent. Section 4 is on Mobile IPv4 considerations. Section 5 lists open issues. Section 6 is on security considerations. 2. Terminology See [1] for additional terminology. Access Router (AR) Mobile nodeÆs (MN) default router as in [2]. Domain A collection of networks sharing a common network administration. Foreign Agent (FA) As defined in [3]. Gateway Local Mobility Agent (GLMA) In a hierarchy of LMAs, the gateway LMA is the one that is connected to the Internet. Home Agent (HA) As defined in [3]. Home domain The domain where the home network and home agent are located. Home network Sarikaya Expires March 2003 3 Architectural Framework for LMM September 2002 As defined in [3]. Local Mobility Agent (LMA) As defined in [4]. Local Care-of Address (LCoA) The address MN uses on each link in the domain Mobile Node (MN) As defined in [3]. Regional Care-of Address (RcoA) The address associated with GLMA that MN uses for regional regional registration. Regional Foreign Agent (RFA) A Foreign Agent which may be the target of a request for regional registration [5]. Regional Registration A mobile node performs registration locally at the visited domain, by sending a Regional Registration Request to a GFA, and receiving a Regional Registration Reply in return [6]. Site A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. As defined in [8]. 3. LMM Architectures Figure 1 shows a generic architecture. +-+ +----+ +---+ +----+ -->| |--------| AR |-------|LMA| | LMA| | +---+ +-+ /+----+ +---+ +----+ | | |MN | AP / | I | +---+ / | N | | +-+ / +---+ | T | +--+ | | |---- |LMA|------| E |--|CN| | +-+ +---+ | R | +--+ | AP | N | Movement v |E | \ +-+ +----+ +---+ +----+ |T| \ | |-------| AR |--------|LMA| | LMA| - \ Visited +-+ +----+ +---+ +----+ \ Domain AP | ------------------------------------------------ | Other domains | +--+ |HA| +--+ Figure 1. Generic LMM Architecture Sarikaya Expires March 2003 4 Architectural Framework for LMM September 2002 3.1 Generic Architecture Consider a mobile node (MN) in a visited administrative domain, or simply visited domain. Localized mobility management requirements [4] can be satisfied with the introduction of a new architectural entity called local mobility agent (LMA). There are layer 2 entities called access points (AP) that enable MN to connect to the access router (AR) for IP connectivity to the Internet. ARs are connected to LMAs. LMAs may be interconnected in different ways. ARs MAY also be configured to act as LMAs at the lowest level. The LMA that is connected to the Internet is called the Gateway LMA (GLMA). 3.2 LMA Architectures LMAs can be connected into a tree topology as shown in Figure 2. GLMA is located at the root of the tree. MN MUST form a regional care of address from GLMA. MN after receiving the address of GLMA can configure a regional care of address on GLMAÆs subnet. GLMA and other LMAs keep a regional binding cache. A binding cache entry is created for an MN with each regional registration. The binding cache entry at GLMA binds the home address of MN with the next LMA downstream. The entries in other LMAs are formed in a similar way. ARs are the default routers of MN in the subnet. ARs are not LMAs. +--------+ | | | GLMA |----| | | | | +--------+ | I | / | \ | N | ... ... ... | T | +--+ | | E |--|CN| +--------+ | R | +--+ | | | N | | LMA | | E | \ | | | T| \ +--------+ \ / \ | +--------+ +--------+ +--+ | | | | |HA| | AR | | AR | +--+ | | | | +--------+ +--------+ | | | +--------+ ... | | | MN | | | +--------+ Figure 2. Hierarchical LMM Architecture Sarikaya Expires March 2003 5 Architectural Framework for LMM September 2002 This architecture requires special care on the IP datagrams to be routed downstream. The datagrams coming from the home agent tunneled to GLMA. GLMA decapsulates it and finds the home address of MN as the destination address. Using the binding cache entry GLMA reencapsulates the datagram to the corresponding lower care-of address. In Mobile IPv6, CNs send route optimized packets to MN. Route optimized packets are processed by GLMA by for finding the home address of MN in the routing header and checking the regional binding cache entry in order to get the next LMA address to forward the packets to. GLMA then replaces the destination address with the downstream LMA address. LMAs downstream forward route optimized packets by modifying the destination address and this continues until MN receives the packet. Two level hierarchy can also be used as shown in Figure 3. ARs in the figure MAY act like LMAs in this case Figure 3 represents a two level hierarchy. IP datagram forwarding downstream for tunneled packets from MNÆs HA is done by consulting the regional binding cache. The packet is decapsulated and then tunneled to MNÆs local care-of address. Route optimized packets from CNs are tunneled to MNÆs local care-of address if LMA has a binding cache entry for the final destination. 3.3 Domain change detection It is critical for the operation of any LMM protocol that MNs should be able to know if it is in its home domain (site) or in a visited domain. In neighbor discovery, routers advertise subnet prefixes. Subnet prefixes are obtained from site prefixes. Therefore routers can advertise site prefixes as part of neighbor discovery. This way MN can detect domain changes as described in [6]. Presently there is no standard means of obtaining site prefixes and this restricts MNs ability to detect domain changes. There are other restrictions associated with this, e.g. site-local addresses can not be used as home addresses [7]. Routers can advertise site prefixes as an extension required by LMM. MNs should be able to get the site prefix from RAs coming from LMAs and therefore detect any change of the domain. When the domain change is detected MN must perform regional registrations. 3.4 Route optimization From the architectures in Figures 2 and 3, it is clear that after regional registrations are performed, the routing of datagrams from CN to MN is triangle routing. LMA(s) receive the datagrams and then tunnel them to MN. The difference from HA anchored triangle routing is reduction in the number of hops. In this LMM induced triangle routing, the IP header added for tunneling can be considered as the highest concern for performance reductions compared with route Sarikaya Expires March 2003 6 Architectural Framework for LMM September 2002 optimization which uses routing headers that occupy smaller number of bytes. +------+ | HA | +------+ | | +----+ | | CN | | +----+ +-+ | | | ----------------------- | INTERNET | | | ------------------------ | | | +-------+ | LMA | +-------+ | \ | +-------+ | | | | +-----+ +-----+ | AR1 | | AR2 | +-----+ +-----+ +-----+ | MN | +-----+ Figure 3. Flat LMM Architecture The tunneling overhead can be avoided in some cases such as when the CNs are in the same link as MN as follows: If the local access router is an LMA, MN MUST select this LMA; otherwise MN MUST use its LCoA to communicate with local CNs. When there are routing loops, e.g. AR1 and AR2 are directly connected in Figure 3, some CNÆs routing distance may become shorter to MN directly, rather than going through LMA. As a result, LMM is causing an unavoidable tunneling overhead as well as non-optimal routing. Routing loops may manifest in more complicated scenarios in which a distant CN is connected to a border router (BR1) and the LMA is connected to a different border router (BR2) and the CN is of shorter distance to MN without involving LMA than with involving LMA. Such an Sarikaya Expires March 2003 7 Architectural Framework for LMM September 2002 architecture is given in [8]. The routing loop in this example is also created because of a direct link between ARs. Problems associated with routing loops can be avoided as follows: Routers MUST be configured to send router advertisements with LMA extension on certain interfaces, e.g. avoiding AR to AR direct links. GLMA MUST be the only node in the domain to which CNs outside the domain send datagrams. 4. Mobile IPv4 Considerations GLMA in Mobile IPv4 acts like a gateway foreign agent (GFA). Other LMAs become regional foreign agents (RFA). AR is the Foreign agent (FA). FAs MUST be LMM-aware in Mobile IPv4. If a tree architecture is used, the agent advertisements MUST be extended to advertise the hierarchy of addresses to MNs. This is done by GFA first putting its address in its advertisements and by each RFA attaching its address into the advertisement. This way the MNs receive the addresses in the path to GFA. In Mobile IPv4 agent advertisements do not carry site prefixes. There must be other mechanisms used for domain change detection. Network access identifiers (NAI) can be used for this purpose [9]. MN compares the realm part of its NAI with the realm part of NAIs of LMAs and decides on the first domain change. Subsequent domain changes are similarly detected. Using network access identifiers, MN may be assigned a different home address by a different home agent every time it changes its FA. This is called dynamic home agent assignment. Dynamic home agent assignment is equivalent to LMM if the new home agent is always chosen from the same domain in which FA resides. Regional care of address is the address of GFA in Mobile IPv4. MN can also detect the domain change by comparing its regional care of address with the address coming from the agent advertisements. 5. Open Issues Whether or not it is left to the LMM protocol to solve domain change detection problem. Whether or not base MIPv4/v6 operation and LMM operation can be mixed once LMM start to be used. This is important for efficiency reasons. It may be advantageous for MN to communicate CNs in the same domain using the base protocol and to communicate CNs outside the domain using LMM. Whether or not a hierarchy of LMAs should be used. If LMAs are configured hierarchically then it is not clear if the hierarchy should be advertised in the router advertisements. Sarikaya Expires March 2003 8 Architectural Framework for LMM September 2002 Whether or not the regional care of address (RCoA) can be used as the source address by MN. For Mobile IPv4 based LMM, while regional care of address is a public address, the local care of addresses can be private. This may give an incentive for the deployment of LMM protocols. On the other hand the requirement for FAs to be LMM-aware brings deployment difficulties. 6. Security Considerations Registration messages exchanged between LMA and MN MUST be authenticated. MN MUST share an authentication key with all LMAs that it communicates. LMM helps reduce the security problem associated with the registration messages exchanged between MN and CN since MN does not need to send any new registration messages (binding updates) as long as it stays in the same domain. 7. References 1 Manner, J., Kojo, M, "Mobility Related Terminology", draft-manner- seamoby-terms-04.txt, work in progress, May 2002. 2 Johnson, D.B., Perkins, C.E., Arkko, J., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, work in progress, June 2002. 3 Perkins, C.E., "IP Mobility Support", RFC 3220, IETF, December 2001. 4 Williams, C., "Localized Mobility Management Requirements", draft- ietf-mobileip-lmm-requirements-02.txt, work in progress, June 2002. 5 Gustafsson, E., Jonsson, A., Perkins, C.E., "Mobile IPv4 Regional Registration", draft-ietf-mobileip-reg-tunnel-06.txt, work in progress, March 2002. 6 E. Nordmark, "Site Prefixes in Neighbor Discovery", draft-ietf- ipngwg-site-prefixes-05.txt, work in progress, February 2001. 7 S. Deering, et al., "IPv6 Scoped Address Architecture", draft-ietf- ipv6-scoping-arch-04.txt, work in progress, June 2002. 8 Y-H. Han, J-H. Choi, J-H. Lee, "Route Optimization Support for Localized Mobility Management Based on IPv6", draft-han-mobileip- rolmmv6-00.txt, work in progress, July 2002. 9 P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000. 8. Author's Addresses The working group can be contacted via the current chairs: Basavaraj Patil Nokia Sarikaya Expires March 2003 9 Architectural Framework for LMM September 2002 6000 Connection Dr. Irving, TX. 75039 USA Phone: +1 972-894-6709 Email: Basavaraj.Patil@nokia.com Phil Roberts Megisto Corp. Suite 120 20251 Century Blvd Germantown MD 20874 USA Phone: +1 847-202-9314 Email: PRoberts@MEGISTO.com Questions about this memo can also be directed to: Behcet Sarikaya Network Strategy Group, Mobile Networking Team Alcatel USA M/S 026 1000 Coit Rd. Plano, TX 75075 USA Email: behcet.sarikaya@alcatel.com Phone: (972) 477-2794 Fax: (972) 519-2460 Sarikaya Expires March 2003 10