Hui Deng INTERNET-DRAFT Hitachi (China)Investment Ltd. <draft-deng-mip6-ha-loadbalance-01.txt> Rong Zhang China Telecom Xiaolong Huang University of California at Los Angeles Kai Zhang Tsinghua University Expires: October 2004 April 2004 Load Balance for Distributed Home Agents in Mobile IPv6 draft-deng-mip6-ha-loadbalance-01.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 dynamical 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........................................... 3 2. Terminology............................................ 3 3. Previous work.......................................... 4 4. Multiple Home Agents................................... 5 5. Modified Home Agents List.............................. 6 6. Modified Router Advertisement Message.................. 7 Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 1]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 7. New Load Balance Information Option Format............. 8 8. Home Agent Reassignment................................ 9 9. Prevention of Duplicate Home Agent Assignment..........11 10. IANA Considerations....................................12 11. Security Considerations................................13 12. Acknowledgements.......................................13 References.............................................14 Authors' Addresses.....................................14 A. Changes from Previous Version of the Draft.............14 Intellectual Property and Copyright Statements..........15 Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 2]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 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. DHAAD has been specified in base Mobile IPv6 protocol, but it can be only used for stationary load balance among multiple home agents. 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. 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. Correspondent Node (CN) A peer node with which a mobile node is communicating. The correspondent node may be either mobile or stationary. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 3]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 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 10.1. The list is used for informing mobile nodes during dynamic home agent address discovery. 3. Previous Work The document [4] has described the problem related to switch the service from the failed home agent to another functional home agent, and propose some guideline for possible solution. Load balance of multple home agents also has been illustrated. In document [5], Virtual Home Agent Reliability Protocol has been proposed to solve the realibility problem of home agent. The solution is transparent to mobile node. Principally, this solution is quite similar to VRRPv6 [6]. Even for VRRP solution which is related to dynamically assigns responsibility for a virtual router to one of VRRP routers on a LAN, different vendor has different solution, some vendors provide layer 3 solution VIP (Virtual IP), and other vendors can provide layer 2 solution VMAC(Virtual MAC). Besides VRRP, some other proprietary protocol such as heart-beat can also be used for avoding reliability problem of home agent. So that will be inefficient to making a standard about home agent reliability, and not only vendors, but also carrier/SIP will be quite diffcult to handle this issue. Furthermore, home agent list and DHAAD have not been considered in this document yet, but DHAAD have been originally designed to handle multiple home agents in base Mobile IPv6 protocol. Besides that, this protocol only has one active home agent to keep the transparent to mobile node, so it mightbe quite diffculty to do load balance based on this mechanism. Problem of sequence number in security assocation have not yet been considered. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 4]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 Inter Home Agents Protocol (HAHA) [7] has been proposed to provide multiple home agent redundancy and load-balancing for both Mobile IPv6 protocol and Nemo basic support protocol. Because HAHA protocl allows multiple home agents to be placed at different links, it can prevent home link failure from Mobile IPv6. How to optimize the synchronizing binding message among multiple link home agents will be the most important, but this problem has been omited in the document. Furthermore synchronizing binding of only one particular MN to multiple home agents simultaneously has been described. Suppose there are more than 0.1 million users, such kind of synchronizing signal will be a heavy burdern for network. Considering the reliability of home agent, if Primary Home Agent is failed, and one CN want to start communicate with MN, but based on the HAHA protocol, it will be quite diffcult for CN to find the where is MN because in the home network even other home agent existed and has been synchronizd. Another issue related to HAHA is that if all outgoing packets from MN will be always tunneled through primary home agent, realiability and load balance will have some problems. Finally network and signaling based on HAHA is complicatd, but carrier/ISP expect simple deployment of network architecuture, anyway this solution will be quite useful in the case of NEMO. 4. Multiple Home Agents The following Figure gives the topology layout to deploy this protocol for distributed home agents |------------------------------| |---------- | | | | |---| |---| |---| |---| |HA | |HA | |HA | |FA | |---| |---| |---| |---| \ /\ \ /\ /MN\ ------------------- /MN\ /----\ / /----\ / 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. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 5]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 5. 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. A new entry is created or an existing entry is updated in response to receipt of a valid Router Advertisement in which the Home Agent (H) bit is set. Each Home Agents List entry conceptually contains the following fields: o The link-local IP address of a home agent on the link. This address is learned through the Source Address of the Router Advertisements [8] received from the router. o One or more global IP addresses for this home agent. Global addresses are learned through Prefix Information options with the Router Address (R) bit set, received in Router Advertisements from this link-local address. Global addresses for the router in a Home Agents List entry MUST be deleted once the prefix associated with that address is no longer valid [8]. o The remaining lifetime of this Home Agents List entry. If a Home Agent Information Option is present in a Router Advertisement received from a home agent, the lifetime of the Home Agents List entry representing that home agent is initialized from the Home Agent Lifetime field in the option (if present); otherwise, the lifetime is initialized from the Router Lifetime field in the received Router Advertisement. If Home Agents List entry lifetime reaches zero, the entry MUST be deleted from the Home Agents List. o The preference for this home agent; higher values indicate a more preferable home agent. The preference value is taken from the Home Agent Preference field in the received Router Advertisement, if the Router Advertisement contains a Home Agent Information Option, and is otherwise set to the default value of 0. A home agent uses this preference in ordering the Home Agents List when it sends an ICMP Home Agent Address Discovery message. Here we extend Home Agents List to support load balance mechanism, so it can share the traffic information among the home agents in the home network to make decisions of home agent Reassignment. To do so, Home Agents List has been extended to indicate the traffic load level of all home agents in the home network. The entry has been added to Home Agent Lists related to traffic load information is: A. 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. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 6]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 B. 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 information to all the other home agents in the home network throuth the router advertisement. 6. Modified Router Advertisement message Here we extend the Unsolicited Router Advertisement Messages to include traffic load information. A new option - called traffic load - is embedded into the Option field of Unsolicited Router Advertisement Messages. Routers send out Router Advertisement message periodically, or in response to a Router Solicitation. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|L| Res. | Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- ICMP Fields: L 1-bit "Load Balance" flag. When set, Load Balance information will be broadcasted based on Router Advertisement message, Load Balance information option will be included in the options. Res.(Reserved) Reduced from 5-bit to 4-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The maximum value corresponds to 18.2 hours. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default router list. The Router Lifetime applies only to Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 7]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. Prefix Information These options specify the prefixes that are on-link and/or are used for address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on- link destinations for the links to which they attach. If complete information is lacking, a multihomed host may not be able to choose the correct outgoing interface when sending traffic to its neighbors. In the Prefix Information option for use in Router Advertisement 1-bit router address flag Must be set to guarantee Prefix field containing a complete a global IPv6 address of this home agent. of The added Option field in the router advertisement should be as follows. 7 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Size | Registered MN Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 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. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 8]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Queue Size (2 byte): A coarse parameter for the Queue Size in the router's TLT Registered MN Number (2 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 [8]. 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 Router Advertisement with the Traffic Load Information from other home agent, a home agent should record the traffic load into the its extended Home Agents List. The home agent keeps the Home Agents List sorted in a non-ascending order of the traffic load field, unless the traffic load is LIGHT. For the LIGHT home agent, the Home Agents List 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. Home agents MAY include this option in their Router Advertisements. This option MUST be silently ignored for other Neighbor Discovery messages. 8. 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. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 9]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 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 Home Agents List 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. 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 Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 10]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 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. 9. 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 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. Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 11]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 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 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. 10. 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 Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 12]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 11. Security Considerations Security Considerations have not been discussed in this draft. Acknowledgements The authors would like to thank Hidenori Inouchi, Shiro Tanabe of Hitachi Central Research Lab. for their comments and suggestions. 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, Zhang, Huang, Zhang Expires: October 2004 [Page 13]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 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 Rong Zhang Network Technology Research Division Guangzhou Research and Development Center China Telecom Guangzhou, 510630, China Email: zhangr@gsta.com 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: 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-00.txt: o A home agnet list has been extended to replace traffic load table. o A new flag has been added to support load balance information in Router Advertisement Message. 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 Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 14]
INTERNET-DRAFT draft-deng-mip6-ha-loadbalance-01.txt April 2004 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 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." Deng, Zhang, Huang, Zhang Expires: October 2004 [Page 15]