INTERNET-DRAFT Hui Deng <draft-deng-mip6-ha-loadbalance-02.txt> Hitachi (China) Date: October 2004 Brian Haley Hewlett-Packard Company Xiaodong Duan China Mobile Rong Zhang China Telecom Kai Zhang Tsinghua University Load Balance for Distributed Home Agents in Mobile IPv6 draft-deng-mip6-ha-loadbalance-02.txt Status of This Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document specifies a dynamic load balance mechanism among multiple home agents by taking into account acceptable number of mobile nodes for each home agent up to now, with the goal of reducing and preventing traffic bottlenecks at the home agent. This mechanism can be used when a home agent is overloaded, wants to achieve better load-balancing with peer home agents, or is going offline for service. Deng, Haley, Duan, Zhang, Zhang [Page i]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 TABLE OF CONTENTS Status of This Memo ............................................... i 1. Introduction............................................... 1 2. Terminology................................................ 1 3. Multiple Home Agents....................................... 2 4. Modified Home Agents List.................................. 3 5. New Load Balance Information Option Format................. 3 6. Home Agent Reassignment.................................... 4 6.1 Replace Home Agent Selection........................... 4 6.2 Home Agent Handoff message............................. 5 6.3 Sending Home Agent Handoff messages.................... 6 6.4 Receiving Home Agent Handoff messages.................. 6 7. IANA Considerations........................................ 6 8. Security Considerations.................................... 7 References................................................. 8 Authors' Addresses......................................... 9 A. Changes from Previous Version of the Draft................. 9 Intellectual Property and Copyright Statements..............10 Deng, Haley, Duan, Zhang, Zhang [Page ii]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 1. Introduction In Mobile IPv6 [1], home agents are reponsible for the registration of mobile nodes in the home network, intercepting packets destined for them, and tunneling these packets to their care-of address. When the home agent is supporting a large number of mobile nodes and actively tunneling traffic to them, it could become overloaded, leading to dropped packets and connections. Dynamic Home Agent Address Discovery (DHAAD) can be used to find another home agent, but the mobile node has no way of knowing that it should attempt this method until it has problems contacting its current home agent. There are many reasons a home agent might want to reduce the number of mobile nodes it is currently supporting. For example, it might be overloaded, it wants to achieve better load-balancing between a peer home agent, or it is going offline for service. This protocol defines a load balance mechanism among multiple home agents which can effectively release and prevent the formation of traffic bottleneck at the home agent. 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 [1]. Following terms are not re-defined. They are included for the convenience of the readers. IP Internet Protocol Version 6 (IPv6).[2] Mobile IPv6 Mobile IP for IPv6 [3] Home Agent (HA) A router on a MN's home link with which the MN has registered its current Care-of address. While the MN is away from home, the HA intercepts packets on the home link destined to the MN's home address, encapsulates them, and tunnels them to the MN's registered Care-of address. Mobile Node (MN) A node that can change its point of attachment from one link to another, while still being reachable via its home address. Deng, Haley, Duan, Zhang, Zhang [Page 1]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 Correspondent Node (CN) A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. Security Association (SA) An IPsec security association is a cooperative relationship formed by the sharing of cryptographic keying material and associated context. Security associations are simplex. That is, two security associations are needed to protect bidirectional traffic between two nodes, one for each direction. Dynamic Home Agent Address Discovery (DHAAD) A protocol which describes how a home agent can help mobile nodes to discover the addresses of the home agents [3]. The home agent keeps track of the other home agents on the same link, and responds to queries sent by the mobile node. Home Agents List Home agents need to know which other home agents are on the same link. This information is stored in the Home Agents List, as described in more detail in Section 4. The list is used for informing mobile nodes during dynamic home agent address discovery. Home Agent Handoff (HAH) message This HAH message is used by the home agent to signal the mobile node it should use another Home Agent for subsequent Binding Updates. 3. Multiple Home Agents The following Figure gives the topology layout to deploy this protocol for distributed home agents |------------------------------| |---------- | | | | |---| |---| |---| |---| |HA | |HA | |HA | |FA | |---| |---| |---| |---| \ /\ \ /\ /MN\ ------------------- /MN\ /----\ / /----\ / Deng, Haley, Duan, Zhang, Zhang [Page 2]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 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. 4. Modified Home Agents List Each home agent maintains a separate Home Agents List for each link on which it is serving as a home agent. An entry is created in response to receipt of a valid Router Advertisement in which the Home Agent (H) bit is set as specified in [1]. We extend the Home Agents List to support load balance information so it can share registration information among the home agents in the home netowrk to make decisions for home agent reassignment. 5 New Load Balance Information Option Format Load Balance among multiple home agents defines a new Load Balance Information option, used in Router Advertisements sent by a home agent to advertise information specific to this router's functionality as a home agent. The format of the Load Balance Information option is as follows: 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Mobile Node Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 Deng, Haley, Duan, Zhang, Zhang [Page 3]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value of this field MUST be 1. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Available Mobile Node Number (4 byte): Available Mobile Node number. This field should be a coarse parameter for the number of mobile node home bindings this home agent is able to accept. Unsolicited Router Advertisement messages should be sent at time uniformly distributed within [MinRtrAdvInterval, MaxRtrAdvInterval] according to [8]. To make the information exchange more effective, the Unisolicited Router Advertisement message with the Registered Mobile Node Information MAY can be sent at time uniformly distributed with in [MinRtrAdvInterval, MinRtrAdvInterval + IntervalRMMNExtension]. IntervalRMMNExtension = 2 * MinRtrAdvInterval The home agent keeps the Home Agents List sorted in ascending order since that should place the least-loaded first. Home agents MAY include this option in their Router Advertisements. This option MUST be silently ignored for other Neighbor Discovery messages. 6. Home Agent Reassignments 6.1 Replace Home Agent Selection There are many reasons a a home agent might want to reduce the number of mobile nodes it is currently supporting. For example, it might be overloaded, it wants to achieve better load-balancing between a peer home agent, or it is going offline for service. If another home agent offering services is known, its address can be communicated to the mobile node. Selection of this replacement home agent should follow these steps: o it MUST be in the current Home Agents List known by this home agent Deng, Haley, Duan, Zhang, Zhang [Page 4]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 o it SHOULD be offering services for same set of home prefixes as the current home agent o it SHOULD be the most lightly loaded home agent as determined from information supplied in a recent Load Balance Information Option 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. A home agent should not frequently select a new home agent for registered mobile nodes because the handoff induces extra control traffic and could cause a disruption of service. Therefore, only a highly loaded home agent should do a home agent handoff. 6.2 Home Agent Handoff message The Home Agent Handoff (HAH) message is used by the home agent to signal the mobile node it should use another Home Agent for subsequent Binding Updates. The Home Agent Handoff message uses the MH Type value 8 (TBD). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Agent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Home Agent Address The address of the preferred Home Agent. If set to the unspecified address, the mobile node should do DHAAD to find another Home Agent. If no actual options are present in this message, no padding is necessary and the Header Len field will be set to 2. Deng, Haley, Duan, Zhang, Zhang [Page 5]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 6.3 Sending Home Agent Handoff messages If another home agent is known and meets the criteria specific in 6.1, its address should be copied into the Home Agent Address field of the message. This address MUST be a unicast routable address. Otherwise it should be set to the unspecified address. In order to send a Home Agent Handoff message to the mobile node, the home agent MUST use the IPsec ESP tunnel already established for protecting Return Routability traffic as specified in [3]. This way the mobile node will avoid being subjected to a denial of service attack. 6.4 Receiving Home Agent Handoff messages After verifying the packet passes the authentication requirements, it should be processed as follows: o if the Home Agent Address field is set to the unspecified address, the mobile node should perform DHAAD to find a replacement home agent o if the Home Agent address is not a unicast routable address, the packet MUST be silently discarded o otherwise, the address should be stored for future binding updates When the mobile node determines it must renew its binding, it SHOULD NOT use the current home agent's address, but instead SHOULD use one it learned from the handoff message, DHAAD, or some other mechanism outside the scope of this draft. 7. IANA Considerations This document defines one new Neighbor Discovery [8] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery messages: o The Load Balance information option o New Mobile Header message, described in section 6.2 Deng, Haley, Duan, Zhang, Zhang [Page 6]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 8. Security Considerations Here we give a example to solve the SA problem based on our proposal. Visited Network | Home Network | +-------+ | +--------| HA1 | | | +-------+ | | | | +------+ | +-------+ | +-------+ | MN |<--------|-------> | sAAA |---+--------| HA2 | +------+ | +-------+ | +-------+ | | ... | | | | +-------+ | +--------| HAn | | +-------+ This figure shows the network architecture of our proposed solution with part function of AAA. sAAA(part function of AAA) will handle SA between mobile node and multiple home agents. sAAA will assign a home agent, home address and security credential with all home agents for mobile node. All home agents will be informed of correspondence security credential for all mobile nodes. When mobile node handover to a new home agent, the SA between them already established. If a home agent is being taken off-line, care should be taken to ensure that either other home agents can accept new mobile node home bindings, or there is a standby home agent in place, so there is no loss of service for the current mobile nodes. This should be done before attempting any handovers. Deng, Haley, Duan, Zhang, Zhang [Page 7]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 References [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in IPv6," draft-ietf-mobileip-ipv6-24 (work in progress), June 2003. [4] J. Faizan, H. El-Rewini, and M. Khalil, "Problem Statement: Home Agent Reliability", draft-jfaizan-mip6-ha-reliability-01 (work in progress), February 2004. [5] J. Faizan, H. El-Rewini, and M. Khalil, "Virtual Home Agent Reliability Protocol", draft-jfaizan-mipv6-vhar-01 (work in progress), February 2004. [6] R. Hinden, "Virtual Router Redundancy Protocol", draft-ietf-vrrp-spec-v2-10 (work in progress), February 2004. [7] R. Wakikawa, V. Devarapalli, and P. Thubert, "Inter Home Agents Protocol", draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004. [8] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [9] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June 2003. [10] D. Maughan, M. Schertler, M. Schneider, and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [11] A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. Deng, Haley, Duan, Zhang, Zhang [Page 8]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 Authors' Addresses Hui Deng Research & Development Center Hitachi (China), Investment Ltd. Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu Chao Yang District, Beijing 100004, China E-mail: hdeng@hitachi.cn Brian Haley Hewlett-Packard Company 110 Spitbrook Road Nashua, NH 03062, USA Email: Brian.Haley@hp.com Xiaodong Duan Research & Development Center China Mobile Beijing 100053, China Email: duanxiaodong@chinamobile.com Rong Zhang Network Technology Research Division Guangzhou Research and Development Center China Telecom Guangzhou, 510630, China Email: zhangr@gsta.com Kai Zhang Network Theory Laboratory. Department of Electronic Engineering Tsinghua University Beijing 100084, China Email: zhangkai98@mails.tsinghua.edu.cn Appendix A. Changes from Previous Version of the Draft This appendix briefly lists some of the major changes in this draft relative to the previous version of this same draft, draft-deng-mip6-ha-loadbalance-01.txt: o queue size has been deleted for deciding change of the home agent. o A new home agnet handover message has been defined to make home agent proactively notify the mobile node about changing of the serving home agent. Deng, Haley, Duan, Zhang, Zhang [Page 9]
INTERNET-DRAFT Load Balance among Multiple HAs October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Deng, Haley, Duan, Zhang, Zhang [Page 10]