H.Deng INTERNET-DRAFT Hitachi (China)Investment Ltd. Rong Zhang China Telecom Xiaolong Huang University of California at Los Angeles K. Zhang Tsinghua University Expires: April 2004 November 2003 Load Balance for Distributed Home Agents in Mobile IPv6 draft-deng-mip6-ha-loadbalance-00.txt Status of this memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies the load balance of mechanism which take account of not only the mobile node registration information but also data the tunneled data traffic information to effectively release and prevent the formation of the traffic bottleneck at the home agent. TABLE OF CONTENTS 1. Introduction........................................... 2 2. Multiple Home Agents................................... 2 3. Traffic Load Table in the Home Network ................ 3 4. Home Agent Reassignment................................ 4 Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 1] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 5. Prevention of Duplicate Home Agent Assignment.......... 5 1. Introduction In Mobile IPv6 [1], home agents are responsible for the registration of mobile nodes in the home network, and tunneling the data packets to the mobile nodes when the mobile nodes are not reachable through its home IP addresses tentativly. but it will cause that the traffic bottleneck could be formed at a home agent. When the home agent experiences high intensity of the tunneled traffic and the mobile node registration information. This protocol defines a hybrid load balance mechanism which takes account of not only the mobile node registration information but also the tunneled data traffic information to effectively release and prevent the formation of the traffic bottleneck at the home agent. Specific flow state establishment methods and the related service models are out of scope for this specification, but the generic requirements enabling co-existence of different methods in IPv6 nodes are set forth in section 4. 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 [KEYWORDS]. 2. Multiple Home Agents The following Figure gives the topology layout to deploy this protocol for distributed home agents In this protocol, the home network is composed of multiple Mobile IPv6 home agents and multiple mobile nodes. Each home agent in the home network is attached with an access router. When the mobile nodes reside in the home network, the home agents do not execute any home agent tasks. The home agent assignment of the mobile nodes in the home network can be either evenly assigned among the multiple HAs or unevenly assigned. Whether the home agent assignment is even or not would neither arbitrarily affect the original traffic burden problem nor affect the performance of this protocol. |------------------------------| |---------- | | | | |---| |---| |---| |---| |HA | |HA | |HA | |FA | |---| |---| |---| |---| \ /\ \ /\ /MN\ ------------------- /MN\ /----\ / /----\ / Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 2] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 3. Traffic Load Table in the Home Network This protocol shares the traffic information among the home agents in the home network to make decisions of home agent Reassignment. To acquire and maintain the traffic information, each home agent maintains a so-called Traffic Load Table (TLT). The Traffic Load Table has records to indicate the traffic load level of all home agents in the home network. The entry of the Traffic Load Table (TLT) is: A. Home Agent Address The home agent address is the IP address of the base station where the home agent resides. B. Queue Size The traffic load indicates the buffer size at a home agent. When the buffer size of a home agent is lower than a threshold, the buffer size is considered to be LIGHT. C. Registered MN Number at a HA The home agent should monitor its queue size and the registered mobile node number. Each home agent periodically broadcasts its traffic load advertisement to all the other home agents in the home network. The traffic load advertisement has the same fields as in the traffic load table. The traffic load advertisement could be embedded into Unsolicited Router Advertisement Messages. A new option - called traffic load - is embedded into the Option field of Unsolicited Router Advertisement Messages. The added Option field should be as follows. Queue Size (1 byte): A coarse parameter for the Queue Size in the router's TLT Registered MN Number (1 byte): Registered MN number. If more than 256 MN could register a HA, the field should be a coarse paramter for the MN number in the router's TLT Unsolicited Router Advertisement messages should be sent at time uniformly distributed within [MinRtrAdvInterval, MaxRtrAdvInterval] according to RFC2461. To make the traffic information more effective, the Unisolicited Router Advertisement message with the Traffic Load information should be sent at time uniformly distributed with in [MinRtrAdvInterval, MinRtrAdvInterval + IntervalTLTExtention]. IntervalTLTExtention = 2 * MinRtrAdvInterval Upon receiving the RouterAdvertisement with the Traffic Load Information from other home agent, a home agent should record Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 3] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 the traffic load into the its Traffic Load Table. The home agent keeps the Traffic Load Table sorted in a non-ascending order of the traffic load field, unless the traffic load is LIGHT. For the LIGHT home agent, the Traffic Load Table is sorted in a non-ascending order of the registered mobile node number. In this protocol, the Queue Size field is used to make decisions for home agent reassignment to release the traffic burden, while the registered mobile node number field is used to prevent the formation of the traffic burden. 4. Home Agent Reassignments In this protocol, at each home agent, a timer is attached for each entry in the binding update cache. When the timer is time out, the mobile node corresponding to the entry is considered to be eligible for home agent reassignment. The timeout time is called RegTIMEOUT. RegTIMEOUT = MinRtrAdvInterval / Queue Size Indicator Queue Size Indicator is a paramter indicating the traffic load. The home agent may select a new home agent in the Traffic Load Table for the timeout mobile node according to our home agent reassignment algorithm. If a new home agent is assigned to the timeout mobile node, the home agent actively sends out an ICMP Reply message to the mobile node without the reception of any ICMP Request message. Different from the standard ICMP reply packet, the ICMP here should only contain one home agent in the home agent list, which is the newly selected home agent, other than contains a list home agent. By receiving this ICMP message, the timeout mobile node should compare the indicated home agent with its old home agent. If the indicated home agent in the ICMP Reply message is different from the old home agent, the mobile node should modify its home agent field and register at the new home agent by sending a binding update message to the new home agent IP address. By using the ICMP messages in the DHAAD mechanism, this protocol can be implemented in the IETF Mobile IPv6 draft without any changing of the protocols of the communication between home agents and mobile nodes. The frequency of selecting a new home agent for the mobile node is a tradeoff between the home agent handoff frequency and the load balance performance. The home agent should not frequently select a new home agent for the registered mobile node, because the home agent handoff induces extra control traffic and delays the traffic forwarding to the mobile nodes. Thus only a very busy home agent or a potentially very busy home agent should proceed to the home agent handoff. Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 4] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 When selecting a new home agent, the new home agent should be one of the most released home agents in the Traffic Load Table. There are two fields in the traffic load table should be considered in the home agent selection algorithm. One is the Queue Size field, which indicates the current traffic load. Another one is the registered mobile node number, which indicates the potential traffic load in the future. The home agent should prevent from having too many registered mobile nodes, so that the future traffic burden formed by the tunneled traffic for the registered mobile nodes could be prevented. The new HA Reassignment algorithm is as follows. Algorithm. HA Reassignment IF (Self Queue Size > LIGHT) THEN IF (Other HA Queue Size < LIGHT) THEN Randomly select a HA with LIGHT Queue. ELSE IF (Self Queue Size is top 10% in the traffic table) THEN Randomly select a bottom 10% home agent in the traffic table END ELSE THEN IF (my registered MN number is top 10% in the traffic table) THEN Randomly select a bottom 10% home agent in the traffic table. END END In the home agent reassignment, only one of the most busy home agents can select a new home agent for its registered mobile node. Thus the new home agent assignment does not take place frequently. In Mobile IPv6, a mobile node only needs the home agent to tunnel the data traffic before the Correspondent Binding Update Procedure take place, when the mobile node is moving from one network to another network. Thus a home agent who has more number of registered mobile nodes is more likely to experience tunnel traffic because more mobile nodes potentially will move from one network to another network. This protocol can force a home agent to start the new home agent assignment even though the home agent does not experience much traffic, so that the future traffic burden could be prevented statistically. 5. Prevention of Duplicate Home Agent Assignments The home agent reassignment may induce duplicate home agent assignments. When a mobile node subsequently sends more than one binding updates to the old home agent, the home agent may have different decisions on selecting the new home agent for the same mobile node. When the duplicate home agent assignment occurs, only the last new home agent is regarded as the new home agent of the mobile node. The mobile node will only process its Mobile IPv6 tasks with the latest assigned new home agent, while other duplicate home agents assigned to the mobile node still sit in the home network without further updates from the mobile node. This situation is not allowed to happen, because the duplicate home Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 5] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 agents cannot correctly forward the traffic to the mobile node without the updates from the mobile node. To uniquely assign a home agent for the mobile node, the home agent should maintain a Home Agent Handoff Table. The Handoff Table is used to record whether a mobile node has been handed over to another HA in a quite recent time. And if that is the case, it should discover which HA is the last HA assigned to the mobile node. Thus the last assigned HA will still be the HA assigned for the mobile node this time. An entry of the Handoff Table has following fields. Mobile Node Address This field represents the IP address of a registered mobile node, which sends binding updates to the home agent periodically. Handing Off (true/false) This field represents whether a mobile node has been handed over to another HA in a quite recent time. If that is the case, the mobile node should be assigned to the same home agent as last assignment. New Home Agent Address This field records the last home agent assigned to a registered mobile node. It avoids duplicate home agent assignments. Handoff Expire Time This field represents whether the Handing Off field of this entry is valid. If the handoff timer has expired, the handing off field of this entry is invalid. Before the home agent select a home agent for the registering mobile node, the home agent should check the Home Agent Handoff Table. If anyone of the following conditions is true, the mobile node should be regarded as eligible to select a new home agent. 1. There is no entry for the mobile node in the handoff table. 2. Handing off field is false. Thus the mobile node has not been handed over to another HA in a quite recent time. 3. Handoff expire time is before the current time. If the mobile node is eligible to be assigned a new home agent, the home agent selects a new home agent and writes an entry for the mobile node into the Home Agent Handoff Table. The handing off Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 6] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 field should be set true, and expire time should cover the subsequent several binding updates of the mobile nodes. If the mobile node is illegible to a new home agent assignment, the home agent assigned to the mobile node should be the new home agent address in the Home Agent Handoff Table, or the home agent itself in case of no entry being found. Acknowledgements The authors would give special thanks to the researchers in HITACHI Research Center, where the discussions have been carried out. References [1] D. B. Johnson, C. Perkins, and J. Arkko, "Mobility support in IPv6," in IETF, 2002. [2] J. Jue and D. Ghosal, "Design and Analysis of Replicated Server Architecture for Supporting IP-Host Mobility,'' in ACM Mobile Computing and Communications Revue, 2(3):16-23, 1998. [3] J. Jue and D. Ghosal, "Design and Analysis of Replicated Server to Support IP-Host Mobility in Enterprise Network," in IEEE International Conference on Communications v3:1256-1260, 1997. [4] A. Vasilache, J. Li and H. Kameda, "Load Balancing Policies for Multiple Home Agents Mobile IP Networks," in IEEE International Conference on Web Information Systems Engineering, 2001. [5] N. Montavont and T. Noei, "Handoff Management for Mobile Nodes in IPv6 Networks," in IEEE Communication Magazine, 40(8):38-43, 2002. Authors' Addresses Hui Deng Research & Development Center Hitachi (China), Investment Ltd. Beijing Fortune Bldg. 1416, 5 Dong San Huan Bei-Lu Chao Yang District, Beijing 100004, China E-mail: denghui@hitachi.com.cn Rong Zhang Network Technology Research Division Guangzhou Research and Development Center China Telecom Guangzhou, 510630, China Email: zhangr@gsta.com Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 7] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 Xiaolong Huang Department of Electrical Engineering Engineering IV Building University of California at Los Angeles Los Angeles, CA 90023, USA Email: todhuang@ee.ucla.edu Kai Zhang Network Theory Laboratory. Department of Electronic Engineering Tsinghua University Beijing 100084, China Email: zhangk@atm.mdc.tsinghua.edu.cn IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Copyright Notice Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 8] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003 part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as and expires in January 2004. Deng, Zhang, Huang, Zhang Expires: April 2004 [Page 9] INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-00.txt November 2003