[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/