IETF Mobile IP Working Group Kyungjoo Suh INTERNET DRAFT Samsung October 2002 Regional Mobile IPv6 mobility management draft-suh-rmm-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 This document defines a new protocol, namely, Regional Mobile IPv6 mobility management (RMM/RMIPv6). RMM mechanism satisfies the LMM requirements while it is more flexible mobility management scheme than existing solution, for example HMIPv6. This document therefore describes methods to be used to reduce the amount of signaling to the Home Agent and Correspondent Nodes. In addition, this scheme is flexible enough to adapt to any network topology assumed by IPv6. The network that using RMM/RMIPv6 is robust against the failure or the performance degradation. The mechanism is intended to reuse the Care of Address. Moreover, the forwarding tunnel length from an anchor point to a Mobile Node can be a controllable or configurable. Suh Expires April 2003 [Page 1] Internet Draft Regional Mobile IPv6 mobility management October 2002 Table of Contents 1. Introduction ......................................................2 2. Terminology .......................................................3 3. Overview of RMM/RMIPv6 ............................................4 4. RMM/RMIPv6l Operation ............................................5 νννννννν4.1 Mobile Node Operation ....................................6 νννννννν4.2 Regional Anchor Point Operation .........................7 5. Interoperability with Fast Handoff ................................7 6. Security Considerations ...........................................8 Acknowledgements .....................................................8 References ...........................................................8 Author's Addresses ...................................................8 Appendix A: Comparison with HMIPv6 ...................................9 A.1. Address Configuration A.2. MAP vs RAP Appendix B: Forwarding Cost Function .................................9 1. Introduction In general, in the basic Mobile IP protocol[2], movement between two subnets and routing changes requires the mobile node must issue binding updates to its Home Agent and its Correspondent Nodes. This binding updates sent to the Home Agent and the Correspondent Nodes for route optimization can cause latency. This latency may cause some packets for the mobile node to be lost. Localized Mobility Management (LMM)[4] for Mobile IP is introduced to enhance Mobile IP to reduce the amount of latency in binding updates and amount of signaling over the Internet. The Hierarchical Mobile IPv6 mobility management (HMIPv6) [3] is suggested to reduce the amount of signaling to the Home Agent and the Correspondent Nodes. In addition, HMIPv6 may improve handoff speed of Mobile IPv6. This document describes a proposed protocol, Regional Mobile IPv6 mobility management (RMM/RMIPv6). This mechanism satisfies the LMM requirements while it is more flexible mobility management scheme than existing solution, for example HMIPv6. The motivation of designing the RMM/RMIPv6 is summarized as follows: - Reducing the signaling overhead resulted from the movement of MNs - Interoperable with Mobile IPv6 - No assumption on the network architectures - Simplify the network design - Reuse the CoA that was made by a MN previously, thus avoid the unnecessary delay obtaining the CoA (RCoA) - Avoid creating a single point of failure or a bottleneck for the performance Suh Expires April 2003 [Page 2] Internet Draft Regional Mobile IPv6 mobility management October 2002 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. Other terminology is used as defined in the basic Mobile IP specification [2]. In addition, new terms are defined below: Region In RMM/RMIPv6 the term "region" is used instead of the term "domain". Regional Mobility Management (RMM) Regional Mobility Management is a kind of Localized Mobility Management[4]. In [4] this is referred to as the method of restricting the signaling area. In this document, the RMM is used to distinguish it from the LMM, because the LMM is currently requirements and RMM is a concrete mechanism. Regional Anchor Point (RAP) The Regional Anchor Point is an access router located in the mobile node's visited domain. The RAP has the following functionality: RAP which is newly introduced here acts as a local Home Agent for the MN within a certain region. It reduces the amount of latency in binding updates sent to the Home Agent and the Correspondent Nodes and the amount of signaling when mobile node traverses within a local domain. In [3] there is a similar functional entity called Mobility Anchor Point (MAP) which is distinguished from RAP because of discovery process. future RAP (fRAP) The future RAP is the RAP which will be used as an RAP when the current RAP is not available or is not proper to use. current RAP (cRAP) The current RAP is the RAP which is used as a RAP currently. Therefore, the current RAP serves as a regional anchor point for the mobile node when a mobile node moves to a visited domain. Regional Care-of Address (RCoA) An RCoA is an address obtained by the mobile node as defined in [3] from the visited domain. However, in this document the obtaining method is different from the method in HMIPv6. It may be configured by obtaining the CoA which mobile node obtains from the previous RAP in a stateless or stateful manner. However, the RCoA in [3] is auto-configured by the mobile node or assigned to the MAP's interfaces. Suh Expires April 2003 [Page 3] Internet Draft Regional Mobile IPv6 mobility management October 2002 On-Link Care-of Address (LCoA) The LCoA defined here is similar to the LCoA in HMIPv6, except that the LCoA is obtained in a stateless or stateful method. 3. Overview of RMM/RMIPv6 This document defines Regional Mobile IPv6 mobility management (RMM/RMIPv6). In RMM/RMIPv6 the term "region" means "domain". The region is dynamically determined by MNs or Regional Anchor Points (RAP) based on forwarding cost function. The RAP serves as a local Home Agent, i.e. a local mobility anchor point, for the MN within a certain region. Any AR can be a RAP for a specific MN and the anchoring point for each MN may be different. Therefore, RAPs can be distributed over the network. This make the network using RMM/RMIPv6 to be robust against the failure or the performance degradation, since there is no single point of failure or bottleneck for packet forwarding. The mechanism defined in this document is intended to reduce the amount of signaling to Mobile Node's Home Agent and its Correspondent Nodes. Moreover, the protocol does not assume a certain network topology of Access Routers, for example hierarchical structure. As a result, the protocol is flexible enough to adapt to any network topology assumed by IPv6. The RMM mechanism is intended to reuse the Care of Address that was obtained by MN in the previous AR and make the AR (visited by MN) as a RAP for the MN. The forwarding path from a RAP to a MN can be a controllable or configurable, because the RAPs are dynamically determined by MNs (mobile determined region) or RAPs themselves (network determined region). In this mechanism, at first a mobile node must remember whether the current AR supports RAP service. After a mobile node hands off and if it wants to use the previous AR as a RAP, it must check cost function, for example distance limitation. RMM/RMIPv6 mechanism reuses the Care of Address that was obtained by MN in the previous AR, and it makes the AR (visited by MN) as a RAP for the MN. The reused Care of Address is utilized as a RCoA for the MN. The MN binds its current location with the RCoA. Within a RAP region, the RCoA does not change. The RAP serves as a local Home Agent for the MN within a certain region. Therefore, if the mobile node changes its current address within a region, it registers the new address to the RAP. In RMM/RMIPv6, if possible, within a certain region the previous AR visited by a MN becomes a RAP simply being an anchoring point and it performs packet forwarding service to the MN. Thus, if the RAP functionality is not required, MN can stop using RMM/RMIPv6 and revert back to the basic Mobile IPv6 protocol service. Suh Expires April 2003 [Page 4] Internet Draft Regional Mobile IPv6 mobility management October 2002 The RMM/RMIPv6 concept is a simple extension of smooth handoff mechanism of the Mobile IPv6 protocol. RMM/RMIpv6 is fully interoperable with Mobile IPv6 including Smooth Handoff and Fast Handoff.For the optimization of routing path in a certain network assumption, HMIPv6 and RMM/RMIPv6 can be used together. 4. RMM/RMIPv6 Operation Figure 1 illustrates a network architecture as an example of the use of RMM/RMIPv6. +-------+ | HA | +-------+ | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +---------+ | AR1(RAP)| +-------+ | |---------| AR2 | +---------+ +-------+ | | +-------+ +------------------------------| AR3 | +-------+ +----+ | MN | +----+ ------------> Movement Figure 1: Regional Mobile IPv6 Among ARs, an AR (AR1) which supports RAP functionality announces through Agent Advertisement that it can serve as a RAP. If MN wants to use a RAP at first, MN must remember the current AR(AR1) supports RAP service. Therefore, after MN hands off, if MN wants to use the previous AR(AR1) as a RAP, it must check two things which runs as follow: First, MN must check that the current AR(AR2) supports RAP. Second, MN must check distance limitation. Suh Expires April 2003 [Page 5] Internet Draft Regional Mobile IPv6 mobility management October 2002 According to the evaluation of the cost function(distance limitation), there are four categories of operation following: First, if the current AR(AR2) supports RAP functionality and it is located within distance limitation, the mobile node use the CoA which is obtained the previous AR(AR1) as a RCoA. The reuse the Care of Address reduces the overheads obtaining RCOA. Second, if the current AR supports RAP functionality and it is located out of distance limitation, the mobile node reverts back to the basic Mobile IPv6 protocol service. Third, if the current AR does not support RAP functionality and it is located within distance limitation, the mobile node use the CoA which is obtained the previous AR(AR1) as a RCoA. Last, if the current AR does not support RAP functionality and it is located out of distance limitation, MN stops using RMM/RMIPv6 and reverts back to the basic Mobile IPv6 protocol service as described in the draft of Mobile IP support[2]. When a mobile node depends on a RAP to maintain mobility locally, it may not have any modification of binding updates to either Home Agent or Correspondent Nodes. The method defined in this document allows a RAP to be used as the local agent of registration. The RAP that will act on these functions is part of the localized mobility management, and is typically identified within the visited domain. The protocol and messages in this document are intended to facilitate the operations which may occur between the mobile node, a RAP, a Home Agent, and Correspondent Nodes. However, the only message flows specified in this document are the binding update messages between the mobile node and the RAP, and binding update acknowledgement between the RAP and the mobile node. 4.1. Mobile Node Operation The mobile node must check if the current access router has a function of a RAP for the use of future, whenever the mobile node hands off from one access router to another access router. After MN hands off, if MN wants to use the previous AR as a RAP, it must check distance limitation. According to the evaluation of the cost function(distance limitation) and supportability of RAP function (at the previous AR), the MN's behaviors are categorized into two fold: First, the mobile node may reuse the CoA which was obtained by MN in the previous AR as a RCoA, if the distance from the previous RAP to the current access router can satisfy distance limitation. Second, the mobile node reverts back to the basic Mobile IPv6 protocol service, if the current AR is located out of distance limitation. Suh Expires April 2003 [Page 6] Internet Draft Regional Mobile IPv6 mobility management October 2002 The care of address configuration of mobile node is classified into two categories. First, for the RCoA the mobile node may reuse the CoA which is obtained by MN in the previous AR, if the distance limitation is satisfied and RAP functionality of previous AR is supported. Second, the method of obtaining the LCoA is the same as HMIPv6, except that it can be done in a stateless manner or stateful manner. A mobile node depends on a RAP to maintain a local mobility. A mobile node therefore must receive the binding update acknowledgement from the RAP, because the RAP is used as the local agent of registration. The mobile node reverts back to the basic Mobile IPv6 protocol service, if there is no binding update acknowledgement or it receives a binding update acknowledgement that contains the denial of RAP service for a certain reason from the RAP. 4.2. Regional Anchor Point Operation Within a certain region RAP is an anchoring point and it performs packet forwarding service to the MN. In RMM/RMIPv6 any AR can be a RAP for a specific MN and the anchoring point for each MN may be different. As a result, RAPs are distributed over the network. The following steps are performed on the RAP: 1. The RAP binds the RCoA and LCoA without Duplicate Address Detection procedure for the RCoA. There is no DAD procedure because the RCoA has been used as CoA by the MN before MN leaves the RAP (AR). 2. The RAP intercepts packets and tunnels them to mobile node's LCoA. 3. The RAP works for Mobile Node's deregistration process. The RAP releases the binding entry for the mobile node, when the Mobile Node sets the lifetime=0 and sends binding updates to the current RAP. 5. Interoperability with Fast Handoff The RMM/RMIPv6 protocol can be used with Smooth Handoff and/or Fast Handoff. In some case, forwarding tunnel of Smooth Handoff and/or Fast Handoff can be used for RMM/RMIPv6. In other words, RMM/RMIpv6 is fully interoperable with Mobile IPv6 including Smooth Handoff and Fast Handoff. Suh Expires April 2003 [Page 7] Internet Draft Regional Mobile IPv6 mobility management October 2002 6. Security Considerations The security considerations resulting from use of these extensions do not offer any higher level of security than what is already implicit in use of the security solutions in basic mobile node operation. Therefore, in the next version of this document will include appropriate level of security for Mobile IP entities, such as mobile node and Home Agent, to operate Mobile IP operations. Acknowledgement The author would like to thank Young-Joo Suh and Dong-Hee Kwon for their valuable feedback and comments on this draft. The author would also like to thank Kil-Suk Yang and Jae-Myung Jang for participating in the initial discussion. References [1] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineerifng Task Force, March 1997. [2] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-ipv6-18, June 2002. [3] H. Soliman, C. Castelluccia, K. El-Malki, L. Bellier. Hierachical MIPv6 mobility management (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-hmipv6-07.txt, October 2002. [4] C. Williams. Localized Mobility Management (work in progress), Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-lmm-requirements-02.txt, June 2002. Author's Addresses Questions about this document can be directed to the authors: Kyungjoo Suh (Joo Suh) Global Standards and Strategy team Telecommunication R & D Center Samsung Electronics Co., LTD. Suwon P.O. BOX 105, 416, Maetan-3dong, Paldal-gu, Suwon-city, Gyeonggi-do, 442-742 Korea Phone: +82-31-279-5123 Email: joo.suh@samsung.com Fax: +82-31-279-5130 Suh Expires April 2003 [Page 8] Internet Draft Regional Mobile IPv6 mobility management October 2002 Appendix A: Comparison with HMIPv6 A.1. Address Configuration In the hierarchical MIPv6, the LCoA must be obtained in a stateless manner. On the other hand, in the basic mode of operation, the mobile node configures the RCoA in a stateless manner from the combination of the MAP's subnet prefix and the mobile node's interface identifier. This kind of method to obtaining the RCoA can cause overhead. In the extended mode operation, the RCoA is obtained in the MAP option. In contrast, in this document, the LCoA can be obtained in a stateless manner or stateful manner. In addition, the method of obtaining the RCoA is quite different from that of HMIPv6. If the previous access router supports a RAP functionality and the mobile node wants to use the previous access router as a RAP, the mobile node use the CoA obtained in the previous access router as RcoA. Therefore, that CoA is already obtained in a stateless or stateful manner, and at this point the previous access router is called the current RAP. The mobile node may reuse the CoA which is obtained from the previous RAP, when the mobile node hands off from one router to another router (current access router to which the mobile node is currently attached), and if the distance from the previous RAP to the current access router can satisfy distance limitation. A.2. MAP vs RAP In the HMIPv6, the process of MAP discovery is dynamic MAP discovery or using route renumbering methods. In the case of basic mode of operation of HMIPv6, after acquisition of RCoA there is the process of Duplicate Address Detection (DAD) by the MAP. In this document to find out an appropriate RAP the distance limitation is mentioned, however, details of this function are currently out of scope of this memo and will be specified in next version of this document. On the other hand there is no DAD procedure because RCoA is obtained by using the CoA obtained when the mobile node connected to the previous RAP. Appendix B: Forwarding Cost Function The forwarding cost function may be defined following and described in detail in the next version: Cost = Function of (Delay, Hop Count, Reliability, Load) The useful example of forwarding cost function is Distance (hop) based Forwarding Cost Function. Suh Expires April 2003 [Page 9]