< draft-deng-mip6-ha-loadbalance-01.txt		draft-deng-mip6-ha-loadbalance-02.txt >
			INTERNET-DRAFT Hui Deng
	Hui Deng		<draft-deng-mip6-ha-loadbalance-02.txt> Hitachi (China)
	INTERNET-DRAFT Hitachi (China)Investment Ltd.		Date: October 2004 Brian Haley
	<draft-deng-mip6-ha-loadbalance-01.txt> Rong Zhang		Hewlett-Packard Company
	China Telecom		Xiaodong Duan
	Xiaolong Huang		China Mobile
	University of California at Los Angeles		Rong Zhang
			China Telecom
	Kai Zhang		Kai Zhang
	Tsinghua University		Tsinghua University
	Expires: October 2004 April 2004
	Load Balance for Distributed Home Agents in Mobile IPv6		Load Balance for Distributed Home Agents in Mobile IPv6
	draft-deng-mip6-ha-loadbalance-01.txt		draft-deng-mip6-ha-loadbalance-02.txt
	Status of this memo		Status of This Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, I certify that any applicable
	of Section 10 of RFC2026.		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		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html.
			Copyright Notice
			Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This document specifies the dynamical load balance of mechanism		This document specifies a dynamic load balance mechanism among
	which take account of not only the mobile node registration		multiple home agents by taking into account acceptable number of
	information but also data the tunneled data traffic information to		mobile nodes for each home agent up to now, with the goal of
	effectively release and prevent the formation of the traffic		reducing and preventing traffic bottlenecks at the home agent.
	bottleneck 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.
	TABLE OF CONTENTS		TABLE OF CONTENTS
	1. Introduction........................................... 3		Status of This Memo ............................................... i
	2. Terminology............................................ 3		1. Introduction............................................... 1
	3. Previous work.......................................... 4		2. Terminology................................................ 1
	4. Multiple Home Agents................................... 5		3. Multiple Home Agents....................................... 2
	5. Modified Home Agents List.............................. 6		4. Modified Home Agents List.................................. 3
	6. Modified Router Advertisement Message.................. 7		5. New Load Balance Information Option Format................. 3
	7. New Load Balance Information Option Format............. 8		6. Home Agent Reassignment.................................... 4
	8. Home Agent Reassignment................................ 9		6.1 Replace Home Agent Selection........................... 4
	9. Prevention of Duplicate Home Agent Assignment..........11		6.2 Home Agent Handoff message............................. 5
	10. IANA Considerations....................................12		6.3 Sending Home Agent Handoff messages.................... 6
	11. Security Considerations................................13		6.4 Receiving Home Agent Handoff messages.................. 6
	12. Acknowledgements.......................................13		7. IANA Considerations........................................ 6
	References.............................................14		8. Security Considerations.................................... 7
	Authors' Addresses.....................................14		References................................................. 8
	A. Changes from Previous Version of the Draft.............14		Authors' Addresses......................................... 9
	Intellectual Property and Copyright Statements..........15		A. Changes from Previous Version of the Draft................. 9
			Intellectual Property and Copyright Statements..............10
	1. Introduction		1. Introduction
	In Mobile IPv6 [1], home agents are responsible for the registration		In Mobile IPv6 [1], home agents are reponsible for the registration
	of mobile nodes in the home network, and tunneling the data		of mobile nodes in the home network, intercepting packets destined
	packets to the mobile nodes when the mobile nodes are not reachable		for them, and tunneling these packets to their care-of address.
	through its home IP addresses tentativly. but it will cause that		When the home agent is supporting a large number of mobile nodes and
	the traffic bottleneck could be formed at a home agent. When the home		actively tunneling traffic to them, it could become overloaded,
	agent experiences high intensity of the tunneled traffic and the		leading to dropped packets and connections. Dynamic Home Agent
	mobile node registration information. DHAAD has been specified in		Address Discovery (DHAAD) can be used to find another home agent,
	base Mobile IPv6 protocol, but it can be only used for stationary		but the mobile node has no way of knowing that it should attempt
	load balance among multiple home agents. This protocol defines a		this method until it has problems contacting its current home agent.
	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		There are many reasons a home agent might want to reduce the number
	models are out of scope for this specification, but the generic		of mobile nodes it is currently supporting. For example, it might
	requirements enabling co-existence of different methods in IPv6 nodes		be overloaded, it wants to achieve better load-balancing between a
	are set forth in section 4.		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		2 Terminology
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	Following terms are not re-defined. They are included for the		Following terms are not re-defined. They are included for the
	convenience of the readers.		convenience of the readers.
	skipping to change at page 4, line 5 ¶		skipping to change at page 2, line 10 ¶
	Mobile Node (MN)		Mobile Node (MN)
	A node that can change its point of attachment from one link to		A node that can change its point of attachment from one link to
	another, while still being reachable via its home address.		another, while still being reachable via its home address.
	Correspondent Node (CN)		Correspondent Node (CN)
	A peer node with which a mobile node is communicating. The		A peer node with which a mobile node is communicating. The
	correspondent node may be either mobile or stationary.		correspondent node may be either mobile or stationary.
	Security Association (SA)		Security Association (SA)
	An IPsec security association is a cooperative relationship formed		An IPsec security association is a cooperative relationship formed
	by the sharing of cryptographic keying material and associated		by the sharing of cryptographic keying material and associated
	context. Security associations are simplex. That is, two		context. Security associations are simplex. That is, two
	security associations are needed to protect bidirectional traffic		security associations are needed to protect bidirectional traffic
	between two nodes, one for each direction.		between two nodes, one for each direction.
	Dynamic Home Agent Address Discovery (DHAAD)		Dynamic Home Agent Address Discovery (DHAAD)
	A protocol which describes how a home agent can help mobile nodes to		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		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		track of the other home agents on the same link, and responds to
	queries sent by the mobile node.		queries sent by the mobile node.
	Home Agents List		Home Agents List
	Home agents need to know which other home agents are on the same		Home agents need to know which other home agents are on the same
	link. This information is stored in the Home Agents List, as		link. This information is stored in the Home Agents List, as
	described in more detail in Section 10.1. The list is used for		described in more detail in Section 4. The list is used for
	informing mobile nodes during dynamic home agent address discovery.		informing mobile nodes during dynamic home agent address discovery.
	3. Previous Work		Home Agent Handoff (HAH) message
	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.
	Inter Home Agents Protocol (HAHA) [7] has been proposed to provide		This HAH message is used by the home agent to signal the mobile node
	multiple home agent redundancy and load-balancing for both Mobile		it should use another Home Agent for subsequent Binding Updates.
	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		3. Multiple Home Agents
	The following Figure gives the topology layout to deploy this		The following Figure gives the topology layout to deploy this
	protocol for distributed home agents		protocol for distributed home agents
	|------------------------------| |----------		|------------------------------| |----------
	| | | |		| | | |
	|---| |---| |---| |---|		|---| |---| |---| |---|
	|HA | |HA | |HA | |FA |		|HA | |HA | |HA | |FA |
	|---| |---| |---| |---|		|---| |---| |---| |---|
	\		\
	skipping to change at page 6, line 5 ¶		skipping to change at page 3, line 17 ¶
	home network is attached with an access router. When the mobile		home network is attached with an access router. When the mobile
	nodes reside in the home network, the home agents do not execute any		nodes reside in the home network, the home agents do not execute any
	home agent tasks.		home agent tasks.
	The home agent assignment of the mobile nodes in the home network		The home agent assignment of the mobile nodes in the home network
	can be either evenly assigned among the multiple HAs or unevenly		can be either evenly assigned among the multiple HAs or unevenly
	assigned. Whether the home agent assignment is even or not would		assigned. Whether the home agent assignment is even or not would
	neither arbitrarily affect the original traffic burden problem nor		neither arbitrarily affect the original traffic burden problem nor
	affect the performance of this protocol.		affect the performance of this protocol.
	5. Modified Home Agents List		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. 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.
	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
	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		Each home agent maintains a separate Home Agents List for each link
	These options specify the prefixes that are on-link		on which it is serving as a home agent. An entry is created in
	and/or are used for address autoconfiguration. A		response to receipt of a valid Router Advertisement in which the
	router SHOULD include all its on-link prefixes		Home Agent (H) bit is set as specified in [1].
	(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		We extend the Home Agents List to support load balance information
	1-bit router address flag Must be set to guarantee Prefix field		so it can share registration information among the home agents in
	containing a complete a global IPv6 address of this home agent.		the home netowrk to make decisions for home agent reassignment.
	of The added Option field in the router advertisement should be as
	follows.
	7 New Load Balance Information Option Format		5 New Load Balance Information Option Format
	Load Balance among multiple home agents defines a new Load Balance		Load Balance among multiple home agents defines a new Load Balance
	Information option, used in Router Advertisements sent by a home		Information option, used in Router Advertisements sent by a home
	agent to advertise information specific to this router's		agent to advertise information specific to this router's
	functionality as a home agent. The format of the Load Balance		functionality as a home agent. The format of the Load Balance
	Information option is as follows:		Information option is as follows:
	0 1 2 3		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		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 |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Queue Size | Registered MN Number |		| Available Mobile Node Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type
	8
			Type 8
	Length		Length
	8-bit unsigned integer. The length of the option (including the		8-bit unsigned integer. The length of the option (including the
	type and length fields) in units of 8 octets. The value of this		type and length fields) in units of 8 octets. The value of this
	field MUST be 1.		field MUST be 1.
	Reserved		Reserved
	This field is unused. It MUST be initialized to zero by the		This field is unused. It MUST be initialized to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
			Available Mobile Node Number (4 byte):
	Queue Size (2 byte):		Available Mobile Node number. This field should be a coarse
			parameter for the number of mobile node home bindings this
	A coarse parameter for the Queue Size in the router's TLT		home agent is able to accept.
	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		Unsolicited Router Advertisement messages should be sent at time
	uniformly distributed within [MinRtrAdvInterval, MaxRtrAdvInterval]		uniformly distributed within [MinRtrAdvInterval, MaxRtrAdvInterval]
	according to [8].		according to [8].
	To make the traffic information more effective, the Unisolicited		To make the information exchange more effective, the Unisolicited
	Router Advertisement message with the Traffic Load information		Router Advertisement message with the Registered Mobile Node
	should be sent at time uniformly distributed with in		Information MAY can be sent at time uniformly distributed with in
	[MinRtrAdvInterval, MinRtrAdvInterval + IntervalTLTExtention].		[MinRtrAdvInterval, MinRtrAdvInterval + IntervalRMMNExtension].
	IntervalTLTExtention = 2 * MinRtrAdvInterval
	Upon receiving the Router Advertisement with the Traffic Load		IntervalRMMNExtension = 2 * MinRtrAdvInterval
	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		The home agent keeps the Home Agents List sorted in ascending order
	home agent reassignment to release the traffic burden, while the		since that should place the least-loaded first.
	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.		Home agents MAY include this option in their Router Advertisements.
	This option MUST be silently ignored for other Neighbor Discovery		This option MUST be silently ignored for other Neighbor Discovery
	messages.		messages.
			6. Home Agent Reassignments
	8. Home Agent Reassignments		6.1 Replace Home Agent Selection
	In this protocol, at each home agent, a timer is attached for each		There are many reasons a a home agent might want to reduce the number
	entry in the binding update cache. When the timer is time out, the		of mobile nodes it is currently supporting. For example, it might be
	mobile node corresponding to the entry is considered to be eligible		overloaded, it wants to achieve better load-balancing between a peer
	for home agent reassignment. The timeout time is called RegTIMEOUT.		home agent, or it is going offline for service.
	RegTIMEOUT = MinRtrAdvInterval / Queue Size Indicator		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:
	Queue Size Indicator is a paramter indicating the traffic load.		o it MUST be in the current Home Agents List known by this home
			agent
	The home agent may select a new home agent in the Home Agents List		o it SHOULD be offering services for same set of home prefixes as
	for the timeout mobile node according to our home agent reassignment		the current home agent
	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		o it SHOULD be the most lightly loaded home agent as determined from
	be implemented in the IETF Mobile IPv6 draft without any changing of		information supplied in a recent Load Balance Information Option
	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		The frequency of selecting a new home agent for the mobile node is a
	tradeoff between the home agent handoff frequency and the load		tradeoff between the home agent handoff frequency and the load
	balance performance. The home agent should not frequently select a		balance performance. A home agent should not frequently select a
	new home agent for the registered mobile node, because the home		new home agent for registered mobile nodes because the handoff
	agent handoff induces extra control traffic and delays the traffic		induces extra control traffic and could cause a disruption of
	forwarding to the mobile nodes. Thus only a very busy home agent or		service. Therefore, only a highly loaded home agent should do
	a potentially very busy home agent should proceed to the home agent		a home agent handoff.
	handoff.
	When selecting a new home agent, the new home agent should be one of		6.2 Home Agent Handoff message
	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.		The Home Agent Handoff (HAH) message is used by the home agent to
	Algorithm. HA Reassignment		signal the mobile node it should use another Home Agent for
	IF (Self Queue Size > LIGHT) THEN		subsequent Binding Updates. The Home Agent Handoff message uses the
	IF (Other HA Queue Size < LIGHT) THEN		MH Type value 8 (TBD). When this value is indicated in the MH Type
	Randomly select a HA with LIGHT Queue.		field, the format of the Message Data field in the Mobility Header
	ELSE IF (Self Queue Size is top 10% in the traffic table) THEN		is as follows:
	Randomly select a bottom 10% home agent in the traffic table
	END
	ELSE THEN		0 1 2 3
	IF (my registered MN number is top 10% in the traffic table) THEN		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
	Randomly select a bottom 10% home agent in the traffic table.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	END		| Reserved |
	END		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ +
			| |
			+ Home Agent Address +
			| |
			+ +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	In the home agent reassignment, only one of the most busy home		Reserved
	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		16-bit field reserved for future use. The value MUST be
			initialized to zero by the sender, and MUST be ignored by the
			receiver.
	The home agent reassignment may induce duplicate home agent		Home Agent Address
	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		The address of the preferred Home Agent. If set to the unspecified
	agent should maintain a Home Agent Handoff Table. The Handoff		address, the mobile node should do DHAAD to find another Home Agent.
	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		If no actual options are present in this message, no padding is
	address of a registered mobile		necessary and the Header Len field will be set to 2.
	node, which sends binding updates
	to the home agent periodically.
	Handing Off (true/false) This field represents whether a		6.3 Sending Home Agent Handoff messages
	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		If another home agent is known and meets the criteria specific
	agent assigned to a registered		in 6.1, its address should be copied into the Home Agent Address
	mobile node. It avoids duplicate		field of the message. This address MUST be a unicast routable
	home agent assignments.		address. Otherwise it should be set to the unspecified address.
	Handoff Expire Time This field represents whether the		In order to send a Home Agent Handoff message to the mobile node,
	Handing Off field of this entry is		the home agent MUST use the IPsec ESP tunnel already established
	valid. If the handoff timer has		for protecting Return Routability traffic as specified in [3].
	expired, the handing off field of		This way the mobile node will avoid being subjected to a denial
	this entry is invalid.		of service attack.
	Before the home agent select a home agent for the registering		6.4 Receiving Home Agent Handoff messages
	mobile node, the home agent should check the Home Agent Handoff
	Table.
	If anyone of the following conditions is true, the mobile node		After verifying the packet passes the authentication requirements,
	should be regarded as eligible to select a new home agent.		it should be processed as follows:
	1. There is no entry for the mobile node in the handoff table.		o if the Home Agent Address field is set to the unspecified address,
	2. Handing off field is false. Thus the mobile node has not been		the mobile node should perform DHAAD to find a replacement home
	handed over to another HA in a quite recent time.		agent
	3. Handoff expire time is before the current time.
	If the mobile node is eligible to be assigned a new home agent,		o if the Home Agent address is not a unicast routable address, the
	the home agent selects a new home agent and writes an entry for		packet MUST be silently discarded
	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,		o otherwise, the address should be stored for future binding updates
	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		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,		This document defines one new Neighbor Discovery [8] options,
	which must be assigned Option Type values within the option numbering		which must be assigned Option Type values within the option numbering
	space for Neighbor Discovery messages:		space for Neighbor Discovery messages:
	o The Load Balance information option		o The Load Balance information option
	11. Security Considerations		o New Mobile Header message, described in section 6.2
	Security Considerations have not been discussed in this draft.		8. Security Considerations
	Acknowledgements		Here we give a example to solve the SA problem based on our proposal.
	The authors would like to thank Hidenori Inouchi, Shiro Tanabe of		Visited Network | Home Network
	Hitachi Central Research Lab. for their comments and suggestions.		| +-------+
			| +--------| 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.
	References		References
	[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement		[1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[2] R. Hinden and S. Deering, "IP Version 6 Addressing		[2] R. Hinden and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 2373, July 1998.		Architecture", RFC 2373, July 1998.
	[3] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in		[3] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
	skipping to change at page 13, line 50 ¶		skipping to change at page 8, line 40 ¶
	[8] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery		[8] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
	for IP Version 6 (IPv6)", RFC 2461, December 1998.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[9] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to Protect		[9] J. Arkko, V. Devarapalli, and F. Dupont, "Using IPsec to Protect
	Mobile IPv6 Signaling between Mobile Nodes and Home Agents",		Mobile IPv6 Signaling between Mobile Nodes and Home Agents",
	draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress),		draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress),
	June 2003.		June 2003.
	[10] D. Maughan, M. Schertler, M. Schneider, and J. Turner,		[10] D. Maughan, M. Schertler, M. Schneider, and J. Turner,
	"Internet Security Association and Key Management Protocol		"Internet Security Association and Key Management Protocol
	(ISAKMP)", RFC 2408, November 1998.		(ISAKMP)", RFC 2408, November 1998.
	[11] A. Conta and S. Deering, "Internet Control Message Protocol		[11] A. Conta and S. Deering, "Internet Control Message Protocol
	(ICMPv6) for the Internet Protocol Version 6 (IPv6)		(ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Specification", RFC 2463, December 1998.		Specification", RFC 2463, December 1998.
	Authors' Addresses		Authors' Addresses
	Hui Deng		Hui Deng
	Research & Development Center		Research & Development Center
	Hitachi (China), Investment Ltd.		Hitachi (China), Investment Ltd.
	Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu		Beijing Fortune Bldg. 1701, 5 Dong San Huan Bei-Lu
	Chao Yang District, Beijing 100004, China		Chao Yang District, Beijing 100004, China
	E-mail: hdeng@hitachi.cn		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		Rong Zhang
	Network Technology Research Division		Network Technology Research Division
	Guangzhou Research and Development Center		Guangzhou Research and Development Center
	China Telecom		China Telecom
	Guangzhou, 510630, China		Guangzhou, 510630, China
	Email: zhangr@gsta.com		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		Kai Zhang
	Network Theory Laboratory.		Network Theory Laboratory.
	Department of Electronic Engineering		Department of Electronic Engineering
	Tsinghua University		Tsinghua University
	Beijing 100084, China		Beijing 100084, China
	Email: zhangkai98@mails.tsinghua.edu.cn		Email: zhangkai98@mails.tsinghua.edu.cn
	Appendix A. Changes from Previous Version of the Draft		Appendix A. Changes from Previous Version of the Draft
	This appendix briefly lists some of the major changes in this draft		This appendix briefly lists some of the major changes in this draft
	relative to the previous version of this same draft,		relative to the previous version of this same draft,
	draft-deng-mip6-ha-loadbalance-00.txt:		draft-deng-mip6-ha-loadbalance-01.txt:
	o A home agnet list has been extended to replace traffic load table.		o queue size has been deleted for deciding change of the home agent.
	o A new flag has been added to support load balance information		o A new home agnet handover message has been defined to make
	in Router Advertisement Message.		home agent proactively notify the mobile node about changing
			of the serving home agent.
	IPR Notices		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of		The IETF takes no position regarding the validity or scope of any
	any intellectual property or other rights that might be claimed		Intellectual Property Rights or other rights that might be claimed to
	to pertain to the implementation or use of the technology		pertain to the implementation or use of the technology described in
	described in this document or the extent to which any license		this document or the extent to which any license under such rights
	under such rights might or might not be available; neither does		might or might not be available; nor does it represent that it has
	it represent that it has made any effort to identify any such		made any independent effort to identify any such rights. Information
	rights. Information on the IETF's procedures with respect to		on the procedures with respect to rights in RFC documents can be
	rights in standards-track and standards-related documentation		found in BCP 78 and BCP 79.
	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		Copies of IPR disclosures made to the IETF Secretariat and any
	attention any copyrights, patents or patent applications, or		assurances of licenses to be made available, or the result of an
	other proprietary rights which may cover technology that may be		attempt made to obtain a general license or permission for the use of
	required to practice this standard. Please address the		such proprietary rights by implementers or users of this
	information to the IETF Executive Director.		specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	Copyright Notice		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.
	Copyright (C) The Internet Society (date). All Rights		Disclaimer of Validity
	Reserved.
	This document and translations of it may be copied and		This document and the information contained herein are provided on an
	furnished to others, and derivative works that comment on or		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	otherwise explain it or assist in its implementation may be		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	prepared, copied, published and distributed, in whole or in		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	part, without restriction of any kind, provided that the above		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	copyright notice and this paragraph are included on all such		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	copies and derivative works. However, this document itself may		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	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		Copyright Statement
	not be revoked by the Internet Society or its successors or
	assigns.
	This document and the information contained herein is provided		Copyright (C) The Internet Society (2004). This document is subject
	on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET		to the rights, licenses and restrictions contained in BCP 78, and
	ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		except as set forth therein, the authors retain all their rights.
	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."
End of changes. 74 change blocks.
	448 lines changed or deleted		252 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/