Internet Engineering Task Force Yi Xu INTERNET-DRAFT Henry C. J. Lee Vrizlynn L. L. Thing Institute for Infocomm Research 14 February 2003 Mobile Controlled Movement Tracking Local Mobility Agent Selection for Mobile IPv6 Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 introduces a Local Mobility Agent selection algorithm in the Localized Mobility Management of Mobile IPv6. This proposed selection algorithm locates a Local Mobility Agent to register a visiting mobile node in a foreign domain where multiple Local Mobility Agents are deployed. The domain architecture, Local Mobility Agent selection and registration procedures are specified. This algorithm selects Local Mobility Agent on a per mobile node basis and reduces registration delay. It also helps to distribute the registration load to all the Local Mobility Agents, avoiding overcrowding at a particular one. Xu, Lee, Thing Expires 14 August 2003 [Page i] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 Contents Status of This Memo i Abstract i 1 Introduction........................................................1 2 Terminology.........................................................1 3 Overview of Mobile Controlled Movement Tracking Local Mobility Agent Selection................................................2 4 Message Format and Conceptual Data Structures.......................3 4.1 LMA Advertisement Option.......................................3 4.2 Conceptual Data Structures.....................................5 4.3 Modification to Mobile IPv6 Binding Update.....................6 5 LMA Tree Construction and Maintenance...............................6 5.1 Establishing LMA Tree Hierarchy................................6 5.2 Maintaining LMA Tree Hierarchy.................................7 6 LMA Selection and Registration......................................8 6.1 LMA Selection..................................................8 6.1.1 Default Selection.......................................8 6.1.2 Selecting a Nearer LMA..................................8 6.1.3 Selecting a Peer LMA....................................9 6.1.4 Selecting a Non-Peer LMA................................9 6.2 LMA Registration..............................................10 6.2.1 Registration at Home Agent and Correspondent Nodes.....10 6.2.2 Registration at Serving LMA............................10 6.2.3 Registration at Previous LMA...........................10 6.2.4 Data Packet Forwarding.................................11 7 Coexistence of Various LMA Selection Modes.........................11 8 Security Considerations............................................11 8.1 Binding Updates to Home Agents................................11 8.2 Binding Updates to Correspondent Nodes........................12 8.3 Binding Updates to Local Mobility Agents......................12 9 References.........................................................12 10 Authors' Addresses................................................13 Xu, Lee, Thing Expires 14 August 2003 [Page ii] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 1 Introduction To provide support for real-time services for mobile users, strict delay and packet loss requierments are demanded. The Mobile IPv6 [1] protocol enables ubiquitous accessibility to mobile node, but it does not address the registration delay and packet loss issues satisfactorily. In Mobile IPv6 protocol, it is not differentiated between macro-mobility and micro-mobility, so that each handoff of mobile node triggers a new registration process by sending binding updates to the home agent and the correspondent node. In addition to the long disruption in the IP layer connection at the new location, these binding updates also impose considerable bandwidth expense in the Internet. The Localized Mobility Management (LMM) [2] is introduced to reduce the registration delay for intra-domain handoff and relieve the network signalling load. By deploying Local Mobility Agent (LMA) in a domain, the location update at the home agent and correspondent nodes is proxied by LMA on behalf of the mobile node. For any intra- domain handoff, the mobile node only needs to update the LMA with its present address, while its home agent and correspondent nodes, which are usually much further away than the LMA, are not necessarily informed of this new address. Apparently, the LMM scheme supports real-time applications better than the Mobile IP protocol alone. For redundancy and load sharing purposes, multiple LMAs can be deployed in one domain, but it is recommended that a mobile node selects not more than one LMA [3]. This document specifies a LMA selection algorithm and its procedures. Up to the particular mobility pattern of mobile node, this selection algorithm is likely to reduce registration delay further than the present LMM scheme alone. This new algorithm also comes alone with potential load balancing benefits. 2 Terminology The keywords "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 [4]. This document also uses the terminology described in [1], [2] and [3]. Local Mobility Agent (LMA) A Local Mobility Agent functions as a Home Agent in the domain visited by the Mobile Node. The LMA proxies address update of the Mobile Node outside of the domain. Gateway Local Mobility Agent (GLMA) Xu, Lee, Thing Expires 14 August 2003 [Page 1] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 A domain gateway acting as a Local Mobility Agent. Serving Local Mobility Agent (SLMA) The LMA that currently proxies the Mobile Node. Previous Local Mobility Agent (PLMA) The LMA that has been previously serving the Mobile Node immediately before the current one. Visited Domain An administrative domain, where the Mobile Node has moved to. Global Care-of Address (GCoA) Global IP address of the Local Mobility Agent selected by the Mobile Node. This Care-of Address is used for registering with the Mobile Node's Home Agent. Local Care-of Address (LCoA) A new IP address acquired by Mobile Node when it connects to a router in the Visited Domain. This Care-of Address is used for registering with the selected Local Mobility Agent. 3 Overview of Mobile Controlled Movement Tracking Local Mobility Agent Selection The proposed Mobile Controlled Movement Tracking (MCMT) Local Mobility Agent selection algorithm consists of two steps. The first one is to organize the LMAs inside a domain into hierarchy and propagate the relevant hierarchy information to the Mobile Node. The second step is to make a selection decision based on the information received by the Mobile Node. The LMA hierarchy establishment is carried out at the initialization phase when the LMAs are first deployed. If there is no network topology change, the LMA hierarchy will remain the same all the time. If some topology changes happen, such as node failure or link disruption, the LMA hierarchy will adapt to such changes by means of a maintenance mechanism. The LMA hierarchy construction and maintenance procedures are independent of the number of Mobile Nodes in the domain, thus the scalability issue should not be a concern. The Mobile Node obtains the LMA hierarchy information from the access router that it is attached to. This information is location dependent and it is a branch of the entire hierarchy. When the Mobile Node moves around, it will receive a collection of different hierarchy branches, that can be intepreted as a movement pattern Xu, Lee, Thing Expires 14 August 2003 [Page 2] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 indicator. The Mobile Node compares these branches to find out a nearby LMA that covers its mobility scope. Compared to the furthest LMA selection seen in [3], this selection takes movement characteristics of the Mobile Node into consideration. Therefore, for those Mobile Nodes involved in limited mobility, they will not register at the furthest LMA, normally the Gateway LMA. This helps reduce registration delay when handoff takes place. On the other hand, as LMA selection is on a per Mobile Node basis, all the LMAs inside the domain may not end up with the same selection. Consequently, the registration load is decentralized from the GLMA to all the LMAs in the domain. This MCMT algorithm is also adaptive to changes in movement pattern. When the Mobile Node moves in a different way from before, which can be changes in either speed or mobility scope, a new LMA will be discovered to replace the current serving one, if there exists such a more appropriate LMA. This new LMA can be either further or nearer or the same distant away compared to the previous one. After a LMA has been selected, the Mobile Node performs two kinds of registrations. The first one, local registration, binds the home address of the Mobile Node to its Local Care of Address (LCoA) at the selected LMA. The second one, global registration, binds the home address of the Mobile Node to its Global Care of Address (GCoA) at the Home Agent and Correspondent Nodes. When data packets come in, they are first sent to the LMA, then they are forwarded to the present location specified by the Local Care of Address. The MCMT algorithm does not exclude employment of any other LMA selection protocols. In present literature, there are two other LMA selection schemes, the furthest selection and preference selection. The MCMT scheme can coexist with these protocols that the Mobile Node can switch between different selection modes. 4 Message Format and Conceptual Data Structures The MCMT protocol requires a new IPv6 neighbor discovery option [5] to organize the LMAs inside a domain into hierarchy. Each LMA also keeps its hierarchy information locally, which requires a data structure for recording. To differentiate between local registration and global registration, the Mobile IPv6 binding update message is modified. 4.1 LMA Advertisement Option The LMA Advertisement Option is a new ICMPv6 option [6] sent together with router advertisement to propagate LMA information throughout a domain. The format of this option is as follows: Xu, Lee, Thing Expires 14 August 2003 [Page 3] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 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 | Search Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dist (1) | Dist (2) | (More Dist Values) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address of LMA (1) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . (Global IP Addresses of other LMAs) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit identifier of the type of this option. TBA. Option Length 8-bit unsigned integer. The length of the option in unit of 8 octets, including the type and length fields. Search Interval The length of the period (in seconds) to be used for searching a LMA according to the MCMT algorithm. This value is recommended by the network. This allows the network to achieve certain optimization objective, such as load sharing. Lifetime The period (in seconds) in which the LMA is assumed to be valid. Each LMA is required to send out its LMA Advertisement Option periodically. When a LMA stops transmitting the option longer than this lifetime, it is believed to be invalid. Dist An 8-bit hop by hop counter that records the distance from a LMA Xu, Lee, Thing Expires 14 August 2003 [Page 4] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 to the receiving node of this option, which can be either another LMA or a router. This field is increased by one on each hop as the option propagates through each subnet. As the option goes through a series of LMAs and they join in one after another, the size of this option increases gradually by including more LMA items. The Dist fields are allocated in block of 8 at one time. If the number of LMAs contained in the option is less than 8, the remaining space is unused. If the number of LMAs is more than 8, another block is allocated following the first block, and so on. The actual number of LMAs can be deduced from the option length. Global IP Address of LMA A global IP address of one of the network interfaces of the LMA. The Mobile Node is informed of this address so that it knows where to send its regional binding update if this LMA is selected. When multiple LMAs are carried in one option, they appear in the same sequence as the Dist fields, so that they can be easily matched to each other. 4.2 Conceptual Data Structures Each LMA MUST keep a local copy of its hierarchy information. This information is used for two purposes. The first one is to help each LMA find the shortest path from GLMA, the second one is to detect network topology change and maintain the connectivity of the LMA hierarchy. This LMA hierarchy list MAY be implemented in any manner consistent with the description in this document. The conceptual data structure used to record the LMA Hierarchy List contains these fields: - The search interval received in the latest LMA Advertisement Option. This field is copied into any outgoing LMA Advertisement Option. - The lifetime of the parent LMA. This lifetime is used to estimate the validity of the parent LMA. Each LMA MUST periodically send LMA Advertisement Option. The interval of the period is shorter than the lifetime so that all its children LMAs are assured of the connectivity to its parent. - A list of LMAs from the GLMA to the LMA itself. This list records complete path information in the LMA hierarchy. For each LMA, two items are kept in the list, its distance and IP address. When a new LMA Advertisement Option comes in, if it represents a shorter path than the one recorded locally, then this local LMA list is updated with the newly received option. Otherwise, this LMA list remains intact. Xu, Lee, Thing Expires 14 August 2003 [Page 5] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 4.3 Modification to Mobile IPv6 Binding Update To differentiate between global registration and local registration, the Mobile IPv6 Binding Update message is modified by adding the 'V' flag bit. When the Binding Update carries a local registration, the 'V' bit MUST be set. Otherwise, the 'V' bit SHOULD NOT be set. The new format looks like the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D|L| Reserved |V| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 LMA Tree Construction and Maintenance 5.1 Establishing LMA Tree Hierarchy When the LMAs inside a domain are first set up, they do not know own position in the LMA hierarchy tree. The Gateway LMA takes the responsibility to initialize the tree construction process by sending the first LMA Advertisement Option. This option contains only one LMA entry, the GLMA itself. The Dist field is initialized to 1 and the Global IP Address field contains the IP address of the GLMA. The Lifetime field indicates the valid period of the GLMA. The Search Interval field can be set to a value specify by the network, for example, 10 minutes. Upon arrival of this option at a downstream router, if the router does not act as LMA at the same time, it just simply increments the Dist field by 1 and forwards the option onto the other network interfaces. If multiple LMA items are contained in one option, each Dist field is incremented by 1. If the router is a LMA meanwhile, it examines whether a local LMA list already exists. If there is no local LMA list, this is the first LMA Advertisement Option that has ever been received. Then a local LMA list is created using the information carried in this option. If there exists a LMA list already, comparison is made between the length of the local list and that of the received option. The one that contains fewer number of LMAs represents a shorter path from the GLMA. If the local list is shorter, then it remains intact and the received option is silently discarded. If Xu, Lee, Thing Expires 14 August 2003 [Page 6] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 the received option is shorter, then the local LMA list is updated with the content of the option. After that, this LMA generates a new LMA Advertisement Option to replace the received one and forwards this new option onto the other network interfaces. In the new option, the LMA adds in itself as the last entry and set its Dist value to 1. All the other entries are copied from its local LMA list and the Dist values of these LMAs are incremented by 1. The Search Interval field is also copied from its local maintained LMA Hierarchy List. The Lifetime field is set to a value defined by this LMA itself. As the LMA Advertisement Option propagates away from the Gateway LMA, more LMAs are discovered and the length of the advertisement increases gradually until access router is reached, where the LMA tree construction process completes. In this way, every LMA will eventually join the LMA tree. Each access router MUST also keep a local LMA Hierarchy List. They periodically send the LMA Advertisement Option onto the wireless link, so that the Mobile Node can be informed of the list of LMAs from which one will be selected. The Mobile Node MAY also request a LMA Advertisement Option to be sent to itself. It should be noticed that though the LMA Advertisement Option is designed to circulate around with router advertisement, it is not required that each router advertisement must go with LMA Advertisement Option. To reduce the signalling overhead, the LMA Advertisement Option MAY be selectively included in some of the router advertisements. 5.2 Maintaining LMA Tree Hierarchy Every LMA MUST periodically send its LMA Advertisement Option, the interval between these options MUST be shorter than the Lifetime defined in the previous LMA Advertisement Option. Once a downstream LMA receives the option, it first examines if this option comes from its parent LMA or not. This can be done by comparing the list of LMAs in the option to those recorded in the local LMA Hierarchy List. If it is confirmed that this option comes from the parent LMA and the content of the LMA list in the option is consistent with that in the local record, then the Lifetime field in the local LMA Hierarchy List is updated with the value carried in the option. After the LMA tree has been established, the local LMA Hierarchy List in each LMA represents the shortest path from GLMA. All other LMA Advertisement Options received are silently discarded. When a LMA does not hear from its parent LMA or does not receive a LMA Advertisement Option consistent with its local record for a duration longer than the Lifetime kept in its local LMA Hierarchy List, the parent LMA is deemed to be unreachable. This LMA will Xu, Lee, Thing Expires 14 August 2003 [Page 7] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 become attentive to the other LMA Advertisement Options to join the LMA tree again. In this case, the LMA will first select a LMA Advertisement Option randomly to join, then it compares it to the subsequently received options to gradually find out the shortest path from GLMA. When a LMA begins to rejoin into the LMA tree, it will not send out the same LMA Advertisement Option as before. If this LMA has children LMAs, the children LMAs will trigger their rejoining process subsequently. Depending on the LMA Advertisement Options received by individual LMA, they may probably select the same parent LMA or a different one. 6 LMA Selection and Registration 6.1 LMA Selection When the Mobile Node moves into a foreign domain where LMAs are deployed, the Mobile Node will receive a list of LMAs from the access router. The selection of a LMA from the list is described as follows. 6.1.1 Default Selection When the Mobile Node first enters a foreign domain, it SHOULD select the furthest LMA from the LMA list that it receives, which is the Gateway LMA. This selection is made because the furthest LMA is anticipated to cover the mobility of the Mobile Node for the longest time when there is no knowledge on the movement of the Mobile Node yet. The IP address of the furthest LMA can be found in the LMA Advertisement Option received from access router. Then the Mobile Node performs both global registration and regional registration by sending Binding Updates to Home Agent, Correspondent Node and this selected LMA. 6.1.2 Selecting a Nearer LMA After the Mobile Node has selected the GLMA, it immediately starts to search for a nearer LMA to replace the GLMA. The Mobile Node keeps collecting the LMA lists for a period, the duration of which observes the specification carried in the Search Interval field in the LMA Advertisement Option. At the end of the Search Interval, the Mobile Node compares all the LMA lists to find out those LMAs that have appeared in all these lists. The nearest one of them is identified to be the newly selected LMA. If this newly selected LMA is the same as the current Serving LMA, Xu, Lee, Thing Expires 14 August 2003 [Page 8] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 the GLMA in the first place, then another round of search starts again without changing the current Serving LMA. If this newly selected LMA is different from the current Serving LMA, then the new LMA will replace the current serving one. The Mobile Node sends a local Binding Update to the newly selected LMA to bind its Home Address to its LCoA, and sends global Binding Updates to the Home Agent and Correspondent Node. To reduce packet loss during this transition period, the Mobile Node also send one more Binding Update to the Previous LMA to bind its Home Address to the IP address of the new LMA. In this way, any in-flight packet directed to the Previous LMA can be redirected to the new location of the Mobile Node. It is noticed that in the above description, the Mobile Node never moves beyond the coverage of the current Serving LMA. Therefore, the newly selected LMA is always nearer than the Previous LMA. This selection sequence happens when the Mobile Node reduces its mobility scope gradually, which represents a typical movement pattern. In real world scenario, after entering a foreign domain, many Mobile Nodes locate their destination in the domain and then settle down there. These Mobile Nodes will finally select the nearest LMA. 6.1.3 Selecting a Peer LMA When the Mobile Node moves out of the coverage of the current Serving LMA, it needs to select a new LMA. The Mobile Node detects its movement by noticing that the Serving LMA does not appear in the latest received LMA Advertisement Option. From the latest LMA list, the Mobile Node selects the LMA that is almost the same distant away from the Mobile Node as the Previous LMA. Because each LMA in the list comes with its distance, the one with the distance value closest to the Previous LMA is identified to be the peer LMA. The Mobile Node then sends Binding Update to this peer LMA to bind its Home Address to its LCoA. The Mobile Node also sends Binding Update to the Home Agent and Correspondent Node to bind its Home Address to the new GCoA. The IP address of the new LMA is registered at the Previous LMA too. Because the Previous LMA has been selected after a Search Interval, it is believed to be reflecting the present mobility feature of the Mobile Node. Therefore, the peer LMA is considered to be the most appropriate choice after the Mobile Node goes beyond the coverage of the Previous LMA. 6.1.4 Selecting a Non-Peer LMA Xu, Lee, Thing Expires 14 August 2003 [Page 9] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 However, when the Mobile Node goes beyond the coverage of the Previous LMA, it might be due to change in its mobility pattern in addition to the change of location. In this case, a LMA other than the peer one might be more appropriate. Once the Mobile Node moves out of the coverage of the Previous LMA and selects a peer LMA, it starts to search for another LMA in the meantime. At the end of the Search Interval, the Mobile Node finds out the new LMA in accordance with the description in section 6.1.2. However, different from the section 6.1.2 is that the non-peer LMA can be either further or nearer than the Previous LMA. Similar to the description in previous sections, the Mobile Node MUST perform a local registration to bind its Home Address to its LCoA, global registrations to bind its Home Address to its GCoA, and another local registration to inform the Previous LMA of the IP address of the newly selected LMA. 6.2 LMA Registration 6.2.1 Registration at Home Agent and Correspondent Nodes Each time the Mobile Node has selected a LMA, it registers the IP address of the selected LMA at its Home Agent and Correspondent Node. This registration sets up a binding between the Home Address of the Mobile Node and its Global Care-of Address. The registration message format follows the specification described in [1]. The Mobile Node sets the source address of the Binding Update message to its LCoA, the destination address to that of the Home Agent and Correspondent Node, the Alternative CoA field in the mobility option to its GCoA, and the Home Address Destination Option to its home address. 6.2.2 Registration at Serving LMA Meanwhile, the Mobile Node also registers its Local Care-of Address at the selected LMA. This registration binds the Home Address of the Mobile Node to its Local Care-of Address. In the Binding Update, the source address is set to LCoA, the 'V' flag is set, the Home Address Destination Option is set to its home address. 6.2.3 Registration at Previous LMA Each time the Mobile Node selects a different LMA, it registers the IP address of the current Serving LMA at the Previous LMA. Because in the transition period, all the packets sent from the Correspondent Node are directed to the Previous LMA until the Binding Update has been received at the Correspondent Node, This additional local registration help to reduce packet loss during Xu, Lee, Thing Expires 14 August 2003 [Page 10] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 the transition period by redirecting the packets from the Previous LMA to the current Serving LMA. However, this local registration is different from the two above mentioned registration in the sense that it is needed only for a short time, normally a few seconds should already be long enough. After that, the binding entry expires automatically. In the Binding Update message, the source address is set to LCoA, the destination address is set to that of the Previous LMA, the Alternative CoA field in the mobility option is set to the address of the current Serving LMA, Home Address Destination Option is set to its home address, and 'V' flag is set. 6.2.4 Data Packet Forwarding After the Home Agent and Correspondent Nodes have been updated with the GCoA, they will send subsequent data packets to the current Serving LMA, which then tunnels [7] the packets to the latest LCoA of the Mobile Node. If the Mobile Node has recently changed LMA selection, the data packets will be sent to the Previous LMA, then tunneled to the current Serving LMA, then tunneled to the LCoA, until the Home Agent and Correspondent Nodes are updated with the address of the new GCoA. 7 Coexistence of Various LMA Selection Modes The MCMT LMA selection algorithm can coexist with other LMA selection algorithms. In present literature, there is another selection method based on preference value. In a domain that employs more than one LMA selection algorithm, they can be used independently. The Mobile Node receives different LMA advertising options for each of the selection algorithms. Then the Mobile Node MAY decide to use one of them by ignoring the other options. 8 Security Considerations As the MCMT Local Mobility Agent selection algorithm does not change the signaling for global registration, the security issues related to the Home Agent and Correspondent Node can be taken care of by the methods proposed in the Mobile IPv6 Internet draft [1]. 8.1 Binding Updates to Home Agents The Mobile Node and Home Agent must have pre-established security association. The Binding Update messages to Home Agent are protected by Authentication Header or Encapsulating Security Payload. Xu, Lee, Thing Expires 14 August 2003 [Page 11] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 8.2 Binding Updates to Correspondent Nodes The Binding Update messages to Correspondent Nodes are protected by Home Test and Care-of Test. 8.3 Binding Updates to Local Mobility Agents There is no security association between the Local Mobility Agent and the Mobile Node. However, such security association can be obtained by any dynamic means, such as AAA server in the visited domain. 9 References [1] David B. Johnson, Charles E. Perkins, Jari Arkko. Mobility Support in IPv6. Internet Draft draft-ietf-mobileip-ipv6-18.txt (work in progress), Internet Engineering Task Force, June 2002. [2] Carl Williams. Localized Mobility Management Requirements for IPv6. Internet Draft draft-ietf-mobileip-lmm-requirements-02.txt (work in progress), Internet Engineering Task Force, June 2002. [3] Hesham Soliman, Claude Castelluccia, Karim El-Malki, Ludovic Bellier. Hierarchical MIPv6 mobility management (HMIPv6). Internet Draft draft-ietf-mobileip-hmipv6-06.txt (work in progress), Internet Engineering Task Force, July 2002. [4] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119. Internet Engineering Task Force, March 1997. [5] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments 2461. Internet Engineering Task Force, December 1998. [6] A. Conta, S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocl Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2463, Internet Engineering Task Force, December 1998. [7] A. Conta, S. Deering. Generic Packet Tunneling in IPv6 Specification. Request for Comments (Proposed Standard) 2473, Internet Engineering Task Force, December 1998. Xu, Lee, Thing Expires 14 August 2003 [Page 12] INTERNET-DRAFT MCMT Local Mobility Agent Selection February 2003 10 Authors' Addresses Questions about this document can also be directed to the authors: Yi Xu Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 6874 8457 Fax: +65 6775 5014 Email: yxu@i2r.a-star.edu.sg Henry C. J. Lee Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 6874 6668 Fax: +65 6775 5014 Email: hlee@i2r.a-star.edu.sg Vrizlynn L. L. Thing Institute for Infocomm Research 21 Heng Mui Keng Terrace Singapore 119613 Phone: +65 6874 6728 Fax: +65 6775 5014 Email: vriz@i2r.a-star.edu.sg Xu, Lee, Thing Expires 14 August 2003 [Page 13]