IETF Mobile IP Working Group Kyungjoo Suh INTERNET DRAFT February 2003 Regional Mobile IPv6 mobility management draft-suh-mobileip-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. 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 August 2003 [Page 1] Internet Draft Regional Mobile IPv6 mobility management February 2003 Table of Contents 1. Introduction ......................................................2 2. Terminology .......................................................3 3. Overview of RMM/RMIPv6 ............................................4 4. RMM/RMIPv6 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. RAP vs MAP Appendix B: Routing cost function ....................................9 B.1 Definition of Routing Cost Function B.2 Example: Hop based Routing Cost Function 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. The proposed protocol simplifies the network design and there is no assumption on the network architectures which consist of routers, including the access router (AR). 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 August 2003 [Page 2] Internet Draft Regional Mobile IPv6 mobility management February 2003 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 term í—RMMí˜ is used to distinguish it from LMM, because the LMM is currently requirements and RMM is a mechanism or protocol that satisfies the requirements of LMM. And, the term í—RMIPv6í˜ is also used to distinguish it from HMIPv6. 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). RAP is distinguished from MAP because the ways RAP is selected and involved in protocol action are different from that of MAP. 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. On-Link Care-of Address (LCoA) The LCoA defined here is configured on a mobile node's interface based on the access routerí¯s advertised prefix. Suh Expires August 2003 [Page 3] Internet Draft Regional Mobile IPv6 mobility management February 2003 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 when receiving the MAP option. 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 routing 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 topology of a network, 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 Mobile Node can be determined by MN or RAP. In other words, the path is controllable or configurable. The forwarding path can be dynamically determined either by MNs (mobile determined mechanism) or RAPs themselves (network determined mechanism). Before an MN intends to use an AR (previously visited AR) as its RAP, the MN may perform the forwarding path cost measurement, in other words distance measurement. To measure the forwarding path cost, two kinds of control messages are defined: distance measurement request message and distance measurement acknowledgement message (a reply control packet). A distance measurement acknowledgement message contains a field called status, which contains ACK or NACK value indicating whether the forwarding cost is acceptable or not. MN may send a control packet to measure the forwarding path cost. When RAP (or AR) receives the packet, RAP should send a reply control packet containing the ACK in its status field. If RAP Suh Expires August 2003 [Page 4] Internet Draft Regional Mobile IPv6 mobility management February 2003 determines that the forwarding path cost is higher than its threshold (may be administratively configured or dynamically determined by some algorithm), it sends a NACK reply control packet which indicates that RAP cannot serve the MN for cost reason. If RAP determines the forwarding path cost is acceptable, it sends an ACK reply control packet indicating its willingness to serve MN. Note that the decision is made by RAP (network determined mechanism). When MN receives a reply control packet, it should check the status field. When the status filed indicates NACK, MN cannot use the AR (or RAP) as its RAP. When the status filed is ACK, MN can decide whether the AR (or RAP) can be used as its RAP based on the contents of the reply control packet. Even if MN is allowed to use the AR as its RAP, MN can decide again with its own cost threshold (mobile determined). The cost threshold of AR and MN may differ and it can be manually configured or dynamically controlled by some algorithm. A typical algorithm of MN (or AR) may use its current status such as traffic characteristics, current service rate, and bandwidth usage. 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. 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. Suh Expires August 2003 [Page 5] Internet Draft Regional Mobile IPv6 mobility management February 2003 +-------+ | 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. 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 in 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. Suh Expires August 2003 [Page 6] Internet Draft Regional Mobile IPv6 mobility management February 2003 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. 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 LCoA is configured on a mobile node's interface based on the access routerí¯s advertised prefix. 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. Suh Expires August 2003 [Page 7] Internet Draft Regional Mobile IPv6 mobility management February 2003 4.2. Regional Anchor Point Operation Within a certain region RAP can be an anchoring point and it performs a packet forwarding service for a MN. In RMM/RMIPv6 any AR supporting RAP functionality can be a RAP. The RAP selected by each MN may differ. Thus, if there are a lot of ARs that supports the RAP functionality, the RAP for each MN may be distributed over the network which prevents the RAP becoming a single point of failure or a bottle neck in 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 lifetime expires or when the Mobile Node sets the lifetime=0 and sends binding updates to that 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. 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. Suh Expires August 2003 [Page 8] Internet Draft Regional Mobile IPv6 mobility management February 2003 [2] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, Internet Engineering Task Force. draft-ietf-mobileip-ipv6-20, July 2003. [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 author: 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, kjsuhuf@yahoo.com Fax: +82-31-279-5130 Appendix A: Comparison with HMIPv6 A.1. Address Configuration In the hierarchical MIPv6, 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 obtain the RCoA can cause overhead. In contrast, in this document, 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. Suh Expires August 2003 [Page 9] Internet Draft Regional Mobile IPv6 mobility management February 2003 A.2. RAP vs MAP In the HMIPv6, the process of MAP discovery is dynamic MAP discovery or using route renumbering methods. The MAP option must be propagated from MAP to leaf AR. In the case of HMIPv6, after acquisition of RCoA there is the process of Duplicate Address Detection (DAD) by the MAP. In RMIPv6, there is no discovery process for discovering a RAP, which causes the simplicity of protocol as well as no need of preconfiguration of network design for propagation of anchoring point information. In this document, the anchor point information is advertised through one hop advertisement. The MN selects a proper RAP depending on the history of MNí¯s handoff. To find out an appropriate RAP the distance limitation is mentioned. Moreover, 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: Routing Cost Function B.1 Definition of Routing cost function The routing cost function may be defined following: Cost = Function of (Hop Count, Reliability, Bandwidth, Delay) The cost function consists of metric factors for Mobile IP, which are Hop Count, Reliability, bandwidth, and Delay. Each of these factors must satisfy following conditions because of selecting more optimized link: Hop Count () < Hop count Constraint Reliability () > Reliability Constraint Bandwidth () > Bandwidth Constraint Delay () < Delay Constraint B.2 Example: Hop based routing cost function The useful example of routing cost function is Hop Based Routing Cost Function. To measure hop count there are three possible methods: First, MN figures out the hop count. Second, RAP figures out the hop count. In this case, the path can be different from the path from RAP to MN. However, due to assumption of bidirectional path it can be ignorable to measure the path length from MN to RAP. Last, the hybrid method can be used to measure the hop count. For distance measurement, distance measurement request message and distance measurement acknowledgement message are defined. For these two messages, mobility header and special mobility options, i.e. initial hop limit option and distance data option, are used. Suh Expires August 2003 [Page 10]