[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01 02                                                      
MEXT Working Group                                           R. Wakikawa
Internet-Draft                                                Toyota ITC
Intended status: Experimental                                     Z. Zhu
Expires: January 7, 2010                                        L. Zhang
                                                                    UCLA
                                                            July 6, 2009


                 Global HA to HA Protocol Specification
              draft-wakikawa-mext-global-haha-spec-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.







Wakikawa, et al.         Expires January 7, 2010                [Page 1]


Internet-Draft          Global HAHA Specification              July 2009


Abstract

   This document presents a revised version of the global HAHA protocol
   specification.  This version clarified several issues that were vague
   in the original specification.  All the protocol specifications for
   the global HAHA are now added on top of the Home Agent Reliability
   protocol.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Initial Binding Registration . . . . . . . . . . . . . . .  8
     3.2.  Primary Home Agent Switch  . . . . . . . . . . . . . . . .  9
     3.3.  Routing Packets  . . . . . . . . . . . . . . . . . . . . .  9

   4.  Home Agent Configurations  . . . . . . . . . . . . . . . . . . 11
     4.1.  Home Agent and Subnet Distributions  . . . . . . . . . . . 11
     4.2.  Anycast Routing Consideration  . . . . . . . . . . . . . . 12

   5.  Global HAHA Protocol . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  Home Agents Bootstrap  . . . . . . . . . . . . . . . . . . 14
     5.2.  Management of Global Home Agent set  . . . . . . . . . . . 14
       5.2.1.  Home Agent List for the global HAHA  . . . . . . . . . 15
       5.2.2.  Modified Home Agent Hello Message  . . . . . . . . . . 15
       5.2.3.  Sending Home Agent Hello Messages  . . . . . . . . . . 16
       5.2.4.  Receiving Hello Message  . . . . . . . . . . . . . . . 17
     5.3.  Primary Home Agent Receiving Binding Update  . . . . . . . 17
     5.4.  GLobal Binding Management  . . . . . . . . . . . . . . . . 18
       5.4.1.  Global Binding . . . . . . . . . . . . . . . . . . . . 18
       5.4.2.  Modified State Synchronization Message and
               Mobility Option  . . . . . . . . . . . . . . . . . . . 19
       5.4.3.  Global Binding Registration  . . . . . . . . . . . . . 21
     5.5.  Primary Home Agent Switch  . . . . . . . . . . . . . . . . 23
     5.6.  Packet Interception and Delivery . . . . . . . . . . . . . 24
     5.7.  Home Agents Discovery  . . . . . . . . . . . . . . . . . . 24

   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 25

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27

   Appendix A.  References  . . . . . . . . . . . . . . . . . . . . . 27



Wakikawa, et al.         Expires January 7, 2010                [Page 2]


Internet-Draft          Global HAHA Specification              July 2009


     A.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     A.2.  Informative References . . . . . . . . . . . . . . . . . . 27

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28















































Wakikawa, et al.         Expires January 7, 2010                [Page 3]


Internet-Draft          Global HAHA Specification              July 2009


1.  Introduction

   The Global HAHA protocol [ID-HAHA] has been discussed for a few years
   in MIP6, NEMO and now MEXT working group.  We have published several
   documents [ID-HAHA] [ID-HAHAPROTO] [ID-HAHAINTEROP] and presented
   several times in past IETF meetings, and received valuable feedback.
   This document presents a revised version of the global HAHA protocol
   specification.  This version clarified several issues that were vague
   in the original specification [ID-HAHA].  All the protocol
   specifications for the global HAHA are now added on top of the Home
   Agent Reliability protocol [ID-HARELIABILITY] which has been
   standardized at the MEXT working group.

   The global HAHA concept has been evaluated through prototype
   implementations in several places and the results show that the
   design is simple and effective in reducing triangle routing.  Several
   industry sectors such as aviation and automobile have shown their
   interests in using global HAHA to meet the need for their mobility
   managements.  The main advantages of the global HAHA can be
   summarized as follows:

   o  It can provide a more optimized route compared to the non-direct
      path via a single home agent so called dog-leg routing;

   o  It eliminates the single point of failure and bottleneck in Mobile
      IPv6 and NEMO protocols.

   As every coin has two sides, the global HAHA protocol is not an
   exception.  It achieves the above goals through utilizing anycast
   routing, which has raised concerns by various people, and it
   introduces new overheads due to the need to synchronize the mobility
   state among distributed home agents.  By presenting a complete design
   together with the design justifications, we hope that this document
   will help move the discussion towards a converged understanding on
   the pros and cons of the global HAHA protocol.
















Wakikawa, et al.         Expires January 7, 2010                [Page 4]


Internet-Draft          Global HAHA Specification              July 2009


2.  Terminology

   This document uses terms defined in [RFC-3753], [RFC-3775], [RFC-
   3963] and [ID-HARELIABILITY].  A few new terms are also introduced in
   this document:

   Home Subnet Prefix

      It is assigned to a home subnet, and the home agent address of a
      mobile node is assigned out of this prefix block.  In this global
      HAHA specification, the home subnet prefix is assumed to be a
      provider independent prefix.

   Home Agent Address

      An address created from the home subnet prefix and assigned to a
      home agent.

   Home Agent Locator Address

      An IP address assigned to a home agent by the ISP who provides the
      Internet connectivity for the home agent.  This address is used to
      exchange mobility messages between globally distributed home
      agents.

   Global Home Agent Set

      The set of home agents serving the same home subnet prefix.  The
      home agents can be located in topologically or geographically
      different locations.  A global home agent set is identified with a
      16-bit group ID.

   HAHA link

      Because all the home agents in the same global home agent set
      share the same home subnet prefix, yet they may be lcoated in
      different parts on Internet, in order for each of them to reach
      all the others directly as required by IP subnet definition,
      logical connectivity links are created between each pair of home
      agents.  These logical links, called HAHA links. can be realized
      using IP tunnel technologies such as IP tunnel, IPsec tunnel,
      L2TP, PPTP, and so on.

   Primary Home Agent







Wakikawa, et al.         Expires January 7, 2010                [Page 5]


Internet-Draft          Global HAHA Specification              July 2009


      The home agent which a mobile node is currently registered with.
      Among all the available home agent in the same set, this primary
      home agent should be topologically closest to the mobile node.
      Each mobile node has one primary home agent.

   Global Binding

      When a mobile node registers with a primary home agent, the home
      agent notifies this binding, called the global binding, to all the
      other home agents in the same global home agent set.  The
      receivers of this global binding informaiton learns the pair of a
      mobile node and its current primary home agent, and creates a
      route entry for the mobile node with the next hop pointing to the
      primary home agent.  This route entry has a lifetime which can be
      different from the lifetime carried in the original binding
      message.  When the lifetime expires, the route is deleted.



































Wakikawa, et al.         Expires January 7, 2010                [Page 6]


Internet-Draft          Global HAHA Specification              July 2009


3.  Overview

   This protocol is defined as an extension to the Home Agent
   Reliability protocol.  The Home Agent Reliability protocol extends
   Mobile IPv6 [RFC-3775] to provide reliability to home agents at the
   local home link.  Its concept is similar to the router's redundancy
   protocols such as VRRP and HSRP.  When one home agent fails, another
   standby home agent can immediately take over the function of the
   failed one, so that ongoing session of mobile nodes will not be
   interrupted by any single home agent failures.

   Similar to the Home Agent Reliability protocol, the global HAHA
   protocol requires no modification to mobile nodes and mobile routers
   (i.e. end mobile entity).  Supporting Mobile IPv6 [RFC-3775] and Home
   Agent Switch message [RFC-5142] is sufficient to run mobile nodes
   with globally distributed home agents.  However different from the
   Home Agent Reliability protocol, the global HAHA places multiple home
   agents at geographically and topologically different locations and
   can provide uninterrupted services in the face of multiple Home Agent
   failures.  This robustness feature is achieved through the use of IP
   anycast routing, where all the Home Agents in a deployed global HAHA
   system share one anycast address, so that packets from mobile nodes
   can be forwarded to remaining functional home agent in a way that is
   completely transparent to the mobile nodes.

   Figure 1 shows the protocol sequence of the Global HAHA.  As an
   assumption, each home agent in the same global home agent set MUST
   establish HAHA links for interconnecting other home agents.  The
   detail of HAHA link establishment is described in Section 5.1.






















Wakikawa, et al.         Expires January 7, 2010                [Page 7]


Internet-Draft          Global HAHA Specification              July 2009


     MN        HA1       HA2       CN
      |         |         |         |
      |----> (Primary)    |         |   1. Binding Registration
      |         |-------->|         |   2. State Synchronization
      |<========|<========|<--------|   3. From CN to MN
      |========>|------------------>|   4. From MN to CN
      |         |         |         |
      :         :         :         :      MN MOVEMENT
      |         |         |         |
      |------------------+|         |   5. Binding Registration
      |         |<=======+|         |
      |<--------|         |         |   6. Home Agent Switch
      |--------------> (Primary)    |   7. Binding Re-registration
      |         |<--------|         |   8. Binding Notification
      |<==================|<--------|   9. From CN to MN
      |==================>|-------->|  10. From MN to CN
      |         |         |         |

     ==== for tunneling
     ---- for direct packets


                     Figure 1: Overview of Global HAHA

3.1.  Initial Binding Registration

   When the mobile node attempts the binding registration to a home
   agent (operation 1 in Figure 1), the binding update is routed to the
   topologically closest home agent of the mobile node via IP anycast
   routing.  The closest home agent which the mobile node registers its
   binding with is called a primary home agent for the mobile node.
   This specification assumes that the route of home subnet prefix is
   advertised from each of different locations where an HAHA home agent
   resides.  Each HAHA home agent can be reached through both the HAHA
   anycast address and the unicast IP address assigned by the local
   service provider.

   After registering binding cache for the mobile node, the primary home
   agent (HA1) sends State Synchronization messages to all the other
   home agent (i.e.  HA2) in the same global home agent set (operation 2
   in Figure 1).  Then, HA2 creates a global binding for the mobile node
   and creates the mobile node's route entry with the next hop set to
   the primary home agent (HA1).  The global binding needs to be updated
   when a mobile node changes its primary home agent.  It must also be
   refreshed before its lifetime expiration.

   When HA2 receives packets destined to the mobile node, it forwards
   them to the primary home agent (HA1) over the HAHA link according to



Wakikawa, et al.         Expires January 7, 2010                [Page 8]


Internet-Draft          Global HAHA Specification              July 2009


   the global binding (operation 3 in Figure 1).  When a mobile node
   sends data to the correspondent node, the traffic is tunneled to the
   primary home agent, which then routes directly to the destination
   (operation 4 in Figure 1).

3.2.  Primary Home Agent Switch

   In this example, from the routing perspective, the closest home agent
   of the mobile node is now changed from HA1 to HA2 after mobile node's
   movement.  Thus, the primary home agent of the mobile node needs to
   be updated from HA1 to HA2.  The Primary Home Agent switch operation
   consists of two binding updates exchange.  The first binding update
   is used to detect the closer home agent by the current primary home
   agent.  The second binding update is to let the mobile node change
   its primary home agent.

   When a mobile node changes its point of attachment, it simply sends a
   first Binding Update to the current primary home agent (i.e.  HA1 in
   Figure 1) in order to renew its binding as [RFC-3775].  However, HA2
   also advertises the home subnet prefix which is the same prefix of
   the binding update's destination address (HA1's home agent address),
   the Binding Update is first routed to the HA2 by IP anycast routing
   and then forwarded to its destination (HA1) over the HAHA link by HA2
   (operation 5 in Figure 1).

   Due to fact that the binding update is forwarded from one of other
   home agents in the same global home agent set, the HA1 now detects
   that the primary home agent is changed to the HA2.  The HA1 first
   processes the Binding Update and returns a Binding Acknowledgment to
   the mobile node.  In parallel, it triggers a Home Agent Switch
   message [RFC-5142] to the mobile node.  In the Home Agent switch
   message, the address of the HA2 is stored in the Home Agent Address
   field so that the mobile node can associate with the closest home
   agent (operation 6 in Figure 1).

   When the mobile node receives the Home Agent Switch message from the
   HA1, it switches its home agent to the HA2 according to [RFC-5142] .
   The mobile node sends another Binding Update to the HA2.  After
   receiving the Binding Update, the HA2 creates the binding cache and
   sends a State Synchronization message to the other Home Agents (i.e.
   HA1) in the global home agent set.  The HA1 removes the binding cache
   entry of the mobile node and creates the route for the mobile node
   with the next hop set to the HA2 over the HAHA link.

