INTERNET-DRAFT                                                  Hui Deng
INTERNET-DRAFT
<draft-deng-mip6-ha-loadbalance-02.txt>                  Hitachi (China)Investment Ltd.
<draft-deng-mip6-ha-loadbalance-01.txt> (China)
Date: October 2004                                           Brian Haley
                                                 Hewlett-Packard Company
                                                           Xiaodong Duan
                                                            China Mobile
                                                              Rong Zhang
                                                           China Telecom
							  Xiaolong Huang
                                 University of California at Los Angeles
                                                               Kai Zhang
                                                     Tsinghua University
Expires: October 2004                                         April 2004

           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 This document is an Internet-Draft and is subject to all provisions Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of Section 10 which I am aware have been disclosed,
   and any of RFC2026. 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.

   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
   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
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document specifies the dynamical a dynamic load balance of mechanism
   which take among
   multiple home agents by taking into account acceptable number of not only the
   mobile node registration
   information but also data the tunneled data traffic information nodes for each home agent up to
   effectively release and prevent now, with the formation goal of the
   reducing and preventing traffic
   bottleneck 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.

                            TABLE OF CONTENTS

Status of This Memo ...............................................    i
      1.   Introduction........................................... 3   Introduction............................................... 1
      2.   Terminology............................................ 3   Terminology................................................ 1
      3.   Previous work.......................................... 4
      4.   Multiple Home Agents................................... 5
      5. Agents....................................... 2
      4.   Modified Home Agents List.............................. 6
      6.   Modified Router Advertisement Message.................. 7
      7. List.................................. 3
      5.   New Load Balance Information Option Format............. 8
      8. Format................. 3
      6.   Home Agent Reassignment................................ 9
      9.   Prevention of Duplicate 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 Assignment..........11
      10. Handoff messages.................. 6
      7.   IANA Considerations....................................12
      11. Considerations........................................ 6
      8.   Security Considerations................................13
      12.  Acknowledgements.......................................13
           References.............................................14 Considerations.................................... 7
           References................................................. 8
           Authors' Addresses.....................................14 Addresses......................................... 9
      A.   Changes from Previous Version of the Draft.............14 Draft................. 9
          Intellectual Property and Copyright Statements..........15 Statements..............10

1.  Introduction

   In Mobile IPv6 [1], home agents are responsible reponsible for the registration
   of mobile nodes in the home network, intercepting packets destined
   for them, and tunneling the data these packets to their care-of address.
   When the home agent is supporting a large number of mobile nodes when the mobile nodes are not reachable
   through its home IP addresses tentativly. but it will cause that
   the and
   actively tunneling traffic bottleneck to them, it could become overloaded,
   leading to dropped packets and connections.  Dynamic Home Agent
   Address Discovery (DHAAD) can be formed at a used to find another home agent. When 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 experiences high intensity of the tunneled traffic and might want to reduce the number
   of mobile node registration information. DHAAD has been specified in
   base Mobile IPv6 protocol, but nodes it can is currently supporting.  For example, it might
   be only used for stationary
   load balance among multiple overloaded, it wants to achieve better load-balancing between a
   peer home agents. agent, or it is going offline for service.

   This protocol defines a
   hybrid load balance mechanism among multiple home
   agents which takes account of not only the
   mobile node registration information but also the tunneled data
   traffic information to can 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.

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.

   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 10.1. 4.  The list is used for
    informing mobile nodes during dynamic home agent address discovery.

3.  Previous Work

   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 Handoff (HAH) message

    This HAH message 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 by 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
   multiple home agent redundancy and load-balancing for both Mobile
   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 mobile node
    it should use another 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. 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\
                     /----\                   /   /----\
                                             /

   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.

