Internet DRAFT - draft-deng-mip6-vrrp-homeagent-reliability
draft-deng-mip6-vrrp-homeagent-reliability
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]
