IETF MIPSHOP Working Group Internet Draft Youngjun Park Kyungjoo Suh Jaekwon Oh Eun-Hui Bae Document: draft-park-mipshop-nhmds-00.txt Samsung Electronics Expires: May 2004 November 2003 Non-hierarchical MAP Discovery and Selection in HMIPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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 memo introduces a MAP (Mobility Anchor Point) discovery and selection procedure for HMIPv6 (Hierarchical Mobile IPv6). A MAP discovery method is defined in order to expand the coverage of the MAP from a hierarchical domain to the whole foreign network. Subsequent MAP selection algorithm enables to locate MAP on the highest level of hierarchical structure. Addressed method is beneficial not only for the performance of localized mobility management but also for the location privacy. Conventions used in this document 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 RFC-2119 [ii]. Park, et al Expires - May 2004 [Page 1] MAP discovery and selection in HMIPv6 November 2003 1. Introduction HMIPv6 is suggested to reduce signalling overhead of MIPv6. By introducing a MAP as the local mobility agent, overhead incurred by binding updates to home agent and correspondent nodes can be decreased. In HMIPv6, a dynamic MAP discovery and a MAP discovery are addressed as MAP discovery algorithm [vi]. Alternative MAP discovery algorithm and MAP selection criteria are introduced in this memo. Suggested algorithms can select the closest MAP on the highest level of the hierarchy. 2. Overview In HMIPv6, a mobile node must carry out registration to home agent and correspondent node whenever it changes a MAP. It suffers same signalling overhead whenever it moves from non-HMIPv6 supported domain to a MAP domain. Accordingly the performance of HMIPv6 is determined by the time a mobile node can be served by a single MAP continuously. A mobile node can use HMIPv6 when it can locate MAP at the visited network. MAP discovery is the process by which mobile node can find the remote MAP. MAPs and routers are in charge of MAP discovery. Each MAP propagates its MAP option to the neighbor routers and each router distributes received MAP options to other routers. The coverage of MAP is determined by the MAP option propagation method. If the MAP options are propagated through router hierarchy like dynamic MAP discovery, MAP domain is bounded within the routers on the lower level of MAP. If MAP options are distributed to the whole visited network, all the mobile nodes at the visited network can be covered even by a single MAP. In this memo, two values are defined to indicate the location of MAPs. "Distance" value determines the logical distance between MAP and mobile node. "Upward" value determines the relative height of mobile node to the MAP. These values are modified whenever a router receives the MAP option. The modified values are determined according to the propagating direction. When the MAP option is sent from the routers reside on the higher level, "Distance" value increases. If it is sent from the lower level routers, both "Distance" and "Upward" values increase as depicted by figure 1. Park, et al Expires - May 2004 [Page 2] MAP discovery and selection in HMIPv6 November 2003 | | From the higher level router v +-----------+ | | Increase Distance by one | Router | | | Increase Distance by one +-----------+ Increase Upward by two ^ | From the lower level router | Figure 1: MAP discovery Upon reception of MAP option, mobile node must select one MAP to perform local binding update. Basic criterion of MAP selection in this memo is to select the closest MAP on the highest level. To avoid signalling overhead due to frequent MAP change, a mobile node selects MAP located on the highest level. If a MAP locates on a higher level, it locates further from the mobile node. Therefore, the "Distance" field received by mobile node has larger value. Moreover, if a MAP locates on higher level, its MAP options propagate downward from higher level. Therefore, the "Upward" field has smaller value. The mobile node selects MAP located on the highest level by finding MAP which has largest "Distance" value and smallest "Upward" value. To reduce local binding update latency, mobile node selects the closest MAP when two or more MAPs are located on the same highest level. If a MAP locates close to the mobile node, "Distance" value is smaller. Thus the mobile node chooses the MAP with smallest "Distance" among the MAPs on the same highest level. By the approach in this memo, mobile node always can be served by the MAP on the highest level. Thus this algorithm guarantees best performance in location privacy. Park, et al Expires - May 2004 [Page 3] MAP discovery and selection in HMIPv6 November 2003 3. MAP Discovery and Selection 3.1 MAP Operations 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Dist | Pref |R|I|P|V| Upward| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: New MAP option message format Fields: Upward A 4 bit unsigned integer indicating the number of times MAP option has been forwarded to a higher level router. When a router receives a MAP option sent from the lower level, it increase "Upward" by two before distributing MAP option to other routers. The basic process of a MAP is similar to that of dynamic MAP discovery method described in HMIPv6 [vi]. MAP serves as the local home agent for mobile nodes in a visited network. To announce essential information for local binding update such as subnet prefix, MAP generates and propagates MAP options in the router advertisement. All MAPs must be configured so that they can send its MAP option onto all the interfaces. No manually configured hierarchical forwarding path is needed. "Distance" field has default initial value one for all MAPs. This field indicates the logical distance between the MAP and mobile node. Thus, Distance value increases by one whenever the MAP option passes a router. Park, et al Expires - May 2004 [Page 4] MAP discovery and selection in HMIPv6 November 2003 "Upward" field has default initial value zero for all MAPs. This field indicates the relative height of the mobile node to the MAP in the hierarchy. Upward value increases by two whenever the MAP option is delivered upward from the lower level router to the higher level router. "Preference" field may be configured by operators and can be changed by policy or performance based decisions. Definition and usage of other fields including R, I, P, and V flags are identical with the description of HMIPv6. After propagating its MAP option in router advertisement, MAP waits for a mobile node to send local binding update. Upon reception of local binding update, MAP checks validity of remaining lifetime of RCoA provided by the mobile node. If the local binding update is acceptable, MAP sends binding acknowledgement to the mobile node including type 2 routing header with the RCoA. 3.2 Router Operations Upon receiving router advertisement including MAP option, a router inspects the list of MAP options included in the advertisement. The router must check whether newly received MAP option is duplicated one. If "Global IP address for MAP" field of newly received MAP option is identical with the MAP option received before, two MAP options are duplicated. Identical MAP options may have different propagation paths because they are distributed via all the interfaces of all the routers. In this case, two MAP options from same MAP may have different "Distance" or "Upward" values. In addition, "Preference" value may be changes by network operators by the policy or performance reason. Thus duplicated MAP options may have different values. The Router checks if two options have same "Distance", "Upward", and "Preference" values. The router computes the difference between "Distance" and "Upward" for all the duplicated MAP options and accepts the MAP option which has smallest difference. After accepting a unique MAP option for a MAP, the router examines which router sent the MAP option. A router changes the values of "Distance" and "Upward" and retransmits MAP option via all the interfaces. The modifications of these values are classified into three cases: 1. If the MAP option is sent from the routers on the higher levels, then the router must increase "Distance" value by one. Park, et al Expires - May 2004 [Page 5] MAP discovery and selection in HMIPv6 November 2003 2. If the MAP option is sent from the routers on the lower level, then the router must increase both "Distance" value by one and "Upward" value by two. 3. If the MAP option is sent from the router on the same level, then the router must not modify any value in the MAP option. If the router can not determine the level of router from which MAP option is sent, the received router must not change any value in the MAP option. A router sends MAP option in its router advertisement after it adjusts "Distance" and "Upward" values. 3.3 Mobile Node Operations After moving from an access router to new access router, mobile node listens for router advertisement. If received router advertisement contains information about new access router, mobile node can determine its movement and configures its LCoA by stateless or stateful address autoconfiguration [iii]. If no router advertisement has been received, a mobile node can send router solicitation to new access router in order to invoke router advertisement [v]. Mobile node inspects the MAP option extension included in the router advertisement. If either "Distance" field or "Upward" field of previous MAP has changed, the mobile node determines that it may change MAP. If previous MAP does not exist in the list of MAPs mobile node received, mobile node decides to select new MAP. MAP selection procedure of mobile node has three steps. First, mobile node tries to find the MAP located on the highest level. Second, mobile node tries to find the closest MAP if two or more MAPs are selected in the previous step. Last, mobile node selects possible previous MAP or random MAP in the case more than one MAP are selected in the second step. To find the MAP located on the highest level, mobile node estimates the level of each Map. The level of MAP can be defined as the difference between "Distance" and "Upward" value as described in the section 2. Mobile node arranges MAPs in descendent order of difference and selects the MAP which has largest difference. If two or more MAPs have the largest difference in common, the mobile node arranges these MAPs in ascending order of "Distance". The mobile node selects one has smallest "Distance" value among these MAPs. Park, et al Expires - May 2004 [Page 6] MAP discovery and selection in HMIPv6 November 2003 If more than one MAP still remain as candidates after above two steps, mobile node tries to select the previous MAP where it already has local binding. Selecting previous MAP well meets the context of MAP selection because mobile node should be lazy in releasing existing binding [vi]. But, if previous MAP doesn't exist in the lists of MAPs, mobile node chooses random MAP from remaining candidates. For all of above cases, mobile node must confirm that "Preference" value of selected MAP is not zero. After selecting new MAP, mobile node must perform local binding update. If selected MAP is previous one, mobile node must perform local binding update to the previous MAP by using new LCoA and old RCoA. Binding update to neither home agent nor correspondent node is needed when previous MAP is reselected. Otherwise, the mobile node must configure new RCoA by using prefix extracted from the MAP option. Mobile node must perform local binding update to the new MAP by using new LCoA and new RCoA. Upon granting binding acknowledgement, mobile node sends binding update to home agent and to correspondent node respectively. 4. Compatibility Considerations The MAP option addressed in this memo is completely compatible with HMIPv6. The "Upward" field is the last four bits of fourth octet and these bits are defined as "Reserved" in HMIPv6 [vi]. Other fields have the same meaning and value with those of the MAP option used in dynamic MAP discovery. When a HMIPv6 mobile node gets a connection to new access router, it will eventually receive the MAP option described in the section 3.1. If the mobile node is not capable of MAP selection described in the section 3.3, it will try to select the MAP as defined in dynamic MAP discovery and operate with appropriate MAP. Security Considerations A strong authentication is needed between MAPs and mobile nodes especially when mobile nodes have local bindings to remote MAPs. Detailed security problems will be considered in the next version of this memo. Park, et al Expires - May 2004 [Page 7] MAP discovery and selection in HMIPv6 November 2003 References [i] S. Brandner, "The Internet Standards Process - Revision 3", RFC 2026. [ii] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [iii] S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462. [iv] T. Narten, E. Nordmark and W. Simpson, "Neighbor Discovery for IP Version 6",RFC 2461. [v] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24. [vi] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier, "Hierarchical Mobile IPv6 mobility management", draft-ietf- mobileip-hmipv6-08. (work in progress) Author's Addresses Questions about this memo can be directed to: Youngjun Park Samsung Electronics Co., Ltd. Dong Suwon P.O.BOX 105 416 Maetan-3Dong, youngtong-Gu, Suwon-City, Gyeonggi-Do, Korea, 442-600 Email: youngjun74.park@samsung.com Kyungjoo Suh Email: joo.suh@samsung.com Jaekwon Oh Email: jaekwon.oh@samsung.com Eun-Hui Bae Email: eanny.bae@samsung.com Park, et al Expires - May 2004 [Page 8]