5.

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  An 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 as specified in ordering the Home Agents List when
      it sends an ICMP Home Agent Address Discovery message.

   Here we [1].

   We extend the Home Agents List to support load balance mechanism, information
   so it can share the traffic registration information among the home agents in
   the home network netowrk 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 for 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 reassignment.

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
                     These options specify the prefixes that are on-link
                     and/or are used for address autoconfiguration.  A
                     router SHOULD include all its on-link prefixes
                     (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
   1-bit router address flag Must be set to guarantee Prefix field
   containing a complete a global IPv6 address of this home agent.
   of The added Option field in the router advertisement should be as
   follows.

7 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            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Queue Size                 |  Registered MN                 Available Mobile Node Number                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type       8
   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.

   Queue Size (2 byte):

      A coarse parameter for the Queue Size in the router's TLT

   Registered MN
   Available Mobile Node Number (2 (4 byte):

      Registered MN

      Available Mobile Node number. If more than 256 MN could register a HA,
      the This field should be a coarse paramter
      parameter for the MN number in the
      router's TLT 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 traffic information exchange more effective, the Unisolicited
   Router Advertisement message with the Traffic Load information
   should Registered Mobile Node
   Information MAY can be sent at time uniformly distributed with in
   [MinRtrAdvInterval, MinRtrAdvInterval + IntervalTLTExtention].

   IntervalTLTExtention IntervalRMMNExtension].

   IntervalRMMNExtension = 2 * MinRtrAdvInterval

   Upon receiving the Router Advertisement with the Traffic Load
   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 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
   since that should place the traffic burden. least-loaded first.

   Home agents MAY include this option in their Router Advertisements.
   This option MUST be silently ignored for other Neighbor Discovery
   messages.

8.
6.  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

6.1 Replace Home Agent Selection

   There are many reasons a paramter indicating the traffic load.

   The home agent may select a new home agent in the Home Agents List
   for might want to reduce the timeout number
   of mobile node according nodes it is currently supporting.  For example, it might be
   overloaded, it wants to our home agent reassignment
   algorithm. If achieve better load-balancing between a new peer
   home agent agent, or it is assigned to the timeout mobile
   node, the going offline for service.

   If another home agent actively sends out an ICMP Reply message offering services is known, its address can be
   communicated to the mobile node without the reception node.  Selection of any ICMP Request message.
   Different from the standard ICMP reply packet, the ICMP here should
   only contain one this replacement home
   agent should follow these steps:

    o it MUST be in the home agent list, which is the
   newly selected home agent, other than contains a list home agent.
   By receiving current Home Agents List known by 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

    o it SHOULD be offering services for same set of home agent field
   and register at prefixes as
      the new current home agent by sending a binding update
   message to

    o it SHOULD be the new most lightly loaded home agent IP address.

   By using the ICMP messages in the DHAAD mechanism, this protocol can
   be implemented as determined from
      information supplied in the IETF Mobile IPv6 draft without any changing of
   the protocols of the communication between home agents and mobile
   nodes. 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. The  A home agent should not frequently select a
   new home agent for the registered mobile node, nodes because the home
   agent handoff
   induces extra control traffic and delays the traffic
   forwarding to the mobile nodes. Thus only could cause a very busy home agent or disruption of
   service.  Therefore, only a potentially very busy highly loaded home agent should proceed to the home agent
   handoff.

   When selecting do
   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 handoff.

6.2 Home Agent Handoff message

   The Home Agent Handoff (HAH) message is used by the home agent selection algorithm. One is the Queue Size field, which
   indicates the current traffic load. Another one is to
   signal the registered mobile node number, which indicates the potential traffic load in
   the future. The home agent it should prevent from having too many
   registered mobile nodes, so that the future traffic burden formed by
   the tunneled traffic use another Home Agent for the registered mobile nodes could be prevented.
   subsequent Binding Updates.  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 Home Agent Handoff message uses the traffic table
      END

   ELSE THEN
      IF (my registered MN number
   MH Type value 8 (TBD).  When this value is top 10% in the traffic table) THEN
         Randomly select a bottom 10% home agent indicated in the traffic table.
      END
   END

   In MH Type
   field, the home agent reassignment, only one format 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 Message Data field in the mobile node is moving from one network to
   another network. Thus a home agent who has more number of registered
   mobile nodes Mobility Header
   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 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 Assignments Address                       +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved

      16-bit field reserved for future use.  The home agent reassignment may induce duplicate home agent
   assignments. When a mobile node subsequently sends more than one
   binding updates value MUST be
      initialized to zero by 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 sender, and MUST be ignored by the
   mobile node.
      receiver.

   Home Agent Address

   The mobile node will only process its Mobile IPv6
   tasks with address of the latest assigned new home agent, while other
   duplicate home agents assigned preferred Home Agent.  If set to the unspecified
   address, the mobile node still sit should do DHAAD to find another Home Agent.

   If no actual options are present in the
   home network without further updates from the mobile node. This
   situation this message, no padding is not allowed to happen, because the duplicate home
   agents cannot correctly forward
   necessary and the traffic Header Len field will be set 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 2.

6.3 Sending Home Agent Handoff Table. The Handoff
   Table is used to record whether a mobile node has been handed over
   to messages

   If another HA in a quite recent time. And if that home agent is known and meets the case, it criteria specific
   in 6.1, its address should discover which HA is the last HA assigned to the mobile
   node. Thus the last assigned HA will still be copied into the HA assigned for
   the mobile node this time. An entry of the Handoff Table has
   following fields.

   Mobile Node Home Agent 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) message.  This field represents whether a
                                    mobile node has been handed over
                                    to another HA in address MUST be a quite recent
                                    time. If that is the case, the
                                    mobile node unicast routable
   address.  Otherwise it should be assigned set to the same home agent as last
                                    assignment.

   New Home Agent Address           This field records the last home
                                    agent assigned unspecified address.

   In order to send a registered
                                    mobile node. It avoids duplicate
                                    home agent assignments. Home Agent 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 message to the registering mobile node,
   the home agent should check 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
   Table.

   If anyone of messages

   After verifying the following conditions is true, packet passes the mobile node authentication requirements,
   it should be regarded processed as eligible to select a new home agent.

   1.   There is no entry for the mobile node in follows:

    o if the handoff table.
   2.   Handing off Home Agent Address field is false. Thus the mobile node has not been
        handed over set to another HA in a quite recent time.
   3.   Handoff expire time is before the current time.

   If unspecified address,
      the mobile node is eligible should perform DHAAD to be assigned a new home agent,
   the home agent selects find a new replacement home
      agent and writes an entry for
   the mobile node into

    o if the Home Agent Handoff Table. The handing off
   field should address is not a unicast routable address, the
      packet MUST be set true, and expire time should cover silently discarded

    o otherwise, the
   subsequent several address should be stored for future binding updates of the mobile nodes.

   If the mobile node is illegible to a new home agent assignment,
   the home agent assigned to

   When the mobile node should be determines it must renew its binding, it SHOULD
   NOT use the new current home
   agent address in agent's address, but instead SHOULD use one
   it learned from the Home Agent Handoff Table, handoff message, DHAAD, or some other mechanism
   outside the home agent
   itself in case scope of no entry being found.

10. 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

11.  Security Considerations

   o  New Mobile Header message, described in  section 6.2

8.  Security Considerations have not been discussed in this draft.

Acknowledgements

   The authors would like

   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 thank Hidenori Inouchi, Shiro Tanabe
   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
   Hitachi Central Research Lab. service for their comments and suggestions. the current mobile nodes.  This
   should be done before attempting any handovers.

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.

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

   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:  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-00.txt:
   draft-deng-mip6-ha-loadbalance-01.txt:

   o  A home agnet list  queue size has been extended to replace traffic load table. deleted for deciding change of the home agent.

   o  A new flag home agnet handover message has been added defined to support load balance information
      in Router Advertisement Message.

IPR Notices make
      home agent proactively notify the mobile node about changing
      of the serving home agent.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in standards-track and standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of claims of rights IPR disclosures made
   available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   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
   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 at
   ietf-ipr@ietf.org.

Disclaimer 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. Validity

   This document and the information contained herein is 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 DISCLAIMS 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." 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.