Internet DRAFT - draft-wakikawa-mext-global-haha-spec

draft-wakikawa-mext-global-haha-spec






MEXT Working Group                                           R. Wakikawa
Internet-Draft                                                  R. Kuntz
Intended status: Experimental                                 Toyota ITC
Expires: March 5, 2012                                            Z. Zhu
                                                                L. Zhang
                                                                    UCLA
                                                       September 2, 2011


                 Global HA to HA Protocol Specification
                draft-wakikawa-mext-global-haha-spec-02

Abstract

   This document presents a revised version of the global HAHA protocol
   specification.  Global HAHA allows the deployment of Home Agents over
   the Internet for reliability, scalability and performance purposes.
   This version clarifies several issues that were vague in the original
   specification.  Global HAHA makes use of the signaling defined by the
   Home Agent Reliability protocol (HARP) although it is not designed to
   operate in conjunction with HARP.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on March 5, 2012.

Copyright Notice

   Copyright (c) 2011 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Wakikawa, et al.          Expires March 5, 2012                 [Page 1]

Internet-Draft          Global HAHA Specification         September 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

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

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Initial Binding Registration . . . . . . . . . . . . . . .  9
     3.2.  Primary Home Agent Switch  . . . . . . . . . . . . . . . .  9
     3.3.  Routing Packets  . . . . . . . . . . . . . . . . . . . . . 10
     3.4.  Differences between global HAHA and HARP . . . . . . . . . 11

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

   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 HARP Message  . . . . . . . . . . . . . . . . 15
       5.2.3.  Sending Home Agent Hello Messages  . . . . . . . . . . 16
       5.2.4.  Receiving Hello Message  . . . . . . . . . . . . . . . 16
     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  . . . . . . . . . . . . . 19
     5.5.  Primary Home Agent Switch  . . . . . . . . . . . . . . . . 21
     5.6.  Packet Interception and Delivery . . . . . . . . . . . . . 22
     5.7.  Home Agents Discovery  . . . . . . . . . . . . . . . . . . 23

   6.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 24

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 26



Wakikawa, et al.          Expires March 5, 2012                 [Page 2]

Internet-Draft          Global HAHA Specification         September 2011


     9.2.  Informative References . . . . . . . . . . . . . . . . . . 26

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
















































Wakikawa, et al.          Expires March 5, 2012                 [Page 3]

Internet-Draft          Global HAHA Specification         September 2011


1.  Introduction

   The global HAHA protocol aims at leveraging the global deployment of
   Home Agents over the Internet, by proposing reliability, scalability
   and better performances to Mobile IPv6 [RFC6275] deployments.

   The original global HAHA protocol [I-D.thubert-mext-global-haha] has
   been discussed for several years in MIP6, NEMO and now MEXT working
   groups.  Several documents [I-D.thubert-mext-global-haha]
   [I-D.wakikawa-mip6-nemo-haha-spec]
   [I-D.wakikawa-mext-haha-interop2008] have been published and
   presented 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 [I-D.thubert-mext-global-haha].

   Global HAHA makes use of the signaling defined by the Home Agent
   Reliability protocol (HARP) [I-D.ietf-mip6-hareliability] which is
   being standardized in the MEXT working group.  On one hand, HARP
   provides a redundancy mechanism for the Home Agents located on the
   same layer-2 link (or in different layer-2 links provided that proper
   routing updates are performed between links upon failure).  On the
   other hand, global HAHA builds on anycast routing to not only provide
   redundancy but also achieve a better distributed mobility management
   for Mobile IPv6.  More specifically, global HAHA provides the
   following advantages:

   o  It eliminates the single point of failure and bottleneck in Mobile
      IPv6 and NEMO protocols.  By distributing multiple Home Agents
      over wide areas, scalability and robustness of the mobility
      infrastructure can be improved.

   o  It provides very flexible deployment schemes.  When home agents
      are placed at Internet Exchange Points, they can improve the
      performances of mobility over long distances (such as depicted in
      aeronautics scenarios [RFC5522]) by minimizing triangle routing as
      compared to the path utilizing a single home agent (so called dog-
      leg routing).  Alternatively, when home agents are placed closer
      to the edge of the network, a more flat design can be achieved.
      Offloading near the edge of the network becomes possible, to the
      benefit of the core network load [I-D.kuntz-dmm-summary].

   o  It makes use of existing protocols (HARP signaling
      [I-D.ietf-mip6-hareliability], Home Agent Switch messages
      [RFC5142]) while confining the required changed to the home agent
      only.

   Global HAHA also provides reliability in case of a home agent



