MIP6/VRRP Working Group H. Deng Internet-Draft Hitachi Expires: January 12, 2006 X. Duan China Mobile Q. Li Beihang University R. Zhang China Telecom July 11, 2005 Reliability and Load Balance among multiple Home Agents draft-deng-mip6-vrrp-homeagent-reliability-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document proposes a scheme to support reliability and load balance among multiple Home Agents by extending Virtual Router Redundancy Protocol for IPv6. This solution could be transparent to Deng, et al. Expires January 12, 2006 [Page 1] Internet-Draft HA Reliablity & Load Balancing July 2005 Mobile Node to some extent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Deployment Scenario of Multiple HAs for Reliability . . . . . 6 4. VRRPv6 Extensions . . . . . . . . . . . . . . . . . . . . . . 7 4.1 New Parameters per Virtual Router . . . . . . . . . . . . 7 4.2 New State Descriptions . . . . . . . . . . . . . . . . . . 7 4.2.1 Initialize State . . . . . . . . . . . . . . . . . . . 7 4.2.2 Backup State . . . . . . . . . . . . . . . . . . . . . 8 4.2.3 Master State . . . . . . . . . . . . . . . . . . . . . 8 4.3 New VRRP Message Type . . . . . . . . . . . . . . . . . . 8 4.3.1 VRRP_BC_REQUEST message . . . . . . . . . . . . . . . 8 4.3.2 VRRP_BC_UPDATE message . . . . . . . . . . . . . . . . 9 4.3.3 Binding Option Format . . . . . . . . . . . . . . . . 11 5. Redundancy Binding Cache . . . . . . . . . . . . . . . . . . . 12 5.1 Conceptual Data Structure . . . . . . . . . . . . . . . . 12 5.2 Mobile IPv6 Operation . . . . . . . . . . . . . . . . . . 12 5.2.1 Partial Recovery . . . . . . . . . . . . . . . . . . . 12 5.2.2 Full Recovery . . . . . . . . . . . . . . . . . . . . 12 6. Load Balance . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17 9.2 Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 20 Deng, et al. Expires January 12, 2006 [Page 2] Internet-Draft HA Reliablity & Load Balancing July 2005 1. Introduction As specified in [I-D.jfaizan-mipv6-ha-reliability], the failure of a single Home Agent may result in the loss of mobility for numerous Mobile Nodes located throughout the Internet. How to detect and recover from the failure of the Home Agent is the main objective of Mobile IPv6 reliability problem. [I-D.wakikawa-mip6-nemo-haha-spec] and [I-D.jfaizan-mipv6-vhar] proposed several different protocols designed from scratch to realize failure detection of Home Agent. Virtual Router Redundancy Protocol for IPv6 defined in [I-D.ietf-vrrp-ipv6-spec]could support router reliability. In order to avoid recreating the wheel, VRRP is extended in this solution to support failure detection of Home Agent. Meanwhile, the use of VRRP also provides virtual IP address for Home Agent. This virtual IP address could be used in partial recovery from the failure of the Home Agent for Mobile Node. Recovery of Home Agent in reliability solution is expected to be transparent to Mobile Node as VRRP is transparent to network ternimals, which is very difficult to achieve. The use of mandatory IPsec protection for Mobility signals between Mobile Node and Home Agent [RFC3775] is the root of all the difficulties. [I-D.jfaizan- mipv6-vhar] defined a SAD synchronization protocol among multpile Home Agents in order to support Mobile Node transparency in HA recovery. Nevertheless, the nature of IPsec SA make them hard to be synchronized among multiple hosts. SA includes serial number and replay window fields that is updated packet by packet. Synchronization signals would bring considerable traffic among home agents. However, SAD synchronization is not necessary for supporting undiscrupted mobility recovery. The use of IPsec in payload traffic passing through the home agent to the mobile node is optional, as described in [RFC3775] Section 5.5. When IPsec is not used in tunneled traffic, with the virtual IP address provided by VRRP, it is possible that the Backup Home Agent would forward those tunneled traffic both sent from CN to MN and from MN to CN on behalf of the failed Home Agent. Solution specified in [I-D.wakikawa-mip6-nemo- haha-spec] would only forward the traffic from CN to MN, but not forward the traffic from MN to CN through MN-HA tunnel. This is called partial recovery from the failure of the Home Agent and is fully supported in this solution. It should be noted that partial recovery is transparent to the mobile nodes. In order to support partial recovery, binding cache need to be synchronized among one master Home Agent and many backup Home Agents. New VRRP Packet Type is extended to transfer and synchronize Binding Deng, et al. Expires January 12, 2006 [Page 3] Internet-Draft HA Reliablity & Load Balancing July 2005 Cache among Home Agents. Partial recovery will be unavailable when the Mobile Nodes that were served by the failed Home Agent attaches to another link and changes its Care Of Address. A Binding Update signal will be sent by the Mobile Node to its orignal Home Agent, but this signal is encrypted by IPsec SA and could not be decrypted by the backup HA without the appropriate SA. Therefore, in this case, the new Home Agent could not serve the Mobile Node without full recovery. A full recovery from the failure of the Home Agent could be achieved by a bootstrap procedure. The mobile node must bootstrap from the new HA that has taken over the responsibility of its previous failed HA. But the mobile node itself could not initiate the bootstrap because it neither has the knowledge of the failure of HA, nor could be properly inform by any other HA without IPsec SA configured among them. A specific HA initiated Bootstrap solution defined in [I-D.li- mip6-ha-init-bootstrap] is used in this solution for full recovery. This solution also support load balancing among multiple Home Agents. Dynamic home agent assignment could be achieved by sending ha switch signal to mobile node as defined in [I-D.haley-mip6-ha-switch]. Deng, et al. Expires January 12, 2006 [Page 4] Internet-Draft HA Reliablity & Load Balancing July 2005 2. Terminology 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 [RFC2119]. General mobility terminology can be found in [RFC3753]. Security terminology can be found in [RFC2401]. The following additional terms are used here: Virtual Router Redundancy Protocol (VRRP) An election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. VRRP HA A VRRP Router with MIPv6_HA_Mode set to True, and serves as HA. Virtual HA A Virtual Router in VRRP which serves as HA to numerous Mobile Nodes. Virtual HA Address Virtual Router IP Address of a Virtual HA. Redundancy Binding Cache A conceptual data stores in VRRP HA, with a same structure as Binding Cache. Deng, et al. Expires January 12, 2006 [Page 5] Internet-Draft HA Reliablity & Load Balancing July 2005 3. Deployment Scenario of Multiple HAs for Reliability +-------+ +-------+ +-------+ | HA1 | | HA2 | | HA3 | |MasterA| |MasterB| |MasterC| |BackupB| |BackupA| |BackupA| |BackupC| |BackupC| |BackupB| +-------+ +-------+ +-------+ VHA A ---->* VHA B -->* *<---- VHA C | | | | | | ---------------+-----------+-----+--------+--------+--------+- ^ ^ ^ ^ | | | | '`\``\``\``\``\``\``\``\``\``\ { I N T E R N E T } \__\__\__\__\__\__\__\__\__\_/ | | | | (VHA A) (VHA B) (VHA C) (VHA D) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | MN1 | | MN2 | | MN3 | | MN4 | +-----+ +-----+ +--+--+ +--+--+ Legend: ---+---+---+-- = Ethernet, Token Ring, or FDDI MN = Mobile Node HA = Home Agent VHA = Virtual Home Agent (Virtual HA IP) * = IPv6 Address (VHA A) = Home Agent for Mobile Node As we can see from the above figure, more than one Home Agent is deploy in home link. A Virutal Home Agent is a virtual router supported by VRRP, whose virtual router ip address is used as the Home Agent address in Mobile IPv6. A sepecific VRRP HA can attend more than one Virtual HA group, distinguished by VRID. Also one virtual HA group could have more than one HA, with only one master active . Redundancy of HA within a virtual HA group is used to provide HA reliability. Multiple Virtual HA is used to provide load balancing and dynamics HA switch capability. Deng, et al. Expires January 12, 2006 [Page 6] Internet-Draft HA Reliablity & Load Balancing July 2005 4. VRRPv6 Extensions 4.1 New Parameters per Virtual Router New parameters for virutal router are defined in this solution. This section is an extention to section 6.1 in [I-D.ietf-vrrp-ipv6-spec]. MIPv6_HA_Mode Controls whether a VRRP router should act as redundancy Home Agent in Mobile IPv6. If the value of MIPv6_HA_Mode is True, the VRRP router in MASTER state should accept and forward the bidirectional traffic from CN to MN, details could be found in Section 4.2. A VRRP router in MASTER state should also synchronize its Binding Cache to its backups. A VRRP router in BACKUP state should update its Redundancy Binding Cache according to synchronization message, details could be found in Section 4.3 RBC Stands for Redundancy Binding Cache. If A VRRP router is in BACKUP state, it will store Binding Information from VRRP_BC_UPDATE message to to RBC. A Redundancy Binding Cache MUST be located differly with binding cache of master home agent, because the processing of Redundancy Bind Cache is controlled by a specific logic which is totally different than the processing of Mobile IPv6 Binding Cache. Details can be found in Section 4.2. This Redundancy Binding Cache is further explained in Section 5.1 4.2 New State Descriptions New state descriptions associated with the newly defined parameters are provided in this section as an extention to section 6.4 in [I-D.ietf-vrrp-ipv6-spec]. 4.2.1 Initialize State While in this state, a VRRP router MUST do the following: o If MIPv6_HA_Mode is true, then: * VRRP HA MUST Send VRRP_BC_REQUEST message defined in Section 4.3.1 to synchorize current Binding Cache from Virtual HA Master. Deng, et al. Expires January 12, 2006 [Page 7] Internet-Draft HA Reliablity & Load Balancing July 2005 4.2.2 Backup State While in this state, a VRRP router MUST do the following: o If MIPv6_HA_Mode is true, then: * If VRRP HA is the address owner of Virtual HA Address, it MUST Receive VRRP_BC_UPDATE message defined in Section 4.3.2, and synchorize Binding information to Mobile IPv6 Binding Cache. * If VRRP HA is not the address owner of Virtual HA Address, it MUST Receive VRRP_BC_UPDATE message defined in Section 4.3.2, and synchorize Binding information to Redundancy Binding Cache. 4.2.3 Master State While in this state, a VRRP router MUST do the following: o If MIPv6_HA_Mode is true, then: * If VRRP HA is the address owner of Virtual HA IP, when the MIPv6 Binding Cache changes, VRRP HA MUST send VRRP_BC_UPDATE message defined in Section 4.3.2 to backup Home Agents. * If VRRP HA is not the address owner of Virtual HA IP, when the MIPv6 Binding Cache changes, VRRP HA MUST NOT send VRRP_BC_UPDATE message. * When Redundancy Binding Cache changes, VRRP HA MUST send VRRP_BC_UPDATE message which includes only changed entrys. * Upon receiving VRRP_BC_REQUEST message defined in Section 4.3.1, VRRP HA MUST send all entrys in Binding Cache through VRRP_BC_UPDATE message. * VRRP HA MUST Handle Mobile IPv6 related messages as speicified in Section 5.2 4.3 New VRRP Message Type In order to synchronize Binding Update message among multiple Home Agents, this section defines two new VRRP messages. 4.3.1 VRRP_BC_REQUEST message This section defines the format of the VRRP_BC_REQUEST message. The Deng, et al. Expires January 12, 2006 [Page 8] Internet-Draft HA Reliablity & Load Balancing July 2005 relevant fields in the IPv6 header follow the definition in section 5.2 of [I-D.ietf-vrrp-ipv6-spec]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| UNUSED 1 | UNUSED 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(rsvd) | UNUSED 3 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type value must be set to TYPE_VRRP_BC_REQUEST (to be assigned by IANA) Virtual Rtr ID (VRID) The Virtual Router Identifier (VRID) of this Virtual HA. This field MUST be included in the message. UNUSED This field is not used in this type of message, MUST set to 0 by sender, and MUST be ignored by receiver. Other fields follow the definition of section 5.3 in [I-D.ietf-vrrp- ipv6-spec] 4.3.2 VRRP_BC_UPDATE message This section defines the format of the VRRP_BC_UPDATE message. The relevant fields in the IPv6 header follow the definiation in section 5.2 of [I-D.ietf-vrrp-ipv6-spec]. Deng, et al. Expires January 12, 2006 [Page 9] Internet-Draft HA Reliablity & Load Balancing July 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| UNUSED 1 | # of Bindings | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(rsvd) | UNUSED 2 | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Binding(s) | + + + + + + + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type value must be set to TYPE_VRRP_BC_UPDATE (to be assigned by IANA) Virtual Rtr ID (VRID) The Virtual Router Identifier (VRID) of this Virtual HA. This field MUST be included in the message. # of Bindings The number of bindings contained in this VRRP_BC_UPDATE message. The minimum value is 1. UNUSED This field is not used in this type of message, MUST set to 0 by sender, and MUST be ignored by receiver. Binding(s) This fields contains Binding Information. Refer to Section 4.3.3 for the detailed format. Other fields follow the definition of section 5.3 in [I-D.ietf-vrrp- ipv6-spec] Deng, et al. Expires January 12, 2006 [Page 10] Internet-Draft HA Reliablity & Load Balancing July 2005 4.3.3 Binding Option Format This section defines the details of binding option in VRRP_BC_UPDATE message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lifetime, Flags, Sequence Number, Home Address and Care-of Address are directly copied from corrospondent field in Binding Cache entry. Deng, et al. Expires January 12, 2006 [Page 11] Internet-Draft HA Reliablity & Load Balancing July 2005 5. Redundancy Binding Cache Redundancy Binding Cache is a conceptual date model used by VRRP HA to backup the Binding Cache of the Master to the Backups. If the RBC of a VRRP HA is not empty, it means that a certain HA has been failed for some time, some Mobile IPv6 operation MUST be applied to provide different levels of recovery to the Mobile Nodes appeared in the RBC. 5.1 Conceptual Data Structure Redundancy Binding Cache has the same structure with Mobile IPv6 Binding Cache, as defined in section 9.1 in [RFC3775] 5.2 Mobile IPv6 Operation 5.2.1 Partial Recovery As discussed in Section 1, partial recovery could be immediately provided by a VRRP HA that has taken over the responsibility from the failed Virtual HA Master. With partial recovery, bi-directional traffic from MN to CN could be forwarded by new HA, on condition that MN has not changed its CoA since the last HA has failed. Once a Mobile Node changes its CoA after the failure of its original HA (previous Virtual HA Master and address owner of Virtual HA address), or current binding update expires in Redundancy Binding Cache, partial recovery can no longer be provided by new HA (current Virtual HA Master, not Virtual HA address owner). In order to support partial recovery: o A Virtual HA Master MUST accept packets with destination address set to the Home Address of the Mobile Node that exists in Redundancy Bingding Cache. And forward the packets in IPv6 tunnel with source address set to Virtual HA Address and destination address set to the Care of Address of the MN. o A Virtual HA Master MUST accept IPv6 tunnel packets with destination address set to the Virtual HA Address, and source address set to the Home Address of the Mobile Node that exists in Redundancy Bingding Cache. And forward the payload IPv6 packets to CN. 5.2.2 Full Recovery Partial recovery is tranparent to MN, unfortunately it can not last forever. Full recovery could not be transparent to MN but solves all Deng, et al. Expires January 12, 2006 [Page 12] Internet-Draft HA Reliablity & Load Balancing July 2005 the problems. The other problem with full recovery is that it take considerable time and also CPU cycles to recover. Full recovery could be achieved by a new bootstrap as define in [I-D.li-mip6-ha- init-bootstrap]. In order to implement full recovery at appropriate time: o A Virtual HA Master SHOULD NOT full recover all the MN served by the failed HA at the same time. o If A Virtual HA Master received a packet with desitination address address set to Virtual HA address, source address set to the Home Address of the MN exists in RBC, together with a IPv6 destination option which includes the CoA of MN, and the payload type is ESP (potenial Binding Update message encrypted by IPsec SA), the Virtual HA Master MUST schedule a full recovery for the MN and MUST delete binding update associated with the MN in RBC. Deng, et al. Expires January 12, 2006 [Page 13] Internet-Draft HA Reliablity & Load Balancing July 2005 6. Load Balance Home Agent load balance mechanism defined in [I-D.deng-mip6-ha- loadbalance] could be used in this solution to bring dynamic Home Agent load balance to Mobile Node. When a home agent decide to hand off some of its currently served mobile node to a new home agent, HA switch message defined in[I- D.haley-mip6-ha-switch] could be used to inform mobile node. Deng, et al. Expires January 12, 2006 [Page 14] Internet-Draft HA Reliablity & Load Balancing July 2005 7. IANA Considerations This document defines two new VRRP message type TYPE_VRRP_BC_REQUEST TYPE_VRRP_BC_UPDATE Deng, et al. Expires January 12, 2006 [Page 15] Internet-Draft HA Reliablity & Load Balancing July 2005 8. Security Considerations This document does not violate the security requirement for Mobile IPv6 as specified in [RFC3776] In order to support partial recovery in this solution, MN and HA Mobile IPv6 tunnel should not be proctected by IPsec. But this requirement would not bring any security problem to Mobile IPv6 signals between MN and HA. Deng, et al. Expires January 12, 2006 [Page 16] Internet-Draft HA Reliablity & Load Balancing July 2005 9. References 9.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. 9.2 Informative References [I-D.deng-mip6-ha-loadbalance] Deng, H., "Load Balance for Distributed Home Agents in Mobile IPv6", draft-deng-mip6-ha-loadbalance-02 (work in progress), October 2004. [I-D.devarapalli-mip6-nemo-local-haha] Devarapalli, V., "Local HA to HA protocol", draft-devarapalli-mip6-nemo-local-haha-00 (work in progress), July 2005. [I-D.haley-mip6-ha-switch] Haley, B., "Mobility Header Home Agent Switch Message", draft-haley-mip6-ha-switch-00 (work in progress), April 2005. [I-D.ietf-vrrp-ipv6-spec] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", draft-ietf-vrrp-ipv6-spec-07 (work in progress), October 2004. [I-D.jfaizan-mipv6-ha-reliability] Faizan, J., "Problem Statement: Home Agent Reliability", draft-jfaizan-mipv6-ha-reliability-01 (work in progress), February 2004. [I-D.jfaizan-mipv6-vhar] Deng, et al. Expires January 12, 2006 [Page 17] Internet-Draft HA Reliablity & Load Balancing July 2005 El-Rewini, H., Khalil, M., and J. Faizan, "Virtual Home Agent Reliability Protocol (VHAR)", draft-jfaizan-mipv6-vhar-02 (work in progress), April 2004. [I-D.li-mip6-ha-init-bootstrap] Li, Q. and H. Deng, "Home Agent Initiated Bootstrap for Mobile IPv6", draft-li-mip6-ha-init-bootstrap-00 (work in progress), July 2005. [I-D.wakikawa-mip6-nemo-haha-spec] Wakikawa, R., "Inter Home Agents Protocol Specification", draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress), October 2004. Authors' Addresses Hui Deng Hitachi Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Xiaodong Duan China Mobile Research & Development Center, China Mobile Beijing 100053 China Email: duanxiaodong@chinamobile.com Qin Li Beihang University No. 35 Xueyuan Road Haidian District Beijing 100083 China Email: liqin@cse.buaa.edu.cn Deng, et al. Expires January 12, 2006 [Page 18] Internet-Draft HA Reliablity & Load Balancing July 2005 Rong Zhang Academy of Guangdong Tolecom Co. Ltd Guangzhou 510630 China Email: zhangr@gsta.com Deng, et al. Expires January 12, 2006 [Page 19] Internet-Draft HA Reliablity & Load Balancing July 2005 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 (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Deng, et al. Expires January 12, 2006 [Page 20]