Mobile IP Working Group B. Sarikaya Internet Draft Document:draft-sarikaya-mobileip-lmmframework-01.txt Category: Informational Alcatel October 2002 Architectural Framework for Global and Localized Mobility Management draft-sarikaya-mobileip-lmmframework-01.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 mobility management (MM) in general with an emphasis on localized mobility management (LMM). MM requires new architectural entities to be added to the Internet Protocol version 4 and version 6. Also the availability of mobility management must be advertised by these entities extending ICMPv4 and v6. The document identifies these entities as routing proxies (RP) and defines abstractly the behaviour of RPs and their interactions with the existing entities and the router/agent advertisements that RP needs to issue in order to let its presence known. Basic architecture can be optimized by either informing the end nodes in order to achieve route optimization and/ or by localizing mobility management. LMM itself requires new entities identified as localized routing proxies or localized mobility agents (LMA) to be introduced to the basic architectures of mobility management. The behaviour of LMA is abstractly defined. The document also identifies a number of open issues whose resolution is crucial to the standardization of LMM protocols. Sarikaya 1 Architectural Framework for G&L MM October 2002 Table of Contents Status of this Memo............................................1 Abstract.......................................................1 Table of Contents..............................................2 1. Introduction................................................3 2. Terminology.................................................3 3. MM Architectures............................................4 3.1 Generic Architecture.......................................5 3.2 Route Optimization.........................................6 3.3 IPv4 Considerations ....................................6 4. LMM Architectures..........................................7 4.1 Generic Architecture.......................................7 4.2 LMA Architectures..........................................8 4.3 Domain Change Detection....................................9 4.4 Route Optimization ....................................9 5. Mobile IPv4 Considerations ................................11 6. Open Issues with LMM ......................................11 7. Security Considerations ...................................12 8. Acknowledgements...........................................12 A. Major Changes .............................................12 9. References.................................................12 10. Authors' Addresses ......................................13 Sarikaya Expires April 2003 2 Architectural Framework for G&L MM October 2002 1. Introduction Terminal mobility is an essential component of seamless connectivity of the mobile nodes roaming in the Internet and linking themselves to the network using different link technologies, wireless or wired. Terminal mobility in the Internet is handled by global mobility management. Global mobility management enables the mobile nodes to change their point of attachment to the network and yet keep their home addresses. As home address stays the same, the flow of datagrams from the Internet is seamless and the sessions are not disrupted. Global mobility management introduces at the home network a new entity called home routing proxy (HRP). In IP version 4, a new local entity called foreign routing proxy (FRP) may be used. There are two base protocols for global mobility management: 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 routing proxy (RP) at the home network called home agent (HA) and with 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 global mobility management in order to introduce the new entities named home routing proxy and foreign routing proxy. Section 4 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 routing proxy. Section 5 is on Mobile IPv4 considerations. Section 6 lists open issues. Section 7 is on security considerations. 2. Terminology See [1] for additional terminology. Access Router (AR) Sarikaya Expires April 2003 3 Architectural Framework for G&L MM October 2002 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 As defined in [3]. Home Routing Proxy (HRP) The RP that is at the home network, aka home agent. 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]. Routing Proxy (RP) Routing proxies are the network nodes that receive datagrams, decide based on a lookup to which server to forward the datagram. The forwarding is stateless. 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. MM Architectures A mobile node at home network needs a routing proxy at the home network if its communication with the corresponding nodes needs to be Sarikaya Expires April 2003 4 Architectural Framework for G&L MM October 2002 maintained above the Internet Protocol (layer 3) when MN goes to a visited network. Figure 1 shows a generic mobility management architecture which will be explained next. +---+ Home |-------|HRP|---+ Network | +---+ | +-+ | +----+ +--+ -->| |------|-| AR |-------|BR|----| +---+ +-+ | +----+ +--+ | | |MN | AP / | I | +---+ / | N | | +-+ / | T | +--+ | | |---- | E |--|CN| | +-+ | R | +--+ | AP | N | Movement v |E | +-+ +----+ +---+ |T| | |-------| AR |--------| BR|----| Visited +-+ +----+ +---+ Network AP Figure 1. Generic MM Architecture 3.1 Generic Architecture In Fig. 1, AR is the subnet's default router and the border router (BR) plays no specific role in the mobility management other than routing the datagrams. The home routing proxy (HRP) is the entity in charge of mobility management of the subnetÆs nodes. As such HRP announces its services using ICMP router advertisements and mobile nodes (MN) get the address of HRP to be used when roaming. A home network may have several HRPs common to the border router. Replication of HRPs is desirable for reliability and scalability purposes. In case of many HRPs in the same home network, the load balancing between them might be desirable. When MN is in a visited network, it acquires a co-located care of address (CoA) using either stateful or stateless address acquisition techniques. Registration of this address with HRP is a key component of mobility management. Registration enables HRP to update its lookup list, aka binding cache, binding the home address of MN to its co-located care-of address. Upon successful registration, HRP MUST perform proxy neighbor advertisement with which HRP captures datagrams destined to the home address of MN. Registration MUST only create soft-state. At the expiry of the registration life time, registration is performed again until MN returns home network. Sarikaya Expires April 2003 5 Architectural Framework for G&L MM October 2002 HRP treats the datagrams destined to MN when not at home network as requests to be replied by MN. HRP proxies AR in delivering the datagrams. HRP MUST encapsulate these requests and send them to LCoA. Encapsulation MAY use IP-in-IP encapsulation or some other standard encapsulation method. HRP MUST use the lookup list in order to correctly identify MN. The process of delivering the requests to MN MUST be stateless, i.e. HRP as to the eventual reception by MN in its visited network. Corresponding nodes (CN) continue to use the home address of MN and the mobility management is transparent to CNs. However, the proxied routing, aka triangle routing of datagrams from HRP to MN in visited network is a cause for concern especially for CNs in the visited network, etc. Triangle routing can be avoided using route optimization in which CNs send their datagrams directly to the visited network. Route optimization which is discussed next in Section 3.2 leads to the direct involvement of CNs in the mobility management. The latency of registration messages between RPs and MNs is a cause of another concern with mobility management and the solution leads us to the localized mobility management (LMM). LMM is discussed later in Section 4. 3.2 Route Optimization Ideal mobility management with no involvement of routing proxies can be achieved if CNs can acquire the latest care-of address of MN and bind it with the home address and forward the datagrams to the care- of address. This process is called route optimization in mobility management. After receiving the first datagram HRP MAY register MNÆs care-of address with CN. MN itself MAY register its care-of address with CN. CN MUST keep a lookup list, aka binding cache to bind the home address to the care-of address of all MNs that it has active sessions. Source routing is used in route optimized datagrams. Route optimized packets from CN MUST carry the home address as the destination address and MUST NOT use encapsulation. Routing extension headers are the proper mechanism to use in IP version 6. Latency of the registration messages between MN and CN is a concern for optimization. The solution is to use localized mobility management (LMM) as discussed in Section 4. 3.3 IPv4 Considerations Due to the lack of a stateless address configuration in IPv4 a new entity MAY be added on the visited subnet to give MNs a care-of address. This entity will be called foreign routing proxy (FRP). FRP MUST be the default router for MN. Sarikaya Expires April 2003 6 Architectural Framework for G&L MM October 2002 FRP MUST advertise its mobility services using ICMP, aka agent advertisements. MN MUST be able to solicit an agent advertisement in the process of determining the existence of any FRP in the visited network. After configuring the care-of address, MN MUST register the address with HRP via FRP. FRP must deliver the registration reply from HRP to FRP and update its lookup list. FRP MUST decapsulate datagrams from HRP and then deliver them to MN. FRP consults its lookup list in the delivery. 4. LMM Architectures An optimization to mobility management is to use localized mobility management in which HRP functionality is replicated in the domain using local routing proxies (LRP). We call LRP a localized mobility agent in order to align the terminology with LMM requirements document [4]. Figure 2 shows a generic architecture. We assume Mobile IP version 4 [3] and version 6 [2] as the standard solutions to the mobility management described in Section 3 above. Home routing proxy is referred to as the home agent (HA) as in the base protocols. +-+ +----+ +---+ +----+ -->| |--------| 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 2. Generic LMM Architecture 4.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 Sarikaya Expires April 2003 7 Architectural Framework for G&L MM October 2002 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). 4.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 3. Hierarchical LMM Architecture Sarikaya Expires April 2003 8 Architectural Framework for G&L MM October 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 first finding the home address of MN in the routing header and then 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. MN registers its LCoA with GLMA first time in the domain. In subsequent handoffs in the domain, MN registers with lower LMAs in the hierarchy which means reduced latency in registration signaling. Two level hierarchy can also be used as shown in Figure 4. ARs in the figure MAY act like LMAs in this case Figure 4 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. LMAs may not need to know the home address of MNs. Regional binding cache SHOULD bind RCoA with LCoA. An alternative downstream packet processing can be done as follows: LMA captures the packet addressed to RCoA using proxy neighbor advertisements and encapsulates the packet using LCoA as destination address and sends it downstream. The packet is decapsulated by MN and the other LMAs in hierarchy are not involved. LMM MUST be transparent to the home routing proxy (HRP) or the home agent (HA) operation. LMM protocols MUST not induce any new action on HRPs. 4.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]. Sarikaya Expires April 2003 9 Architectural Framework for G&L MM October 2002 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. 4.4 Route optimization From the architectures in Figures 3 and 4, 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 optimization which uses routing headers that occupy smaller number of bytes. +------+ | HA | +------+ | | +----+ | | CN | | +----+ +-+ | | | ----------------------- | INTERNET | | | ------------------------ | | | +-------+ | LMA | +-------+ | \ | +-------+ | | | | +-----+ +-----+ | AR1 | | AR2 | +-----+ +-----+ +-----+ | MN | +-----+ Figure 4. Flat LMM Architecture Sarikaya Expires April 2003 10 Architectural Framework for G&L MM October 2002 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 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. 5. 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 [10]. 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. Sarikaya Expires April 2003 11 Architectural Framework for G&L MM October 2002 6. Open Issues with LMM 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. LMA discovery is facilitated with the use of router advertisement extensions. Static configuration can also be envisaged using configuration protocols such as DHCP. It is also possible to let MNs discover using ICMP Echo Requests and Replies [11]. Whether or not a hierarchy of LMAs should be used. Hierarchy of LMAs offer the advantage of better scalability and reliability. The registration signaling latency is also reduced since every time MN hands off to a different AR in the domain, the regional registration goes up in the hierarchy until the common lowest ancestor in the tree. If LMAs are configured hierarchically then it is not clear if the hierarchy should be advertised in the router advertisements. It is only necessary that each LMA offer its regional care-of address. 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. 7. Security Considerations Registration messages exchanged between MN and CN for route optimization MUST be secured. Return routability can be used for this purpose. Return routability has the negative effect of increasing the latency of registration messages. 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. 8. Acknowledgements Thanks to James Kempf (NTT DoCoMo) for suggesting the routing proxy abstraction for mobility agents. Thanks to JinHyeock Choi Yoon-Hee Han (Samsung), and Alexandru Petrescu (Motorola) for insightful comments. Sarikaya Expires April 2003 12 Architectural Framework for G&L MM October 2002 A. Major Changes In version 1. - added a section on mobility management architectures based on routing proxies 9. References 1 Manner, J., Kojo, M, "Mobility Related Terminology", draft-ietf- seamoby-mobility-terminology-00.txt, work in progress, August 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 3344, IETF, August 2002. 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. 10 P. Calhoun, T. Johansson, C.E. Perkins, "Diameter Mobile IP v4 Application", draft-ietf-aaa-diameter-mobileip-12.txt, August 2002, completed AAA WG last call. 11 V. L. L. Thing, H. C. J. Lee, Y. Xu, "Hop-by-hop Local Mobility Agents Probing", draft-vriz-mobileip-hbhlmap-00.txt, work in progress, June 2002. 10. Author's Addresses The working group can be contacted via the current chairs: Basavaraj Patil Nokia 6000 Connection Dr. Sarikaya Expires April 2003 13 Architectural Framework for G&L MM October 2002 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 Gabriel Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan France EMail: gab@sun.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 April 2003 14