Wakikawa, et al.          Expires March 5, 2012                 [Page 4]

Internet-Draft          Global HAHA Specification         September 2011


   failure.  Whether it would be useful to be able to combine HARP with
   global HAHA for local reliability of a home agent is open for future
   discussion.  Such combination can bring better performances in cases
   that may be unlikely to happen often, at the cost of an increased
   complexity.  Furthermore, whether Global HAHA should be independent
   from HARP and define its own signaling protocol is also open for
   further discussion.

   The global HAHA concept has been evaluated through prototype
   implementations in several places [PAPER-CONEXT] and the results show
   that the design is simple and effective in reducing triangle routing.
   Several industry sectors such as aviation [RFC5522] and automobile
   [I-D.ietf-mext-nemo-ro-automotive-req] have shown their interests in
   using global HAHA to meet the need for their mobility managements.

   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 a concern on routing scalability, and it
   introduces additional 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 March 5, 2012                 [Page 5]

Internet-Draft          Global HAHA Specification         September 2011


2.  Terminology

   This document uses terms defined in [RFC3753], [RFC6275], [RFC3963]
   and and [I-D.ietf-mip6-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 unicast
      address (defined below) 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 unicast address

      A unicast IP address created from the home subnet prefix and
      assigned to a home agent.  This is the address used by Mobile
      nodes when sending Binding Updates to their Home Agent.

   Home agent locator address

      A unicast 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.

   Home agent anycast address

      The anycast address defined as per [RFC2526] and used by mobile
      nodes for Dynamic Home Agent Address Discovery purposes.

   Global home agent set

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

   HAHA link

      All the home agents in the same global home agent set share the
      same home subnet prefix although they may be located 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.  Data packets and Binding Updates that need to be



Wakikawa, et al.          Expires March 5, 2012                 [Page 6]

Internet-Draft          Global HAHA Specification         September 2011


      forwarded between home agents are sent over these HAHA links.

   Primary Home Agent

      The home agent which a mobile node is currently registered with.
      Among all the available home agents in the same set, this primary
      home agent should be topologically closest to the mobile node.  At
      any given time 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 receiver
      of this global binging information learns the mapping between the
      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 locator address.  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 March 5, 2012                 [Page 7]

Internet-Draft          Global HAHA Specification         September 2011


3.  Overview

   Global HAHA relies on IP anycast routing between geographically and
   topologically different home agent locations.  The home subnet prefix
   is announced by all the home agents in a deployed global HAHA system,
   so that packets from and to mobile nodes are always routed towards
   the closest home agents in a way that is completely transparent to
   the mobile and correspondent nodes.

   Global HAHA does not require any modification to mobile nodes and
   mobile routers (i.e. end mobile entity).  Supporting Mobile IPv6
   [RFC6275] and Home Agent Switch message [RFC5142] is sufficient to
   run mobile nodes with globally distributed home agents.

   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.


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

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


                     Figure 1: Overview of global HAHA






Wakikawa, et al.          Expires March 5, 2012                 [Page 8]

Internet-Draft          Global HAHA Specification         September 2011


3.1.  Initial Binding Registration

   Global HAHA home agents can be reached by the mobile node through
   both the home agent anycast address (e.g. obtained with Dynamic Home
   Agent Address Discovery [RFC6275]) and the Home agent unicast address
   (e.g. obtained from the DNS) created from the home agent home subnet
   prefix (see Section 5.7).  Note that the home agent locator address
   is not known by the mobile nodes and is only used between global home
   agents to exchange mobility messages among them.

   When the mobile node attempts the binding registration to a home
   agent using the HA anycast address (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.

   After sending a binding Acknowledgment to the mobile node (operation
   2 in Figure 1) and registering a 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 3 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 locator address of 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 from a correspondent node destined to the
   mobile node, it forwards them to the primary home agent (HA1) over
   the HAHA link according to the global binding (operation 4 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 5 in Figure 1).

   If the mobile node obtained the home agent unicast address through
   the DNS, and that address does not correspond to the topologically
   closest home agent, a home agent switch will be performed as
   described in the next section.

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 a mobile
   node's movement.  Thus, the primary home agent of the mobile node
   needs to be updated from HA1 to HA2.  This case can also happen if



Wakikawa, et al.          Expires March 5, 2012                 [Page 9]

Internet-Draft          Global HAHA Specification         September 2011


   the home agent unicast address obtained from the DNS (during the
   bootstrapping phase of the mobile node) is set to HA1 whereas the
   mobile node is initially closer 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
   the first Binding Update to its current primary home agent (i.e.  HA1
   in Figure 1) in order to renew its binding as per [RFC6275].
   However, since HA2 also advertises the same home subnet prefix, the
   Binding Update is first routed to the HA2 by IP anycast routing.  HA2
   knows that HA1 belongs to the same global Home Agent set, and thus
   forwards the Binding Update to its destination (HA1) over the HAHA
   link (operation 6 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 (operation 7 in Figure 1).  In parallel, it triggers
   a Home Agent Switch message [RFC5142] to the mobile node (operation 8
   in Figure 1).  In the Home Agent switch message, the home agent
   unicast address of HA2 is stored in the Home Agent Address field so
   that the mobile node can associate with the closest home agent.

   When the mobile node receives the Home Agent Switch message from the
   HA1, it switches its home agent to the HA2 according to [RFC5142].
   The mobile node sends another Binding Update to the HA2 (operation 9
   in Figure 1).  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 (operation
   10 in Figure 1).  The HA1 removes the binding cache entry of the
   mobile node and creates a global binding as well as the route for the
   mobile node with the next hop set to the locator address of 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 5 and 12 in Figure 1.
   They are tunneled to the primary home agent and, then, routed
   directly to the CN.

   On the other hand, the packets originated by the correspondent node



Wakikawa, et al.          Expires March 5, 2012                [Page 10]

Internet-Draft          Global HAHA Specification         September 2011


   are routed to the closest home agent by IP anycast routing as shown
   in operations 4 and 11 in Figure 1.  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.

3.4.  Differences between global HAHA and HARP

   The global HAHA protocol makes use of the signaling defined by the
   Home Agent Reliability protocol (HARP) [I-D.ietf-mip6-hareliability]
   which is being standardized in the MEXT working group.  However,
   global HAHA is not designed to be operated in conjunction with HARP.
   HARP extends Mobile IPv6 [RFC6275] to provide reliability to home
   agents.  Its concept is similar to the router's redundancy protocols
   such as VRRP and HSRP.  When one home agent fails, another standby
   home agent located in the same home link or in a different network
   can immediately take over the function of the failed one, so that
   ongoing sessions of mobile nodes will not be interrupted by any
   single home agent failures.

   Global HAHA can also achieve reliability by relying on IP anycast
   routing.  The home subnet prefix being announced by all the home
   agents, packets from and to mobile nodes can be forwarded to
   remaining functional home agents in a transparent manner.  In
   addition, global HAHA can achieve better scalability and provide
   optimized paths between a mobile node and its correspondents, by
   always associating the nearest home agent to the mobile node.
















Wakikawa, et al.          Expires March 5, 2012                [Page 11]

Internet-Draft          Global HAHA Specification         September 2011


4.  Home Agent Configurations

4.1.  Home Agent and Subnet Distributions

   Figure 2 shows the subnet and home agent 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 out of its own address block to the home
   subnet.  We call this ISP assigned prefix "Locator Prefix" (LP).
   Each home agent has two unicast IP addresses: one from its PI home
   subnet prefix (the "home agent unicast address") and another from its
   provider (the "home agent locator address").  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 destined to any IP address
   that belongs to the home subnet prefix are delivered to the
   topologically closest home agent.


        Home Link1 (2001:db8:0:1::/64)
            HA1
             |
           --+--
             |     /|\ LP-1 Prefix
        +--------+  |
        |  ISP1  |
        +--------+         LP-2 Prefix
             |              -->
        +--------+  +--------+    |
        |Backbone|--|  ISP2  |----+- HA2     Home Link2
        +--------+  +--------+    |      (2001:db8:0:1::/64)
             |
        +--------+
        |  ISP3  |
        +--------+  |  LP-3 Prefix
             |     \|/
           --+--
             |
            HA3
        Home Link3 (2001:db8:0:1::/64)

           HA unicast address (PI)     HA locator address (LP)
    - HA1     2001:db8:0:1::1              LP-1Prefix::1
    - HA2     2001:db8:0:1::2              LP-2Prefix::2
    - HA3     2001:db8:0:1::3              LP-3Prefix::3





Wakikawa, et al.          Expires March 5, 2012                [Page 12]

Internet-Draft          Global HAHA Specification         September 2011


              Figure 2: Home Subnets and Agents Distribution

4.2.  Anycast Routing Consideration

   IP anycast routing has been widely used in recent years.  As
   documented in [RFC4786], 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 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 March 5, 2012                [Page 13]

Internet-Draft          Global HAHA Specification         September 2011


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 (Provider Independent prefix, PI)

   o  An own home agent unicast address (created from the PI)

   o  An own home agent locator address (created from the Locator
      Prefix, LP)

   o  A home agent anycast address for Dynamic Home Agent Address
      discovery mechanism (created as per [RFC2526])

   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 HAHA links 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 data
   packets destined to the mobile node and binding updates coming from
   the mobile node.  Although all the Binding Updates are already
   securely exchanged, it is recommended to secure every packets
   tunneled over this HAHA link.  Note that Home Agent HELLO message and
   State Synchronization message do not need to be tunneled over the
   HAHA link as they can be sent directly using the Home Agent locator
   addresses as source and destination addresses.

   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.  The status exchange is done with a Home
   Agent HELLO message defined in the Home Agent Reliability protocol
   [I-D.ietf-mip6-hareliability].



Wakikawa, et al.          Expires March 5, 2012                [Page 14]

Internet-Draft          Global HAHA Specification         September 2011


5.2.1.  Home Agent List for the global HAHA

   [RFC6275] and [I-D.ietf-mip6-hareliability] specify and extend the
   data structure named the Home Agent List.  This list is used to
   manage home agent information at a same home link.  The following two
   fields introduced in [RFC6275] 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 HARP Message

   This specification defines a new flag for the HARP HA-HELLO message
   (Type 4):


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


                          Figure 3: HARP Message

   Home Agent Preference

      In this specification, a same 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






Wakikawa, et al.          Expires March 5, 2012                [Page 15]

Internet-Draft          Global HAHA Specification         September 2011


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

   Global (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 (Global HA) and R
      (Request) 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 4.3.2.1 of [I-D.ietf-mip6-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 source and destination home agent locator
      addresses.  They MUST belong to the same global home agent set.

   o  It MUST protect HA-HELLO by IPsec ESP.

5.2.4.  Receiving Hello Message

   When a home agent receives HA-HELLO, it follows the verification
   described in Section 4.3.2.2 of [I-D.ietf-mip6-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 MUST be
      discarded.

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




Wakikawa, et al.          Expires March 5, 2012                [Page 16]

Internet-Draft          Global HAHA Specification         September 2011


   o  If the Group ID field of the received HA-HELLO and the receiver's
      Group ID are 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
      locator 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.
   If the receiver does not have any binding cache entry nor global
   binding for this mobile node, it processes the binding update
   according to [RFC6275] and stores a binding cache entry 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 the 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

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

   The binding registration and management are the same as specified in
   [RFC6275].  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.







Wakikawa, et al.          Expires March 5, 2012                [Page 17]

Internet-Draft          Global HAHA Specification         September 2011


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
   [I-D.ietf-mip6-hareliability] described in the next section is used
   to exchange the global bindings among the home agents.

   When a global binding is created, the home agent MAY use proxy
   Neighbor Discovery or IP routing to intercept the packets addressed
   to the mobile node's home address.

   When a global binding is created, the home agent MUST create a mobile
   node's route entry which next hop is set to the locator address of
   the primary home agent.  If a mobile node is a mobile router
   [RFC3963], 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
   [RFC3963] (i.e. the operation of aggregated home network [RFC4887]),
   only a single route for the mobile network prefix is sufficient.







Wakikawa, et al.          Expires March 5, 2012                [Page 18]

Internet-Draft          Global HAHA Specification         September 2011


5.4.2.  Modified State Synchronization Message and Mobility Option

   Figure 4 shows the modified version of the state synchronization (SS)
   message defined in [I-D.ietf-mip6-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 4: State Synchronization Message

   Global (G) flag

      When State Synchronization messages are exchanged for global
      binding registration, the Global flag MUST be set.

   Mobility Options

      The Binding Cache Information Option as defined in
      [I-D.ietf-mip6-hareliability] is mandatory for the State
      Synchronization Request (SS-REQ) message (Type 0) as well as State
      Synchronization Reply (SS-REP) message (Type 1).

      Others options (e.g.  AAA Information option, Vendor Specific
      Mobility option, as well as the others referenced in
      [I-D.ietf-mip6-hareliability]) can be used too.

      The SS Status Option as defined in [I-D.ietf-mip6-hareliability]
      MUST be used in the State Synchronization Reply-Ack (SS-ACK)
      message (Type 2).

5.4.3.  Global Binding Registration

   If a primary home agent sends a SS-REP message for every binding
   registration from a mobile node, it causes certain overhead to
   exchange messages.  Unless the binding information is changed (except



Wakikawa, et al.          Expires March 5, 2012                [Page 19]

Internet-Draft          Global HAHA Specification         September 2011


   for sequence number and lifetime), the state synchronization reply
   message is not necessarily sent per mobile nodes' binding
   refreshment.  A SS-REP message MUST be sent by a primary home agent
   to register a global binding at the following timing:

   o  When a primary home agent registers a binding for a mobile node
      for 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 (Ack) and G (Global) 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 Section 5.4.2 MAY be
      stored in the mobility option field.

   o  IPsec ESP MUST be applied.

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

   o  The source and destination addresses 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 ESP, it MUST 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 the newly defined value [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].



Wakikawa, et al.          Expires March 5, 2012                [Page 20]

Internet-Draft          Global HAHA Specification         September 2011


   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 locator address (i.e. the sender of SS-REP).  If a
      mobile node is a mobile router [RFC3963], 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 [RFC3963] (i.e. the
      operation of aggregated home network [RFC4887], 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
   4.4.3 of [I-D.ietf-mip6-hareliability].  In addition, the following
   rules MUST be applied:

   o  IPsec ESP MUST be applied.

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

   o  The source and destination addresses 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
   exchanges.  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



Wakikawa, et al.          Expires March 5, 2012                [Page 21]

Internet-Draft          Global HAHA Specification         September 2011


   need to start the primary home agent switch.  On the other hand, if
   the binding update is first routed to one of non-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 [RFC5142] for the primary
   home agent switch operation.  How to send the home agent switch
   message is described in [RFC5142] and Section 4.5 of
   [I-D.ietf-mip6-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.
   According to [RFC5142], upon receipt of a Home Agent Switch message,
   the mobile node must delete its home binding by sending a Binding
   Update deregistration message.  However, the mobile node SHOULD NOT
   send this de-registration in this specification, since the previous
   active home agent knows the primary home agent switch by receiving
   the SS-REP.  Although this represents a slight modification of the
   mobile node side, this helps achieving minimum latency of the primary
   home agent switch by eliminating the binding de-registration process.

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 source and destination locator
   addresses 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).





Wakikawa, et al.          Expires March 5, 2012                [Page 22]

Internet-Draft          Global HAHA Specification         September 2011


5.7.  Home Agents Discovery

   When a mobile node boots up and needs to discover a home agent, it
   can either use Dynamic Home Agent Address Discovery (DHAAD) or
   perform a DNS lookup by home agent name or service name as specified
   in [RFC5026].

   In the DHAAD case, the mobile node simply sends a DHAAD request
   message to the home agent anycast address.  In that case, the DHAAD
   request message is routed to the closest home agent via IP anycast
   routing.  The closest home agent SHOULD return its own unicast
   address with the highest priority in the DHAAD reply message so that
   the mobile node can use the closest home agent for its binding
   registration.

   In the DNS case, the lookup by home agent name or service name may
   return either the home agent anycast address or a home agent unicast
   address.  In both cases, the binding update sent by the mobile node
   will reach the closest home agent thanks to IP anycast routing.
   However, in the second case, the binding update may be forwarded by
   that home agent towards the owner of the home agent unicast address
   used in the binding update.  In that case, a primary home agent
   switch may be initiated right after the registration of the mobile
   node.  In order to avoid this case, the DNS may be configured to
   return only the home agent anycast address, or have the necessary
   mechanisms to return the unicast address of the closest home agent
   for the mobile node.
























Wakikawa, et al.          Expires March 5, 2012                [Page 23]

Internet-Draft          Global HAHA Specification         September 2011


6.  IANA considerations

   This document does not contain any actions for the IANA
















































Wakikawa, et al.          Expires March 5, 2012                [Page 24]

Internet-Draft          Global HAHA Specification         September 2011


7.  Security Considerations

   TBA: Section 7 of [I-D.ietf-mip6-hareliability] gives useful
   information.















































Wakikawa, et al.          Expires March 5, 2012                [Page 25]

Internet-Draft          Global HAHA Specification         September 2011


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.


9.  References

9.1.  Normative References

   [I-D.ietf-mip6-hareliability]
              Wakikawa, R., "Home Agent Reliability Protocol (HARP)",
              draft-ietf-mip6-hareliability-09 (work in progress),
              May 2011.

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

   [RFC5142]  Haley, B., Devarapalli, V., Deng, H., and J. Kempf,
              "Mobility Header Home Agent Switch Message", RFC 5142,
              January 2008.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

9.2.  Informative References

   [I-D.ietf-mext-nemo-ro-automotive-req]
              Baldessari, R., Ernst, T., Festag, A., and M. Lenardi,
              "Automotive Industry Requirements for NEMO Route
              Optimization", draft-ietf-mext-nemo-ro-automotive-req-02
              (work in progress), January 2009.

   [I-D.kuntz-dmm-summary]
              Kuntz, R., Sudhakar, D., Wakikawa, R., and L. Zhang, "A
              Summary of Distributed Mobility Management",
              draft-kuntz-dmm-summary-01 (work in progress),
              August 2011.

   [I-D.thubert-mext-global-haha]
              Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA
              to HA protocol", draft-thubert-mext-global-haha-01 (work
              in progress), July 2009.

   [I-D.wakikawa-mext-haha-interop2008]
              Wakikawa, R., Shima, K., and N. Shigechika, "The Global



Wakikawa, et al.          Expires March 5, 2012                [Page 26]

Internet-Draft          Global HAHA Specification         September 2011


              HAHA Operation at the Interop Tokyo 2008",
              draft-wakikawa-mext-haha-interop2008-00 (work in
              progress), July 2008.

   [I-D.wakikawa-mip6-nemo-haha-spec]
              Wakikawa, R., "Inter Home Agents Protocol Specification",
              draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress),
              March 2006.

   [PAPER-CONEXT]
              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
              Agents towards Internet-Scale Mobility Deployments",
              CoNEXT 2006 Conference on Future Networking Technologies,
              December 2006.

   [RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
              Addresses", RFC 2526, March 1999.

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

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

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006.

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

   [RFC4887]  Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
              Mobility Home Network Models", RFC 4887, July 2007.

   [RFC4888]  Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network
              Mobility Route Optimization Problem Statement", RFC 4888,
              July 2007.

   [RFC4889]  Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
              Mobility Route Optimization Solution Space Analysis",
              RFC 4889, July 2007.

   [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
              Bootstrapping in Split Scenario", RFC 5026, October 2007.

   [RFC5522]  Eddy, W., Ivancic, W., and T. Davis, "Network Mobility
              Route Optimization Requirements for Operational Use in
              Aeronautics and Space Exploration Mobile Networks",
              RFC 5522, October 2009.



Wakikawa, et al.          Expires March 5, 2012                [Page 27]

Internet-Draft          Global HAHA Specification         September 2011


Authors' Addresses

   Ryuji Wakikawa
   Toyota InfoTechnology Center USA, Inc.
   465 Bernardo Ave
   Mountain View, California  94045
   USA

   Email: ryuji@us.toyota-itc.com


   Romain Kuntz
   Toyota InfoTechnology Center USA, Inc.
   465 Bernardo Ave
   Mountain View, California  94045
   USA

   Email: rkuntz@us.toyota-itc.com


   Zhenkai Zhu
   UCLA
   420 Westwood Plaza
   Los Angeles, California  90095
   USA

   Email: zhenkai@cs.ucla.edu


   Lixia Zhang
   UCLA
   3713 Boelter Hall
   Los Angeles, California  90095-1596
   USA

   Email: lixia@cs.ucla.edu















Wakikawa, et al.          Expires March 5, 2012                [Page 28]