Informational Hongyi Li Internet Draft Nortel Networks draft-li-mobileip-lmm-framework-00.txt Expires: January 2002 July 2001 Local Mobility Management Framework 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 obsolete 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. 1 Abstract The mobile wireless access networks are converging towards IP-based architecture that enables interconnect of different layer 2 radio access systems. IP-based local (or micro) mobility management (LMM) solution is the key to unify the different layer 2 mobility management solutions in the new architecture. This draft defines a LMM framework that supports localized IP route re-direction at the edge of Internet. The proposed framework unifies the route re- direction related signals and allows intelligent handoff algorithms to coordinate the route re-direction process to achieve desired handoff performance. In this framework, a mobile node keeps its routable IP address un-changed when it moves within a local mobility domain such that the correspondent nodes do not need to be informed about the local movement of the mobile node. The basic concept of this framework is the discovery of the set of network nodes that have to be updated when handoffs occur between access ports. Therefore, the handoff intelligence can modify the forwarding state of the set of handoff-affected routers as the mobile node moves through the network. This framework provides the basis for developing different handoff control algorithms. Hongyi Li 1 Local Mobility Management Framework July, 2001 2 Introduction Mobility management is an important service in future Internet to support large amount of mobile devices. This draft defines a local mobility management framework that supports IP mobility by localizing the route redirection at the edge of the Internet. This framework has two basic architecture assumptions: - Firstly, the Internet mobility management should separate mobile routing from the reachability discovery so that the IP addresses are solely used for routing purposes. It eliminates the need of using home addresses as the identity of mobile nodes. This separation allows the integration of the advances in directory and location services in the mobility management. - Secondly, this framework further assumes that local mobility management is independent of the macro-mobility schemes (e.g., MIP, end-to-end session migration) used by the mobile nodes. The local mobility management is complementary to the macro-mobility management to reduce the amount of mobility related signals between communication peers. Local mobility management aims to re- direct route towards the handoff MNs at the network nodes that are close to where the handoff takes place while allowing MN to keep its routable IP address after handoff. Allowing a MN to keep its address after handoff enables the localization of handoff signals and results in fast and consistent handoff performance. The objectives of this local mobility framework are following: - Reduce the number of far reach signals by limiting the route re- direction as close to the handoff mobile nodes as possible. - Unify the route re-direction activities in one signaling framework such that the handoff intelligence can coordinate these activities to achieve desirable handoff performance. This departs from the current MIP approach that uses different protocols for path extension (i.e., extends tunnel from old access router to the new one as in Fast handoff for MIP)[8], and path switching (i.e., replaces, at a crossover router, the tunnel to the old access router with the one to the new access router as in Hierarchical MIP)[5]). In terms of route re-direction, HMIP and FHIP do the similar thing that is to re-direct IP routes towards a handoff mobile at the nodes that are affected by the MN handoff. - Enable topology independent route re-direction protocol to avoid arbitrary development of topology specific route redirection protocols. The examples of topology specific approaches are flat HMIP for star topology, Regional Registration for tree topology [6], and Fast Handoff for chain topology. - Support distributed forwarding state that enables the distribution of signaling and data traffic over the network nodes to avoid signalling and data traffic concentration points and eliminate the single point of failure in the network. Li Informational-Expires January 2002 2 Local Mobility Management Framework July, 2001 The rest of this draft will first describe the network reference architecture and define the terminology covering certain concepts related to this framework. In section 4, an overview of the local mobility management framework is described. Section 5 presents a local mobility management solution developed based on the framework. Section 6 discusses the mapping of the route re-direction capability of the framework to star, tree, and chain network topologies. Finally, section 9 summarizes the key concepts of this framework. 3 Reference architecture and terminology 3.1 Mobile wireless access network model The IP-based mobile wireless access network model considered in this draft consists of interconnected IP routers attached to the Internet backbone, and provides Internet access to mobile users through various types of radio interfaces (e.g., UMTS, CDMA2000, WLAN). A local mobility management domain is assumed to consist of multiple subnets that are interconnected by routers in a general topology. An intra-domain routing protocol (IGP) (e.g., OSPF or RIP) is used for determining the forwarding paths towards the fixed nodes in this network. The LMM protocol is therefore responsible for determining the forwarding paths towards the mobile nodes and re-directing those paths when the MNs change their points of attachment. Note that the routers in figure 1 could be application level routing agents that are configured as an overlay network on top of the IP-based wireless access network. Various types of tunnels can be used to interconnect the nodes (i.e., routing agents) in an overlay network. Internet Backbone +-+ +----+ +---+ +----+ | |<-->| |--------| AR |-------|AR |------| AR |---| [] +-+ /+----+ +---+ +----+ | MN AP / \ \ / | / \ \ / | +-+ / \ +---+ | | |---- \ |AR | | +-+ \ +---+ | AP \ / \ | \ / \ | +-+ +----+ +---+ +----+ | | |-------| AR |--------|AR |------| AR |---| +-+ +----+ +---+ +----+ | AP Figure 1. Network reference architecture for wireless access network 3.2 Definitions Mobile Node (MN) Li Informational-Expires January 2002 3 Local Mobility Management Framework July, 2001 An IP node capable of changing its point of attachment to the network. Access Port (AP) An interface of an Access Router (defined later) for transmitting data to or receiving data from Mobile Nodes. Access Router (AR) An IP router in an access network that interconnects different IP subnets and may also have APs to provide network access to MNs. An AR has at least two interfaces, and at least one of them must connect to another AR or Internet backbone. Access Network (AN) An IP network with one or more subnets that are interconnected by ARs. An AN may connected to the Internet backbone through gateways. Mobile Aware Router (MAR) An AR that has the capability and is configured to track the mobile node's current point of attachment (i.e., access port). It forwards the IP packets destined to a MN towards its current point of attachment. If all the ARs in an access network are MARs, each AR knows where to forward the IP packets towards the mobile nodes. If only a subset of the ARs are MAR, tunnels can be used to connect the MARs into an overlay network such that the data packets can be tunneled through the non-MARs between a pair of MARs. Therefore, mobile routing protocol can operate among the MARs no matter it is used in all the ARs of an access network or a subset of ARs that form a logical overlay network. Local Mobility Domain A local mobility domain contains one or more IP subnets. Within the local mobility domain, the routable IP address assigned to a mobile node does not change. Handoff Affected Router Group (HARG) A set of MARs whose forwarding tables must be updated when a MN moves its point of attachment from one AP to another. 4 Overview of local mobility management framework 4.1 Mobile reachability This draft assumes a mobility management architecture that separates the reachability discovery and the mobile routing functions in Internet. In this architecture, an application can use any reachability discovery service as long as it provides the appropriate name-to-location binding in a timely fashion [7]. The reachability discovery services are used at the beginning of a Li Informational-Expires January 2002 4 Local Mobility Management Framework July, 2001 session between communication peers to determine the IP address currently in use by a MN. To keep the mobile node "always-on", the reachability discovery service may collaborate with paging service to activate the mobile nodes that are not active. Paging service can locate an MN in a specified domain and alert it to attach to the network. 4.2 Mobile attachment process When a mobile node attaches to the network, it must obtain a routable IP address by using either stateful (e.g., DHCP) or stateless (e.g., IPv6 auto-configuration) address allocation mechanisms in the local domain [3]. The attachment process might be initiated by mobile node itself or by an attachment request from the correspondent node via reachability discovery service. After acquiring an IP address, the mobile node must register its identification with the IP address to the reachability discovery service to establish the global reachability. 4.3 Mobile tracking process In this framework, a MN's IP address is allocated from the aggregated prefix assigned to the AP that is a topologically correct IP address. As the MN moves, the allocated IP address stays with it so that there is no need to inform the correspondent nodes of the move and the higher-layer sessions are unaffected by the change of attachment point. This is accomplished by the LMM routing protocol modifying the intra-domain routing tables to reflect the new AP used by the MN. When the HARG members receive the route update request, they can decide to use prefix based forwarding or host specific forwarding for the handoff MN. Host specific route is only required as the MN moves with active sessions, therefore the associated scaling properties are governed by number of MNs in-session rather than longer term roaming population [4]. HARG defines the set of network nodes that need to be updated due to the MN handoffs. Identifying HARG enables localization of the routing update messages to avoid every router in the domain having to track the mobility of every MN. HARG has some unique characteristics in supporting mobility in this framework. First, the HARG members are "close" to where the handoff occurs because handoff is a local phenomenon that should affect only those routers near to the old and new APs. Second, the set of routers affected by a MN handoff from an APa to an APb is the same as the set of router affected by MN handoffs from the APb to the APa. Third, the set of affected routers is static if there is no change in the network topology. Furthermore, HARG membership can be determined at the network boot- up time and it may change when there is a topology change in the access network. The local mobility management framework does not track the out of session MNs, which is instead left to reachability discovery services. The host specific routing enables the MN to continue to use the acquired address in-session instead of updating it at each new Li Informational-Expires January 2002 5 Local Mobility Management Framework July, 2001 access router as required by normal Mobile IP [2,3]. Similarly, the mobile routing protocol is limited to tracking intra-domain mobility and relies on macro mobility management protocol (e.g. Mobile IP) to handle inter-domain handoffs. 4.4 Handoff control mechanism In this framework, we assume a standardized handoff trigger will initiate the handoff process. This trigger provides the address information about the MN's old and new APs. With the identified HARG, the handoff control algorithms only need to update the forwarding states for a handoff MN at the HARG members. As the HARG members are "close" to the APs where the handoff occurs, the handoff related signals are localized. The handoff control algorithms can signal the HARG members in different order and request certain behavior from different HARG members. For instance, if a handoff algorithm requires to extend the path from the old AP to the new one before switching at ARs inside the access network, it can first signal the ARs in the HARG for establishing path extension and then signal the ARs in HARG when the stable layer 3 connectivity at the new AP has been established for the handoff MN. The capability of HARG members can be reported to the AP such that the handoff algorithm can program the MARs to achieve desired handoff performance. The examples of HARG member's capabilities may include tunneling, buffering, multicast, QoS, etc. 5 Realization of the local mobility management framework This section discusses a potential implementation of LMM based on the proposed framework. The functional components of the framework are identified in Figure 2. In the access port, the LMM client performs the HARG member discovery, handoff coordination, and layer 2 interactions. The IP/layer2 mapping performs translation between IP packets and layer 2 radio frames and may provide handoff triggers to the LMM client. Both LMM server and routing protocol reside in the control plane of the AR. The routing protocol could be any IGP protocol (e.g., OSPF or RIP) that is used to support routing for fixed nodes in the access network. The LMM server maintains the hosting router's membership state in HARGs, re-directs IP flows towards MN's current point of attachment and injects host specific routing entries in the forwarding engine. There are three LMM specific interfaces among the functional entities in Figure 2. The interface I1 can be used for conveying layer-2 handoff trigger to the LMM client. The interface I2 is for exchanging HARG membership management and the handoff control messages between the LMM clients and servers. The interface I3 is for LMM server to control the forwarding engine of the hosting router to re-direct forwarding paths with required behaviors. Li Informational-Expires January 2002 6 Local Mobility Management Framework July, 2001 +-----------------------------+ +-----------------------------+ | | | | | +---------+ | | +---------+ +---------+ | | | | | I2 | | | | | | | | LMM <--+------+--> LMM | | Routing | | | | Client | | | | Server | | protocol| | | | | | | | | | | | | +---+-----+ | | +-----+---+ +---+-----+ | | | | | | | | | I1 | | | |I3 | | | +--------------+---+ | | +--+-----------+---+ | | | | | | | | | | | IP/Layer2 +=================+ forwarding | | | | mapping | | | | engine | | | +------------------+ | | +------------------+ | | | | | | Access port | | AR | +-----------------------------+ +-----------------------------+ Figure 2 LMM functional entities The rest of this section describes a LMM protocol suite over interface I2 that realizes the defined LMM framework. The LMM protocol suite includes three protocols namely Handoff Affected Router Discovery Protocol (HARDP), Mobile Registration Protocol (MRP), and Handoff Control Protocol (HCP). The HARDP identifies a set of MARs that needs to update their forwarding state for any MN handoff between APs. The MRP handles the initial message exchange for a MN to gain access to the access network. It establishes initial forwarding state for the registered MNs at all the MARs of an access network. The HCP is responsible for signaling the MARs to update the forwarding state for the handoff MNs. 5.1 Handoff affected router discovery protocol (HARDP) HARG[a, b] is the set of routers that will be affected by the mobile handoff between APa and APb. Routers in HARG[a, b] have different next hop forwarding paths to APa and APb. HARDP uses this characteristic of the routers to determine the membership of HARG[a, b] and the HARG members join/leave the HARG using Internet Group Management Protocol (IGMP) The HARGs are determined using HARDP at network boot-up time and membership in a HARG remains static unless there is a change in network topology. Li Informational-Expires January 2002 7 Local Mobility Management Framework July, 2001 5.2 Mobile Registration Process The Mobile Registration Protocol handles the initial message exchange for a mobile to gain access to the network. The main function performed by the protocol is to provide IP connectivity for the mobile. A mobile can attach to the access network voluntarily or in response to a request from correspondent nodes. The voluntary attachment is the situation when a mobile user wants to communicate with others while the on request attachment is the situation that other correspondent nodes want to communicate with the user. When a correspondent node wants to reach the mobile user, it can use reachability discovery service to request the mobile to attach to the network. Regardless how a MN is initiated to attach to the network, it has to obtain a routable IP address and register this new address with its identity to the reachability discovery services that the mobile user is willing to expose his reachability. A mobile can obtain its IP address through either stateful DHCP allocation or stateless auto-configuration. Within the AN, local reachability for the mobile is implicitly established by the routing protocol of the access network. MN is also required to register its newly assigned IP address to the reachability discovery service for establishing global reachability. A MN can use Mobile IP or other reachability discovery services (e.g. DNS, SIP) for global reachability. 5.3 Handoff Control Protocol (HCP) The HCP assumes that HARDP has already been executed to identify the HARGs. The group of routers in the HARG needs to be informed about the handoff since each node needs to update its forwarding table to reflect a new "IP address to next-hop router" mapping. The following described handoff control protocol assumes the HARGs are multicast groups and the HCP uses a multicast protocol to signal the members in the HARGs for updating their forwarding state. This HCP uses a simple handoff control algorithm that is updating all the MARs in the HARG at the same time. It is obvious that more sophisticated handoff control algorithms can be developed. Consider a MN, which is attached to APa and then moves to APb. During the handoff, a LOCATION_UPDATE message is multicast by APb to the HARG[a, b] which includes the 3-tuple, . APb may obtain the sequence number of the handoff message from the MN where it is incremented each time a handoff is executed, or APb may generate the sequence number using a network synchronized timestamp such as GPS. Routers use the sequence number to ensure that the update from a later location update message is not overwritten by an update from an earlier location update message that got delayed in the network. Each MAR that receives the message executes its route update algorithm to indicate that packets destined for the MN are to be forwarded towards APb. Li Informational-Expires January 2002 8 Local Mobility Management Framework July, 2001 6 Discussions This section discusses the instantiations of the LMM framework in typical overlay network topologies that are used in existing local mobility management approaches. Various topology specific LMM proposals have been made to IETF MIP working group in last two years. These proposals require the MARs to form an overlay network on top of the access network infrastructure. The typical overlay network topologies are star in flat HMIP [5], tree in regional registration [6], and chain in Fast Handoff [8]. These proposals have the same function in term of updating forwarding state at MARs that is re-directing tunnels towards the new attachment point of the handoff MN. The key difference among these proposals is the updating of topology specific HARG members. The HARG membership is configured statically in these proposals such that the handoff control algorithm can update forwarding state at the right MARs. The fundamental problem of developing topology specific protocols is the limited scope of each individual protocol and results in overwhelming number of protocols that have the similar capability. Furthermore, this approach will impose topological restriction on the MAR deployment. The rest of this section will demonstrate that the proposed LMM framework is a more generic framework that is capable of handling route re-direction in different overlay network topology. For simplicity, the following examples of network topology assume that each AR connects to only one AP such that handoffs between APs can be considered as handoffs between the respective ARs. 6.1 Star topology The MARs are connected into a star topology in Figure 3. The handoffs between AR1 and AR2 will affect three MARs: AR1, AR2, AR5. Therefore, the HARG[AR1, AR2] = {AR1, AR2, AR5}. The routes for a MN handoff between AR1 and AR2 should be re-directed in these three nodes. One example of handoff control algorithm could be that the LMM client at the AR2 signals the HARG[AR1, AR2] members to request path re-direction. The route re-direction operation at the AR5 is considered as a path switching while the operation in AR1 is a path extension. Another example of the algorithm could be that the LMM client signals only the AR5 for path re-direction and this results in a path switching at the AR5 without requiring a path extension at AR1. The two example handoff control algorithms may result in different handoff performance (e.g., packet loss). Network operators should have the options to select handoff control algorithms that suit for their needs. Li Informational-Expires January 2002 9 Local Mobility Management Framework July, 2001 +---+ |AR1|----- +---+ \ | \ | \ +---+ +-----+ +---+ |AR4|------| AR5 |-------|AR2| +---+ +-----+ +---+ | | +---+ |AR3| +---+ Figure 3. Star topology 6.2 Tree topology The MARs are connected into a tree topology in Figure 4. There are tunnels between adjacent ARs that have APs (i.e., AR1, AR2, AR3). In this configuration, HARG[AR1, AR2] = {AR1, AR2, AR4}. The handoffs between AR1 and AR2 may require path re-direction at these three nodes. Assume the handoff control algorithm requires updating all the HARG members at the same time, the route re-direction operation at AR4 is a path switching while the operation in AR1 is a path extension. The HARG[AR2, AR3] = {AR2, AR3, AR4, AR5, AR6}. If the access network uses the same handoff control algorithm, the route re-direction operations at AR4, AR5, and AR6 are path switching operations and the operation at AR2 is a path extension. +----+ | AR6| +----+ / \ / \ / \ +----+ +----+ | AR4| | AR5| +----+ +----+ / \ \ / \ \ / \ \ +---+ +---+ +---+ |AR1|-----|AR2|-----|AR3| +---+ +---+ +---+ Figure 4. Tree topology Li Informational-Expires January 2002 10 Local Mobility Management Framework July, 2001 6.3 Chain topology The MARs are connected into a chain topology in figure 5 where only the ARs with AP interfaces are MARs in this access network configuration. A HARG always includes the neighboring ARs as the members. In figure 5, HARG[AR1, AR2] = {AR1, AR2}. When a MN handoff from AR1 to AR2, the location update signals for HARG members will result in a path extension from AR1 to AR2 for the MN +---+ +---+ +---+ |AR1|-----|AR2|-----|AR3| +---+ +---+ +---+ Figure 5. Chain topology 7 Security Considerations TBD. 8 Intellectual property rights Nortel Networks has pending patent applications that may be relevant to this internet-draft. If this specification is adopted by IETF and any claims of this patent are necessary for practicing this standard, any party will be able to obtain a license from Nortel Networks to use any such patent claims under openly specified, reasonable, non-discriminatory terms to implement and fully comply with the standard. 9 Summary This draft proposed a generic framework for local mobility management that unifies the route re-direction signals and allows the handoff control algorithm to coordinate the handoff related activities to achieve desired outcomes. This framework introduces the concept of Handoff Affected Router Group (HARG) that identifies the set of local routers to be signaled when a handoff occurs between APs. With HARG, the framework enables localized and programmable signaling in handoff process. Host specific routing technology may be used to support mobility in this framework that allows a mobile node to keep its locally allocated IP address as long as it moves within the LMM network domain, and therefore, reduce the amount of signals to the correspondent nodes. This framework enables the distribution of the MN forwarding states over the network nodes and avoids creating traffic and signalling concentration points and therefore eliminates single point of failure. Li Informational-Expires January 2002 11 Local Mobility Management Framework July, 2001 The instantiations of the LMM framework for the typical overlay network topologies demonstrate that the proposed LMM framework is a more generic framework that is capable of handling mobility management in different network environment 10 Acknowledgments Special gratitude to Bill Gage, Muhammad Jaseemuddin, Gary Kenward, Yusupha Touray for reviewing the document and providing valuable suggestions for improving this framework. 11 References [1] Hongyi Li, et.al., ''Mobile Routing for Large Scale Wireless Internet,'' in Mobile Computing and Communication Review, vol. 4, No.4, pp. 36-44, 2000. [2] C. Perkins, "IP Mobility Support for IPv4, revised," IETF Draft, Sept. 2000, http://www.ietf.org/internet-drafts/draft-ietf-mobileip- rfc2002-bis-03.txt (working in progress). [3] David B. Johnson, Charles Perkins, " Mobility Support in IPv6," IETF Draft, April 2000, http://www.ietf.org/internet-drafts/draft-ietf- mobileip-ipv6-12.txt, (working in progress). [4] A. O'Neill and Hongyi Li, "Host Specific Routing," IETF Draft, Working in Progress, Nov. 2000. http://search.ietf.org/internet- drafts/draft-oneill-li-hsr-00.txt, (working in progress). [5] Karim El Malki, Hesham Soliman, "Hierarchical Mobile IPv4/v6 and Fast Handoffs" IETF Draft: http://search.ietf.org/internet-drafts/draft- elmalki-soliman-hmipv4v6-00.txt, March 10, 2000, (working in progress). [6] Eva Gustafsson, Annika Jonsson, Charles E. Perkins, "Mobile IP Regional Registration", IETF DRAFT: http://search.ietf.org/internet- drafts/draft-ietf-mobileip-reg-tunnel-03.txt, July 2000, (working in progress). [7] A. Snoeren, et.al, "Reconsidering Internet Mobility," in Proc. 8th workshop on hot topics in operating systems, 2000. [8] G. Tsirtsis, "Fast Handoffs for Mobile IPv6," IETF draft, http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6- 01.txt, April, 2001, (working in progress). [9] J. Loughney, et.al., "SeaMoby Micro Mobility Problem Statement," Internet Draft, Feb. 2001, http://search.ietf.org/internet- drafts/draft-ietf-seamoby-mm-problem-01.txt, (working in progress). 12 Authors' Addresses Li Informational-Expires January 2002 12 Local Mobility Management Framework July, 2001 Hongyi Li Nortel Networks 3500 Carling Ave. Ottawa, Ontario Canada K2H 8E9 Phone: 613-763-5966 Email: hyli@nortelnetworks.com Li Informational-Expires January 2002 13