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