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