3.3.  Routing Packets

   The packets originated by the mobile node are always routed through
   the primary home agent as shown in operations 3, 4, 9, 10 in



Wakikawa, et al.         Expires January 7, 2010                [Page 9]


Internet-Draft          Global HAHA Specification              July 2009


   Figure 1.  They are tunneled to the primary home agent to which the
   mobile node is currently registering and, then, routed directly to
   the CN.

   On the other hand, the packets originated by the correspondent node
   are routed to the closest home agent by IP anycast routing.  If the
   home agent is not the primary home agent of the mobile node
   (destination), the home agent looks up the global binding and routes
   them to the primary home agent of the mobile node over the HAHA link.
   Then, the primary home agent routes the packets to the mobile node
   over the Mobile IPv6's bi-directional tunnel.

   In some scenario, the path between a mobile node and a correspondent
   node becomes asymmetric.  In the global HAHA, the primary home agent
   does not have any specific information of the correspondent nodes and
   does not forward the packets to the closest home agent of the
   correspondent node.


































Wakikawa, et al.         Expires January 7, 2010               [Page 10]


Internet-Draft          Global HAHA Specification              July 2009


4.  Home Agent Configurations

4.1.  Home Agent and Subnet Distributions

   Figure 2 shows the home agents located on the same home link as
   introduced in [RFC-3775] and [ID-HARELIABILITY].  Multiple home
   agents are placed on the same home subnet (2001:db8:0:1::/64) and
   standby home agents are prepared for home agent reliability [ID-
   HARELIABILITY].  The home agents are assigned with different IP
   address as an individual home agent address.  The standby home agent
   for HAa, HAa', shares the same IP address with HAa.


          +--------+
          |Internet|
          +--------+
              |
        --+---+---+--Home Link (2001:db8:0:1::/64)
          |   |   |
         HAa HAb (HAa')

            HA Address
    - HAa  2001:db8:0:1::1
    - HAb  2001:db8:0:1::2
    - HAa' 2001:db8:0:1::1 (Standby)


                    Figure 2: Home Agents Distribtuion

   Figure 3 shows the combination of home agents and subnets
   distribution in a global HAHA system.  Home agents are connected to a
   number of subnets located in various places on Internet, they are all
   assigned the same Provider-Independent (PI) prefix as their home
   subnet prefix.  Each home subnet is connected to the global Internet
   through an ISP who also assigns a prefix of out its own address block
   to the home subnet.  We call this ISP assigned prefix "locator
   prefix".  Each home agent has two IP addresses: one from its PI home
   subnet prefix and another from its provider.  Each ISP that hosts a
   HAHA subnet also agrees to announce the HAHA's PI Home subnet prefix
   to the global Internet, so that packets destinated to any of the home
   agent's IP addresses are delivered to the topologically closest home
   agent.









Wakikawa, et al.         Expires January 7, 2010               [Page 11]


Internet-Draft          Global HAHA Specification              July 2009


        Home Link1 (2001:db8:0:1::/64)
      HA1a HA1b (HA1a')
         |   |   |
         ----+----
             |     /|\ PA-1 Prefix
        +--------+  |
        |  ISP1  |
        +--------+         PA-2 Prefix
             |              -->   +- HA2a
        +--------+  +--------+    |
        |Backbone|--|  ISP2  |----+        Home Link2
        +--------+  +--------+    |        (2001:db8:0:1::/64)
             |                    +- (HA2a')
        +--------+
        |  ISP3  |
        +--------+  |  PA-3 Prefix
             |     \|/
        +----+----+
        |         |
     HA3a       (HA3a')
        Home Link3 (2001:db8:0:1::/64)

             HA address (PI)        HA Locator address (PA)
    - HA1a  2001:db8:0:1::1a       PA-1Prefix::1a
    - HA1b  2001:db8:0:1::1b       PA-1Prefix::1b
    - HA1a' 2001:db8:0:1::1a       PA-1Prefix::1a (Standby)

    - HA2a  2001:db8:0:1::2a       PA-2Prefix::2a
    - HA2a' 2001:db8:0:1::2a       PA-2Prefix::2a (Standby)

    - HA3a  2001:db8:0:1::3a       PA-3Prefix::3a
    - HA3a' 2001:db8:0:1::3a       PA-3Prefix::3a (Standby)


              Figure 3: Home Subnets and Agents Distribtuion

4.2.  Anycast Routing Consideration

   IP anycast routing has been widely used in recent years.  As
   documented in RFC4786 [RFC-4786], anycast has become increasingly
   popular for adding redundancy to DNS servers to complement the
   redundancy that the DNS architecture itself already provides.
   Several root DNS server operators have distributed their servers
   widely around the Internet, and DNS queries are directed to the
   nearest functioning servers.  Another popular anycast usage is by web
   service providers, where two or more web farms share the same IP
   prefix, so that when all the sites are up, HTTP requests are
   forwarded to the web servers closest to the browsers; when a site is



Wakikawa, et al.         Expires January 7, 2010               [Page 12]


Internet-Draft          Global HAHA Specification              July 2009


   down, requests are automatically routed to next nearest web farm.
   Anycast routing provides a simple and effective means to provide
   robust services.

   A concept related to anycast is MOAS (Multi-Origin AS) prefixes, they
   are prefixes advertised by more than one origin AS.  A MOAS prefix
   represents an anycast prefix, although the inverse is not necessarily
   true, i.e. an anycast prefix may not be a MOAS prefix if the prefix
   is announced to the routing system by one origin AS out of the AS's
   multiple locations.  Our measurement using BGP data collected by
   RouteViews and RIPE observed about 2000 or so MOAS prefixes in
   today's global routing system, which is a very small percentage of
   the current routing table entries of about 300K entries.

   One basic cost from providing anycast services is an additional entry
   in the global routing table for each anycast prefix.  When the number
   of anycast applications is small, the impact on the global routing
   system scalability is small.  The use of anycast for important
   infrastructure services, such as DNS root servers, is well justified.
   Using anycast to bootstrap other important services may also be
   justified, if the services are globally scoped are commonly used, and
   the number of anycast prefixes needed is small.  However anycast is
   clearly not for everyone or for all applications usage.  It is a
   worthwhile investigation to consider where best to draw the line.



























Wakikawa, et al.         Expires January 7, 2010               [Page 13]


Internet-Draft          Global HAHA Specification              July 2009


5.  Global HAHA Protocol

5.1.  Home Agents Bootstrap

   For the global HAHA protocol, each home agent SHOULD be configured
   with the following information.

   o  An own home subnet prefix

   o  An own home agent address

   o  An own home agent locator address

   o  A home agent anycast address for Dynamic Home Agent Address
      discovery mechanism

   o  A Group ID of own global home agent set

   o  Home Agent locator addresses of all the other home agents in the
      same global home agent set.

   A home agent first establishes a HAHA link with all the other home
   agents.  How to establish a HAHA link is out of scope in this
   document.  For instance, IP tunnel is established between two home
   agent's locator addresses.  This HAHA link is used to exchange Home
   Agent HELLO message, State Synchronization message and data packets
   destined to a mobile node.  Although all the signal packets are
   securely exchanged, it is recommended to secure every packets
   exchanged over this HAHA link.

   As soon as HAHA links are fully ready, the home agent now provides
   its home agent service to a mobile node.  Without HAHA links, a home
   agent SHOULD NOT configure with its home subnet prefix and act as a
   home agent of the home subnet prefix.  The home agent now starts
   sending its Home Agent HELLO message as described in Section 5.2 and
   soliciting global bindings of all the other home agents as discussed
   in Section 5.4.3.

5.2.  Management of Global Home Agent set

   A home agent exchanges its availability with other home agents of the
   same global home agent set.  These status exchange is done with a
   Home Agent HELLO message defined in the Home Agent Reliability
   protocol [ID-HARELIABILITY].  Unlike the Home Agent Reliability
   protocol, geographically separated home agents are operated more
   carefully and their availability should be always confirmed (ex. by
   the Home Agent Reliability protocol).  Therefore, it MAY use longer
   interval value for the hello message exchange, because these messages



Wakikawa, et al.         Expires January 7, 2010               [Page 14]


Internet-Draft          Global HAHA Specification              July 2009


   are exchanged over the network (i.e. not on the same link).

5.2.1.  Home Agent List for the global HAHA

   [RFC-3775] specifies the data structure named the Home Agent List.
   This list is used to manage home agent information at a same home
   link.  In this specification, the home agent list is extended to
   manage geographically distributed home agents.  The following
   information MUST be stored for globally distributed home agents in
   the home agent list.

   o  home agent address(es)

   o  home agent locator address(es)

   o  The remaining lifetime of this Home Agents List entry

   o  Group ID of global home agent set

   The following two fields introduced in [RFC-3775] are not used in
   this specification.

   o  The link-local IP address of a home agent

   o  The preference for this home agent

5.2.2.  Modified Home Agent Hello Message


        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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |          Sequence #           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Home Agent Preference    |      Home Agent Lifetime      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Hello Interval         |   Group ID    |A|R|G|Reserved |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                    Figure 4: Home Agent Hello Message




Wakikawa, et al.         Expires January 7, 2010               [Page 15]


Internet-Draft          Global HAHA Specification              July 2009


   Home Agent Preference

      In this specification, the equal preference value is used among
      home agents in a global home agent set.  A home agent is selected
      by a mobile node according to routing topology (i.e. anycast
      routing), but not by these preference values.  This value SHOULD
      be set to 0.  The receiver SHOULD ignore this value.

   Group Identifier

      This value is used to identify a particular global home agent set.

   G flag

      Global HA flag.  If this flag is set, the home agent sending this
      HA-HELLO message is operated with this specification.

5.2.3.  Sending Home Agent Hello Messages

   Each home agent periodically sends HA-HELLO to the other home agents
   in the same global home agent set.  Each home agent MUST also
   generate HA-HELLO in the following cases:

   o  when a home agent receives a HA-HELLO with the G and R-flag set

   o  When a new home agent boots up, it SHOULD solicit HA-Hello
      messages by sending a HA-HELLO with the G and R-flag set in
      parallel with sending its own HA-HELLO message.

   When a home agent sends HA-HELLO, the following rule MUST be applied
   in addition to the Section 7.3.2 of [ID-HARELIABILITY].

   o  It MUST set G flag in HA-HELLO.

   o  It MUST specify its global home agent set's ID to the Group ID
      field in HA-HELLO.

   o  The source and destination IPv6 addresses of the IPv6 header of
      the HA-HELLO MUST be the home agent locator address.

   o  It SHOULD protect HA-HELLO by IPsec ESP transport mode.  Only if
      HAHA-link is secured enough (ex. dedicated leased line), IPsec can
      be eliminated.








Wakikawa, et al.         Expires January 7, 2010               [Page 16]


Internet-Draft          Global HAHA Specification              July 2009


5.2.4.  Receiving Hello Message

   When a home agent receives HA-HELLO, it follows the verification
   described in Section 7.3.3 of [ID-HARELIABILITY].  In addition to
   this, it MUST process HA-HELLO which G flag is set as follows:

   o  If the HA-HELLO is not protected by IPsec ESP, it SHOULD be
      discarded.

   o  If the source IPv6 address of HA-HELLO is not belong to one of the
      home agents in the redundant home agent set, the HA-HELLO MUST be
      ignored.

   o  If the Group ID field of the received HA-HELLO and the receiver's
      Group ID is different, HA-HELLO MUST be discarded.  HA-HELLO MUST
      NOT be sent to home agents whose Group ID is different from the
      sender.

   o  HA-HELLO satisfying all of above tests MUST be processed by
      receiver.  The receiver copies home agent information in HA-HELLO
      to the corresponding home agent list entry.  The home agent
      address of the sender is retrieved from the Source Address field
      of the IPv6 header of the HA-HELLO.

5.3.  Primary Home Agent Receiving Binding Update

   The binding update sent by a mobile node is routed to the one of home
   agents in the global home agent set according to the anycast routing.
   The receiver of the home agent processes the binding update according
   to [RFC-3775] and stores a binding for the mobile node.  After
   successful binding registration, the home agent becomes a primary
   home agent for the mobile node.  The primary home agent has following
   functional requirements:

   o  Delivering IP packets destined to the mobile node over the bi-
      directional tunnel

   o  Updating the binding according to the mobile node's binding
      refreshment

   o  Notifying the mobile node binding to the other home agents in the
      same global home agent set.

   o  Sending a Home Agent Switch message if another home agent is more
      preferable to be the primary home agent.  Usually, this is
      trigerred by the reception of a valid Binding Update via another
      Home Agent of the Global Home Agent set




Wakikawa, et al.         Expires January 7, 2010               [Page 17]


Internet-Draft          Global HAHA Specification              July 2009


   o  Providing state synchronization information to other home agent of
      the Global home agent set when a binding is created, updated,
      removed or upon request.

   The binding registration and management are same as [RFC-3775].  The
   global HAHA requires to register global bindings of the mobile node
   by sending the state synchronization message to all the other home
   agents as described in the next section.

5.4.  GLobal Binding Management

5.4.1.  Global Binding

   A global binding has the following information.  Any mobile node's
   specific information can be potentially stored in the global binding.
   The aim of this global binding is to forward the data packets of a
   mobile node received at non primary home agent to the primary home
   agent of the mobile node.  It is not used to deliver a packet
   directly to a mobile node from the non primary home agents.
   Therefore, the mobile node's care-of address is not necessary in the
   global binding, more than likely the primary home agent of the mobile
   node is important in the global binding.

   o  The primary home agent locator address

   o  The mobile node's home address

   o  The mobile router's mobile network prefix(es)

   o  The binding sequence number of a binding update

   o  The flags of a binding update

   o  The lifetime of the global binding

   o  The mobile node's care-of address (optional)

   The modified State Synchronization message [ID-HARELIABILITY] is used
   to exchange the global binding among the home agents.

   When a global binding is created, the home agent MAY use proxy
   Neighbor Discovery to intercept the packets addressed to the mobile
   node's home address.  If there is only single home agent at a home
   link, it simply skip the proxy neighbor discovery and intercepts the
   packet according to IP routing.

   When a global binding is created, the home agent MUST create a mobile
   node's route entry which next hop is set to the primary home agent



Wakikawa, et al.         Expires January 7, 2010               [Page 18]


Internet-Draft          Global HAHA Specification              July 2009


   (i.e. the primary home agent locator address).  If a mobile node is a
   mobile router [RFC-3963], the following mobile node's routes are
   created: one for the home address and one per mobile network prefix.
   If the mobile router's home address is derived from its mobile
   network prefix [RFC-3963] (i.e. the operation of aggregated home
   network [RFC-4887]), only a single route for the mobile network
   prefix is sufficient.

5.4.2.  Modified State Synchronization Message and Mobility Option

   Figure 5 shows the modified version of the state synchronization
   message defined in [ID-HARELIABILITY].  A new G flag is introduced to
   explicitly indicate the global binding registration.


        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      |A|G| Reserved  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identifier            |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               .
       .                                                               .
       .                        Mobility Options                       .
       .                                                               .
       .                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                  Figure 5: State Synchronization Message

   Global (G) flag

      When State Synchronization message are exchanged between
      geographically distributed home agents, the global flag MUST be
      set.

   Mobility Options

      The same options introduced in [ID-HAREALIBILITY] can be used in
      SS-REQ.

      The following options can be used in SS-REP:

      *  Binding Cache Information Option (mandatory)

      *  AAA Information Option (optional)




Wakikawa, et al.         Expires January 7, 2010               [Page 19]


Internet-Draft          Global HAHA Specification              July 2009


      *  Vendor Specific Mobility Option (optional)

      The following options can be used in SS-ACK:

      *  SS Status Option (mandatory)

   Figure 6 is a new mobility option of State Synchronization message.
   In the global HAHA, SS-ACK is mandatory for receivers of SS-REP to
   notify the global binding registration status


        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 = TBD  |   Length      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Status       |                  Reserved                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                        Home Address                           |
       +                                                               +
       |                                                               |
       +                                                               +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Figure 6: State Synchronization Status Option

   Type

      8-bit Type value.  The value is TBD.

   Length

      8-bit length value.

   Status

      8 bit Status value of global binding registration.

      *  0: Success

      *  128: Reason unspecified

      *  129: Malformed SS-REP




Wakikawa, et al.         Expires January 7, 2010               [Page 20]


Internet-Draft          Global HAHA Specification              July 2009


      *  130: Not in same global home agent set

      *  131: No Mobility Option

   Reserved

      24 bit Reserved fields

   Home Address

      Corresponding home address of the status code.

5.4.3.  Global Binding Registration

   A State Synchronization Reply message MUST be sent by a primary home
   agent to register a global binding at the following timing.  If a
   primary home agent notifies its State Synchronization Request message
   for every binding registration from a mobile node, it causes certain
   overhead to exchange messages.  Unless the binding information except
   for sequence number and lifetime is changed, the state
   synchronization message isn't necessarily sent per mobile nodes'
   binding refreshment.

   o  when a primary home agent registers a binding for a mobile node at
      the first time.  The primary home agent MUST register a global
      binding to the global home agent set.

   o  when a global binding is expired.  The primary home agent MUST
      refresh the global binding.

   When a primary home agent receives a binding update from a mobile
   node and registers a binding for it, it sends a State Synchronization
   Reply message.  SS-REP is sent to all the other home agents in the
   global home agent set with the following rules.

   o  The A and G flags MUST be set in SS-REP.

   o  At least, one Binding Cache Information Option MUST be stored in
      the mobility option field.  Multiple options can be stored in a
      SS-REP.

   o  Other optional mobility options listed in Figure 5 MAY be stored
      in the mobility option field.

   o  IPsec ESP transport mode SHOULD be applied.  Only if HAHA-link is
      secured enough (ex. dedicated leased line), IPsec can be
      eliminated.




Wakikawa, et al.         Expires January 7, 2010               [Page 21]


Internet-Draft          Global HAHA Specification              July 2009


   o  The source and destination address of the SS-REP MUST be home
      agent locator address.

   o  The source and destination address MUST belong to the same global
      home agent set.

   When a home agent receives the SS-REP, the following rules must be
   applied to the received SS-REP.

   o  If the SS-REP is not protected by IPsec, it SHOULD be discarded.

   o  If no options are carried in SS-REP, the receiver MUST ignore the
      SS-REP and MUST send SS-ACK with the Status Synchronization Status
      option which status value is set to [131: No Mobility Option].

   o  If the sender of SS-REP is not in the same global home agent set,
      the receiver MUST reject the SS-REP and MUST send SS-ACK with the
      Status Synchronization Status option which status value is set to
      [130: Not in same global home agent set].

   o  If the G flag is not set in RR-REP, the receiver MUST ignore the
      SS-REP and MUST send SS-ACK with the Status Synchronization Status
      option which status value is set to [129: Malformed SS-REP].

   o  If no errors are found in SS-REP, the receiver MUST register or
      update the global binding per Binding Cache Information Option.
      If the supplemental mobility options are specified for a mobile
      node, the information MUST be stored in the global binding.

   o  After the successful global binding registration, it MUST create a
      mobile node's route entry which next hop is set to the primary
      home agent (i.e. the sender of SS-REP).  If a mobile node is a
      mobile router [RFC-3963], the following mobile node's routes are
      created: one for the home address and one per mobile network
      prefix.  If the mobile router's home address is derived from its
      mobile network prefix [RFC-3963] (i.e. the operation of aggregated
      home network [RFC-4887]), only a single route for the mobile
      network prefix is sufficient.

   o  The receiver of SS-REP then sends SS-ACK with state
      synchronization status mobility options for all the mobile nodes
      registering its global binding.

   When a home agent needs to solicit SS-REP, it can send SS-REQ to a
   home agent.  The rules to construct SS-REQ is described in Section
   7.4.1 of [ID-HARELIABILITY].  In addition, the following rules MUST
   be applied:




Wakikawa, et al.         Expires January 7, 2010               [Page 22]


Internet-Draft          Global HAHA Specification              July 2009


   o  IPsec ESP transport mode SHOULD be applied.  Only if HAHA-link is
      secured enough (ex. dedicated leased line), IPsec can be
      eliminated.

   o  The source and destination address of the SS-REQ MUST be home
      agent locator address.

   o  The source and destination address MUST belong to the same global
      home agent set.

5.5.  Primary Home Agent Switch

   Primary Home Agent switch operation consists of two binding update
   exchange.  The first binding update is basically used by a primary
   home agent to detect the better home agent in the same global home
   agent set and to trigger sending a home agent switch message to
   mobile nodes.  The second one is to complete primary home agent
   switch by registering the binding to the new primary home agent.

   When a mobile node moves, it sends a binding update to its primary
   home agent currently registering the binding.  If The binding update
   is directly routed to the destination (i.e. home agent), there is no
   need to start the primary home agent switch.  On the other hand, if
   the binding update is first routed to one of not primary home agents,
   the receiver of the binding update SHOULD become the primary home
   agent of the mobile node from the routing perspective.  The receiver
   does not operate any inspection of the binding update and simply
   forwards it to the destination address of the binding update over the
   HAHA link.

   Once the primary home agent receives the binding update forwarded by
   one of home agents in the same global home agent set, it processes
   the binding update as described in Section 5.3.  In addition, it
   starts sending a home agent switch message [RFC-5142] for the primary
   home agent switch operation.  How to send the home agent switch
   message is described in [RFC-5142] and Section 9 of [ID-
   HARELIABILITY].

   The mobile node receiving the home agent switch message simply
   updates its home agent address and re-registers its binding to the
   new primary home agent.  The new primary home agent sends SS-REP to
   all the other home agents to update its global binding.  After
   receiving SS-REP, the previous primary home agent SHOULD delete its
   original binding and create a global binding for the mobile node.







Wakikawa, et al.         Expires January 7, 2010               [Page 23]


Internet-Draft          Global HAHA Specification              July 2009


5.6.  Packet Interception and Delivery

   When a home agent receives a packet destined to a mobile node, it
   first check the binding cache.  If it finds an original binding, it
   tunnels the packet to the mobile node over the bi-directional tunnel.
   Otherwise, it checks the global binding of the mobile node.  If it
   finds the global binding, it then routes the packet to the primary
   home agent recorded in the global binding over the HAHA link.  The
   packet is delivered to the primary home agent by IP encapsulation.
   In the outer IP header, the home agent locator address should be
   used.  If neither a binding nor a global binding is found, the packet
   MUST be simply discarded.  The home agent SHOULD return an ICMP
   Destination Unreachable, Code 3, message to the packet's Source
   Address (unless this Source Address is a multicast address).

5.7.  Home Agents Discovery

   When a mobile node boots up and needs to discover a home agent, it
   simply sends a dynamic home agent address discovery message to the
   home agent's anycast address.  In that case, the dynamic home agent
   address discovery message is routed to the closest home agent.  The
   closest home agent SHOULD return its own address with the highest
   priority in the dynamic home agent address reply message so that the
   mobile node can use the closet home agent for its binding
   registration.

   Alternatively, it discovers a home agent from DNS server.
























Wakikawa, et al.         Expires January 7, 2010               [Page 24]


Internet-Draft          Global HAHA Specification              July 2009


6.  IANA considerations

   TBA
















































Wakikawa, et al.         Expires January 7, 2010               [Page 25]


Internet-Draft          Global HAHA Specification              July 2009


7.  Security Considerations

   TBA: Section 10 of [ID-HARELIABILITY] gives useful information.
















































Wakikawa, et al.         Expires January 7, 2010               [Page 26]


Internet-Draft          Global HAHA Specification              July 2009


8.  Acknowledgements

   We would like to thank to Pascal Thubert and Vijay Devarapalli for
   the original discussion of the global HAHA.  We also thank to Arnaud
   Ebalard for his review and valuable comments.


Appendix A.  References


A.1.  Normative References

A.2.  Informative References

   [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
   in IPv6", RFC 3775, June 2004.

   [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
   Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
   January 2005.

   [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
   RFC 3753, June 2004.

   [RFC-2991] D. Thaler and C. Hopps, "Multipath Issues in Unicast and
   Multicast Next-Hop Selection", RFC 2991, November 2000.

   [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
   Terminology", RFC 4885, July 2007.

   [RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization
   Problem Statement", RFC 4888, July 2007.

   [RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization
   Solution Space Analysis", RFC 4889, July 2007.

   [RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message",
   RFC 5142, November 2007.

   [RFC-4786] J. Abley, and K. Lindqvist, "Operation of Anycast
   Services", RFC 4886, December 2006

   [RFC-4887] Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli,
   "Network Mobility Home Network Models", RFC 4887, April 2007.

   [ID-HARELIABILITY] Wakikawa, R. (Editor), "Home Agent Reliability
   Protocol", draft-ietf-mip6-hareliability-04.txt (work in progress),
   July 2008.



Wakikawa, et al.         Expires January 7, 2010               [Page 27]


Internet-Draft          Global HAHA Specification              July 2009


   [ID-HAHA] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA
   to HA protocol", draft-thubert-mext-global-haha-00.txt (Work in
   Progress), March 2008

   [ID-HAHAPROTO] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter
   Home Agents Protocol Specification",
   draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), March 2006.

   [ID-HAHAINTEROP] Wakikawa, K. Shima, and N. Shigechika, "The Global
   HAHA Operation at the Interop Tokyo 2008",
   draft-wakikawa-mext-haha-interop2008-00.txt (work in progress), July
   2008.

   [ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements
   for Operational Use in Aeronautics and Space Exploration Mobile
   Networks", draft-ietf-mext-aero-reqs-03.txt, January 2009.

   [ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements
   for NEMO Route Optimization",
   draft-ietf-mext-nemo-ro-automotive-req-02.txt, January 2009.

   [PAPER-CONEXT] Ryuji wakikawa, Guillaume Valadon, Jun Murai.,
   "Migrating Home Agents towards Internet-Scale Mobility Deployments",
   ACM 2nd CoNEXT Conference on Future Networking Technologies, Lisbon,
   Portugal. 4-7 December 2006



Authors' Addresses

   Ryuji Wakikawa
   Toyota ITC / Keio University
   6-6-20 Akasaka, Minato-ku
   Tokyo  107-0052
   Japan

   Phone: +81-3-5561-8276
   Fax:   +81-3-5561-8292
   Email: ryuji@jp.toyota-itc.com












Wakikawa, et al.         Expires January 7, 2010               [Page 28]


Internet-Draft          Global HAHA Specification              July 2009


   Zhenkai Zhu
   UCLA
   420 Westwood Plaza
   Los Angeles, CA  90095
   US

   Phone: +1 310 993 7128
   Email: zhenkai@cs.ucla.edu


   Lixia Zhang
   UCLA
   3713 Boelter Hall, UCLA
   Los Angeles, CA  90095
   US

   Phone: +1 310 825 2695
   Email: lixia@cs.ucla.edu

































Wakikawa, et al.         Expires January 7, 2010               [Page 29]