MEXT                                                          P. Thubert
Internet-Draft                                                     Cisco
Intended status: Standards Track                             R. Wakikawa
Expires: September 19, 2008                              Keio University
                                                          V. Devarapalli
                                                         Azaire Networks
                                                          March 18, 2008


                        Global HA to HA protocol
                   draft-thubert-mext-global-haha-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 September 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This HAHA protocol extends MIPv6 [RFC3775] and NEMO [RFC3963] to
   remove their link layer dependencies on the Home Link and distribute
   the HAs at IP layer.  Global HAHA considers the distribution at the
   scale of the Internet, and introduces the MIP proxy for Local
   Mobility Management and Route Optimization in the Infrastructure.



Thubert, et al.        Expires September 19, 2008               [Page 1]


Internet-Draft                 Global-HAHA                    March 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Motivations  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Layer 3 operations . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Route Optimization . . . . . . . . . . . . . . . . . . . .  5
     2.4.  Single point of failure  . . . . . . . . . . . . . . . . .  8
   3.  Rationale for the proposed solution  . . . . . . . . . . . . .  8
   4.  A proxy for Mobile IP  . . . . . . . . . . . . . . . . . . . .  8
   5.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Initial routing  . . . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  External routing . . . . . . . . . . . . . . . . . . . 11
       5.1.2.  Internal routing . . . . . . . . . . . . . . . . . . . 12
     5.2.  Binding  . . . . . . . . . . . . . . . . . . . . . . . . . 13
       5.2.1.  Direct primary binding . . . . . . . . . . . . . . . . 13
       5.2.2.  local proxy binding  . . . . . . . . . . . . . . . . . 13
       5.2.3.  Foreign proxy binding  . . . . . . . . . . . . . . . . 14
     5.3.  Route Optimizations  . . . . . . . . . . . . . . . . . . . 15
       5.3.1.  Leaking MNP routes in the HAHA network . . . . . . . . 16
       5.3.2.  On-demand proxy routes . . . . . . . . . . . . . . . . 17
   6.  Terminology and concepts . . . . . . . . . . . . . . . . . . . 19
   7.  Distributed Home Network . . . . . . . . . . . . . . . . . . . 21
   8.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  Mobile Router Operation  . . . . . . . . . . . . . . . . . . . 22
     9.1.  Locating Home  . . . . . . . . . . . . . . . . . . . . . . 22
     9.2.  Proxy MIP client . . . . . . . . . . . . . . . . . . . . . 22
   10. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Locating the other HAs that serve the same Home  . . . . . 22
     10.2. Locating the HA that owns the binding for a HoA  . . . . . 22
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   12. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 23
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     14.1. informative reference  . . . . . . . . . . . . . . . . . . 23
     14.2. normative reference  . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25













Thubert, et al.        Expires September 19, 2008               [Page 2]


Internet-Draft                 Global-HAHA                    March 2008


1.  Introduction

   The reader of this document is expected to be familiar with both the
   Mobile IPv6 [RFC3775] and NEMO Basic Support [RFC3963] documents.  As
   such, the reader is expected to understand the concept of a Home Link
   and the Neighbor Discovery related operations that take place over
   that link.

   Home Agent global distribution is useful when a Mobile Router moves
   geographically large area such as airplane, vehicle, etc...  The
   overhead of the basic NEMO protocol is redundant route caused by the
   bi-directional tunnel between a Home Agent and a Mobile Router.  If a
   Mobile Router moves far away from a Home Agent, the overhead can not
   be ignored.

   Thus, it is reasonable to consider that a Mobile Router dynamically
   switches to the topologically closest Home Agent (Home Link).  This
   distribution is also effective for load-balancing.  The Home Agent is
   expected to serve thousands of Mobile Routers on its Home Link and
   tunnels all packets for the Mobile Routers by itself.

   But with NEMO basic support and MIPv6, Home is locally anchored to
   the Home Link at Layer 2, so Home can not be distributed
   geographically.  In particular for NEMO, what's needed is a route to
   a mobile prefix via a tunnel end point that is the CareOf address of
   the Mobile Router.  The Home Address is but a practical artifact that
   is mostly needed as a correlator for the registration.

   This draft proposes a model that enables the HA to HA communication
   at Layer 3, allowing to get rid of the Home Link in configurations
   where it's not needed.

   This draft also introduces the concept of proxy Home Agent, enabling
   a Mobile Router to binding locally as it is roaming far from any of
   its own Home Agents.

   Finally, the draft presents how the Home Agents and the proxy Home
   Agents can use the concept of route projection to improve the data
   path between Mobile Routers.












Thubert, et al.        Expires September 19, 2008               [Page 3]


Internet-Draft                 Global-HAHA                    March 2008


2.  Motivations

2.1.  Requirements

   This draft addresses two generic requirements expressed in the Nemo
   requirements [RFC4886]:

   Local Mobility and Global Mobility:  Multihoming is mentioned as
      desirable.  The global mobility type is not expected to be limited
      for any consideration other than administrative and security
      policies.

   Scalability:  NEMO support signaling and processing is expected to
      scale to a potentially large number of mobile networks.  Thus
      draft extends the scalality of the NEMO basic protocol.

   There is a requirement from airplane companies which want to be at
   Home in the various airports that their planes visit.  In fact, this
   is expressed in an abstract fashion by the case (1,n,1) of the NEMO
   multihoming issues [RFC4980] draft: "Single MR, Multiple HAs, Single
   NEMO-Prefix".

   There is also a general direction that indicates that NEMO could be
   extended as a solution for VPN.  To get there, we must ensure that
   NEMO is upscaled to the classical capabilities of VPN, including the
   global distribution of Points Of Presence.  It is a classical feature
   for VPNs to allow the roaming users to connect to the closest point
   of presence into their company VPN.  The same feature can not be
   provided with MIPv6 or NEMO, because the Home depends on a link that
   has a unique physical location.

2.2.  Layer 3 operations

   Mobile IPv6 [RFC3775] standarizes an interface between a Mobile Node
   and its Home Agent and its correspondents, as well as an interface
   between Home Agents.  One angle of the MIPv6 operation is that the
   protocols hides the MN mobility by making as if the Mobile Node was
   always connected to a Home Link.  The connectivity is maintained by
   Home Agents that are permanently and physically attached to that Home
   Link.

   So the model for MIPv6 is Home Link centric and it is no surprise
   that it extends IPv6 Neighbor Discovery [RFC4861] for its operations,
   in particular for HAs to discover each others, and to discover when
   one of them has a binding for a Mobile Node, and which one.  An
   immediate consequence of being Link centric is that Home can not be
   distributed at Layer 3, locally within a site or over the Internet.




Thubert, et al.        Expires September 19, 2008               [Page 4]


Internet-Draft                 Global-HAHA                    March 2008


   the NEMO Basic Support [RFC3963] inherits the concept of Home Link
   and MIPv6 operations on that link, making NEMO partially a link layer
   operation.  On the other hand, the NEMO Basic Support also operates
   as a routing protocol at L3, for example when it injects routes in
   the explicit prefix mode.  So NEMO operations are somewhat half L2
   and half L3.

   What we are getting at with the HAHA protocol is placing NEMO fully
   at L3.  This mostly means the replacement of all ND based exchanges
   by some equivalent, but at Layer 3, over the Internet Protocol.  This
   also means the abstraction of the concept of Home Address into a
   globally unique router ID, as opposed to an address from a Home Link.

   So even if this paper trivially applies to Mobile IPv6, we place our
   descriptions in the context of NEMO, and use MRs where MIPv6 MNs
   could fit as well.

2.3.  Route Optimization

   MIPv6 comes with a Route Optimization scheme that enables a direct
   MR-CN conversation, bypassing the Home Agent.  With the basic
   support, NEMO does not have such a support yet.  In any case, RO
   comes at an additional cost in terms of protocol, which varies with
   the degree of expected trust.

   Without Route optimization, all the packets MR-CN flow via the Home
   Agent; this increases both the cost and the latency.  The resulting
   path can be illustrated like this:

      CN1  <--------------------- -- -- -----------------+   +---> CN2
     (NYC)                                               |   |    (NICE)
                                                         |   |
                                                         |   |
                                                         |   |
                                                         |   |
                             MRHA tunnel                 |   |
            ===================== == == ================
      MR   <--------------------- -- -- -----------------  HA (BRITTANY)
     (NJ)   ===================== == == ================
                                                           |
                                                           |
                                                         -----
                                                         /////
                                                        Home Link

                 Figure 1: Current model with a Home Link

   The routing overhead becomes costly when:



Thubert, et al.        Expires September 19, 2008               [Page 5]


Internet-Draft                 Global-HAHA                    March 2008


      The distance ||MR, CN|| is much smaller then the sum of the
      distances ||MR, HA|| + ||HA, CN||.

      AND

      ||MR, HA||+||HA, CN|| is costly.  If the 3 points are very close,
      the overhead is relatively important, but small in absolute terms.

   In the picture above, say that a European phone (MR) is roaming in
   New Jersey but Homed in Brittany.  And say that the phone owner
   places a call in New York city to CN1.  Without RO, the voice packets
   flow back and forth over the peering lines between Brittany and the
   US, and the routing overhead causes an additional latency that
   decreases the perceived quality of the phone call.

   On the other hand, calling CN2 would result in a small, acceptable
   overhead, considering that the distance ||HA, CN2|| is very small
   with regards to ||MR, HA|| or ||MR, CN2||.  Now, when the MR moves
   back to Brittany and places a new call to CN2, going via the HA might
   double the distance, but the whole thing being local, it is
   negligible.

   The geographical distribution of Home generalizes this latter
   situation.  If we can get rid of the concept of a Home Link that
   anchors the HA in a single location, then we can distribute HAs
   geographically, and, hopefully, one is close to our MR when it's
   roaming.

   So if a MR can locate and bind with a closeby HA, then ||MR, HA|| is
   contained and the overhead is globally limited.  In a same fashion,
   when a CN sends a packet to the MR, it finds a HA closeby and the
   overhead ||HA, CN|| is contained as well.



















Thubert, et al.        Expires September 19, 2008               [Page 6]


Internet-Draft                 Global-HAHA                    March 2008


      CN1  <-----+                                         +-----> CN2
     (NYC)       |                                         |      (NICE)
                 |                                         |
                 |                                         |
                 |                                         |
                 |               long distance             |
                 |               HAHA tunnel               |
                      =========== == == =================
                HA'  ------------ -- -- ------------------ HA (BRITTANY)
               (DC)   =========== == == =================
              || | ||       (under the Atlantic :)
              || | ||
              || | || short distance
              || | || MRHA Tunnel
              || | ||
                 v
               MR (NJ)

         Figure 2: Globally Distributed HA for World Wide service

   In our previous example, we see that a HA' deployed in the East Coast
   saves the round trip over the Atlantic.  There is a new overhead for
   the call to Europe, though, since an additional path is involved
   between MR and HA'.  Then again, if both ||MR, HA'|| and ||CN2, HA||
   are relatively small compared to ||HA, HA'|| then the overhead is
   acceptable; unless all 3 points are located closeby, in which case,
   again, the additional cost is acceptable.

                                                             CN2 (NICE)
                                                                ^
                                                                |
     HA'(DC)  ------------------------------------------------- HA
       |                                                    (BRITTANY)
       v
     MR (NJ)


     <------------------------------------------------------------->
                Diagonal (direct path) cost

     <--------------------------------------------------------------->
                Via HAs

     Figure 3: Illustrating that the overhead can be relatively small







Thubert, et al.        Expires September 19, 2008               [Page 7]


Internet-Draft                 Global-HAHA                    March 2008


2.4.  Single point of failure

   The Home Link is a single point of failure for MIPv6/NEMO operations.

   Should the Home Link fail, the whole set of MNs / MRs is disconnected
   from the rest of the world.  One could decide to use a virtual link
   for Home, but then:

   MIPv6 provides a support for multiple HAs, with the DHAAD mechanism.
   This mechanism helps scaling up the Home by adding HAs dynamically,
   and eventually load balancing the bindings between them.  But this
   all relies on HAHA communication over the PHYSICAL Home Link; so
   making that link virtual implies a single Home Agent.

   In turn this makes the HA a single point of failure, and disables the
   scalability that the DHAAD mechanism provides to MIPv6.


3.  Rationale for the proposed solution

   For the time being, the precise flows are not elaborated.  One idea
   is that a protocol such as IS-IS or OSPFv3 could help a lot, mostly
   in the registration phase.  Another is that HAs should be proactively
   preassigned to receive a given set of registration, in order to allow
   a certain degree of aggregation within sites and in between site.
   Finally, the concept of proxy is introduced to limit the number of
   primary sites (to 1?) and as a key element for an upcoming NEMO route
   optimization scheme, where routes can be echanged in a trusted
   fashion between proxies.


4.  A proxy for Mobile IP

   The draft references extensively a MIP proxy HA function.  The word
   proxy, here, is taken in a classical sense, like, for instance, a web
   proxy: a MIP proxy Home Agent acts as a HA for the MN and as a MN for
   the HA, the CN, and other proxies.  In particular, the MIP proxy
   terminates the MR-HA tunnel and the associated encryption, extracts
   the packets, and reencapsulates them to the destination.

   This differs from a proxy-MIP function, which performs the Mobile
   Node operation on behalf of a non MIP-enabled node, in order to
   manage its mobility transparently.








Thubert, et al.        Expires September 19, 2008               [Page 8]


Internet-Draft                 Global-HAHA                    March 2008


                                  +-------+           +-------+
                                  |       |           |       |
                                  | HA 1  |           | HA 2  |
                                  |       |           |       |
                                  +-------+           +-------+
                                primary ^           primary ^
                                binding |           binding |
              +-------+           +-------+           +-------+
              |       | --------->|       |---------->|       |
              | MN/MR |  proxy    |proxy 1| secondary |proxy 2|
              |     1 |  binding  |       | binding   |       |
              +-------+           +-------+           +-------+
                                   RO   |           proxy   ^
                                binding v           binding |
                                  +-------+           +-------+
                                  |       |           |       |
                                  |  CN   |           | MN/MR |
                                  |       |           |     2 |
                                  +-------+           +-------+

                      Figure 4: MIP proxy Home Agent

   Distributing widely the MIP proxies presents a number of advantages:

   Route Optimization:  a proxy-to-proxy path between to MNs/MRs could
      be much shorter then the path via the HAs.

   Local Mobility Management:  when the MN moves around a given proxy,
      but keeps binding to that same proxy, the proxy does not need to
      inform the primary HA.

   Nested NEMO:  when Mobile Routers attach to one another and form a
      nested NEMO, the corresponding MRHA tunnel are nested as well.  If
      they all bind to a same proxy, the proxy will decapsulate all the
      levels of tunneling, and retunnel only once towards the Internet
















Thubert, et al.        Expires September 19, 2008               [Page 9]


Internet-Draft                 Global-HAHA                    March 2008


5.  Overview

   This description covers the specific case of a Partitioned Home
   Network.  Home is subnetted and the subnets are attributed to the
   distributed sites.  As a result, in a given location, HAs will be
   operating both as primary HA taking the registrations for the local
   partition and proxy HA for registrations that belong to other sites.
   Additional satellite sites might be deployed around some of the main
   sites.

               ##                                         ##
     ##        ##                                         ##
     ##\       ||                                         ||proxy/parent
       \\      ||                                         || tunnel
        \\  ---||----            ...... ...           ----||---
         \\|         |       ....   ....  ...        |         |
          \   @---@  |    ....              .....    |  @---@  |
    ## -----  | X |  ---------------------------------   \ /   ------##
    ## -----  @---@    ....  HAHA tunnel        ....      @    ------##
           |         ---------------------------------         |
            ------\ \ ...                        .... / /-||---
                   \ \...                         .../ /  ||
                    \.\.                            /./   ||
                    .\.\       internet            /./.   ||
                     .\.\     ...........         / /...  ##
                    ...\ \                       / / ..   ##
                     .. \ \                     / /  ...
                      ...\ \                   / / ...
                        ..\ \   ......        / /...
                           \.\ .    ...... .././
     @  primary HA          \ \          .. / /
                             \ \ --------- / /
     ## proxy HA or           \ \  @   @  / /
     ## satellite site         \    \ /    /
                                \    @    /-----##
     --                         |   / \   ------##
    |  | primary site           |  @   @  |
     --                          ---------

                            Figure 5: Overview

   It is out of the scope of this document to discuss how the subnetting
   was decided and configured.  It is also out of the scope of this
   document to describe the operations within a site where more than one
   HA is deployed.  It is expected that in each primary site, HAs
   discover each other, mesh using tunnels, and form an area that owns
   the partition of Home that was assigned to that site.




Thubert, et al.        Expires September 19, 2008              [Page 10]


Internet-Draft                 Global-HAHA                    March 2008


5.1.  Initial routing

5.1.1.  External routing

   Sites are expected to be connected locally to the internet, via the
   network of one or more service provider.  Each site has a default
   route to the internet via that connection.

                                    . ..   /
            ---------          ........ ..;.           ---------
           |         |       ..          / .....      |         |
           |     ::/0 ->  ....          ;      ...  <- ::/0     |
           |         ============HAHA=TUNNEL===========         |
           |         | ....           ;          .... |         |
           |         | .<- Home::/16 /  Home::/16 ->..|         |
            --------- ...           ;             ...  ---------
                        .....      /               ..
                               .  ;....      ......
                                 /  ..........

   In return, each site advertises a Home aggregation to the internet.
   The Home aggregation has a very short prefix which should be
   partitioned amongst a number of Service Providers and subnetted to
   serve as Distributed Home Networks for their customers.  One could
   visualize this aggregation as a subway for Mobile Nodes.

                                    ......
            ---------           ....... .../           ---------
           |         |      .....         ;  ....     |         |
           |         ----------------------------------         |
           |     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<      |
           |    v    ------------HAHA-tunnel-----------   ^     |
           |    v    |                /              .|   ^     |
           |    \  ==MRHA==          /            ... |   ^     |
           |  HA >---------- MR     ;              .. |   ^     |
           |    /  =tunnel=        /                 .|   ^     |
           |    v    |            ;                   |   ^     |
           |     >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA   |
           |         | .        ;                ...  |         |
            ---------   .      /                ...    ---------
                         ...  ;....      ......
                             /    ..........

   Thus, a site attracts the DHAAD requests from any MR that happens to
   be roaming close to the site, regardless of the MR primary site.  So
   MRs bind to the closest site from their physical location.  In a same
   fashion, CNs send all packets to LFNs via the closest Home site.  But
   packets back flow directly from the site where the MR is bound.



Thubert, et al.        Expires September 19, 2008              [Page 11]


Internet-Draft                 Global-HAHA                    March 2008


5.1.2.  Internal routing

   In each site, border HAs are elected to mesh with peers in other
   sites.  Sites are interconnected over a mesh tunnels and private
   links.  Routing between sites obeys the traditional rules of the
   Internet, using for instance an Exterior Gateway Protocol (like BGP)
   between different service providers, and an IGP within a Distributed
   Home Network.

   Between sites of a given Distributed Home Network, it might be
   preferable to form a fully meshed backbone, in order to limit the
   cost of routing and optimize the paths.

                                    ......
            ---------           ....... .../           ---------
           | site1   |      .....         ;  ....     |    Site2|
           |         ----------------------------------         |
           |  Home:Site2::/48 ->            <- Home:Site1::/48  |
           |         ------------HAHA-tunnel-----------         |
           |  @ @ @  |                /              .|   @   @ |
           |   @ @   | <- Home::/16  ;   Home::/16 -> |  @ @ @  |
            ---------   .           /            ...   ---------
                         ...   ....;     ......
                                  /..........


   It can be expected that, in order to scale, satellite sites would be
   deployed to take the proxy bindings but would not participate to the
   HAHA protocol that happens between the primary sites - at least when
   a proactive version of HAHA is being used.

                                    ......
            ---------           ....... .../.          ---------
           | Sat1    |      .....         ;   ....    |   Site1 |
           |         ----------------------------------         |
           |  Home::/16 ->               <- Home:Site1:Sat1:/64 |
           |         ----proxyHAHA-tunnel--------------         |
           |  ####   |                /              .|  @ @ @  |
           |  ####   | <-  Home::/16 ;   Home::/16 -> |   @ @   |
            ---------   .           /            ...   ---------
                         ...   ....;     ......
                                  /..........


   In a satellite site, HAs are only proxy, never primary.  Each proxy
   HA has at least one assigned parent HA, which belongs to a primary
   site.  A tunnel is established between the proxy HA and the parent
   HA.  The parent advertises the Home Aggregation to the proxy over



Thubert, et al.        Expires September 19, 2008              [Page 12]


Internet-Draft                 Global-HAHA                    March 2008


   that tunnel, as it does over the internet.  In return, the proxy
   advertises its own prefixes, and redistributes the Home Aggregation
   over the internet.  Finally, the parent redistributes the route to
   the proxy's network into its area, via itself, as an external route.

5.2.  Binding

   At that point, the primary sites are ready to accept bindings, either
   directly from Mobile Routers or via proxy HAs.  This is the runtime
   phase for HAHA.

   A MR that is located close to its primary site will register there
   for its primary binding.  In that case, the binding is direct.
   Otherwise, the MR will use a proxy in order to bind locally, and the
   proxy will perform the primary binding on behalf of the MR.  If the
   proxy is parented at the primary site, the binding is local;
   otherwise, it is called a foreign binding.

5.2.1.  Direct primary binding

   When the primary HA accepts a direct binding from a MR, then it must
   let the other primaries know that it owns the binding for that Home
   Address, in a fashion that is discussed in Section 10.2.

                         ......
               ......../.     ...    ---------------------------
          ...         ;         ..  |                     Site1 |
          ..         / Home::/16 ->.|   @--@--@                 |
         ...        ;            .. |  /                        |
        ....       /    MR ==MRHA==== @ <- Home:site1:MNP::/64  |
         ....     ;     |        .. |  \                        |
        ...      /    ------   ...  |   @--@                    |
         ...    ;      MNP          |                           |
           ... / ..          ...     ---------------------------
                  ...........

         Figure 10: Primary HA injects necessary MR routes in area

   The primary HA installs all (implicit and explicit) routes to the MR
   MNPs over the MRHA tunnel.  It must also inject any required route,
   such as explicit prefix routes, into the primary area, as external
   routes via itself.  All these routes are summarized at the area
   border and the other areas are not affected by the routing change.

5.2.2.  local proxy binding

   When a MR binds to a satellite site, a HA acts as a proxy and binds
   in turn with a primary site, on behalf of that MR, to create the



Thubert, et al.        Expires September 19, 2008              [Page 13]


Internet-Draft                 Global-HAHA                    March 2008


   primary binding.  The proxy binding can only succeed if the primary
   binding does.  If the primary accepts the binding, then it returns a
   positive Binding Ack, with the list of the prefixes that are routed
   via the Mobile Router.

                             .. ........
            ---------     ..   .       ...    ------------------
           | Sat1    |  ..               /.  |            Site1 |
           |         | <- Home::/16     ;  . |                  |
           |         | ..              /  .. |                  |
           |  ---> =========================== @ <- Home:site1  |
           | |       |.              /    .. |        :MNP::/64 |
           |  --  # ======= MR      ;   ...  |                  |
           |         | .    |      /         |                  |
            ---------   . -----   ;   ...     ------------------
                           MNP.../..

   Then the proxy HA installs the routes that it got from the the
   positive Binding Acknowledgement over the proxy MRHA tunnel, and
   Acknowledges the proxy BU.  Once a primary binding has succeeded, the
   proxy might establish secondary bindings with other sites.

5.2.3.  Foreign proxy binding

   When a MR binds to a foreign site, whether the site is primary or
   satellite, a HA from the site acts as a proxy as if the site was a
   satellite from the primary.

      -----------------    .. ..        ...    -----------------
     | Foreign site    | ..     ..   |     .  | MR primary Site |
     |                 ------------------------                 |
     |        +-------------------------------------- primary   |
     |        | +----------proxyHAHA-----------------           |
     |        | |      ------------------------        ^        |
     |        | |      |             .        |        ^        |
      -------|| ||-----  ..          |     ..  -----------------
             || ||    - . - . - . - . -     .
      -------|| ||-----              |      .
     |        | |      |.      |MNP  .     ..
     |      proxy --MRHA--- MR-|     |   ...
     |         HA ---------    |     |     ...
     |                 | ..          .      .
     |Foreign satellite|<- Home::/16 |      .
      -----------------     ...  ..      ...







Thubert, et al.        Expires September 19, 2008              [Page 14]


Internet-Draft                 Global-HAHA                    March 2008


5.3.  Route Optimizations

   When the MR binds in a foreign location, the transport between an
   arbitrary correspondent and the MR within the HAHA network might be
   far from optimized.

   As a result of the primary binding, a proxyHAHA tunnel is established
   between the proxy and the primary HA.  That tunnel is itself
   encapsulated in the HAHA tunnels when packets flow over the internet.

                              .. ..  |...
      -----------------    ..        .  ...    -----------------
     | Foreign site    | ..          |     .  | MR primary Site |
     |                 ------------------------                 |
     |        +-------------------------------------- primary   |
     |        |v<<<<<<<<<<<home:site:mnp::/64<<<<<<<< HA        |
     |        |v+----------proxyHAHA-----------------           |
     |        |v|      ------------------------        ^        |
     |        |v|      |             .        |        ^        |
      -------||v||-----  ..          |     ..  ------| ^ |------
             ||v||    - . - . - . - . - . - . -      | ^ |
      -------||v||-----              |      .  ------| ^ |------
     |        |v|      |.            .     .. |        ^        |
     |            --MRHA---     |MNP |   ...  |      home:      |
     |   proxyHA  >>>>>>>>>> MR-|    .     .. |      site::     |
     |            ---------     |    |     ...|       /48       |
     |                 |             .      ..|        ^        |
     |Foreign satellite|<- Home::/16 |      . |Foreign ^ site   |
      -----------------              .      .. ------| ^ |------
                  - . - . - . - .- . - . - . -       | ^ |
                      ...                  ..  ------| ^ |------
                         ..                ...|        ^        |
                       ...         CN >>>>Home::/16>>>>>        |
                        ...                 ..|                 |
                         ..                 ..|                 |
                          .....   Home::/16 ->|                 |
                             .....    ....... |Foreign satellite|
                                 ..........    -----------------

            Figure 13: The path from CN to MR is not optimized

   Also, packets from an arbitrary correspondent reach the site that is
   closest to the correspondent, then forwarded to the primary site for
   the destination.  Within the primary site, they are encapsulated
   towards the proxy and sent across the HAHA network again.  Finally
   they reach the proxy that decapsulates the packets and encapsulates
   them back.




Thubert, et al.        Expires September 19, 2008              [Page 15]


Internet-Draft                 Global-HAHA                    March 2008


   In order to improve this, various possibilities are offered:

5.3.1.  Leaking MNP routes in the HAHA network

   The proxy can establish a secondary binding with its parent.  In
   return, the parent redistributes an external route to the MNP via
   itself, and leaks that route inside the whole HAHA network.

                              .. ..  |...
      -----------------    ..        .  ..
     | Foreign site    | ..          |     .
     |                 ----------------------------------+
     |     parentHA <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< |
     |                 ------------------------------+ ^ |
     |        |v|      |             .               | ^ |
      -------||v||-----  ..          |     ..        | ^ |
             ||v||    - . - . - . - . - . - . -      | ^ |
      -------||v||-----              |      .  ------| ^ |------
     |        |v|      |.            .     .. |      home:      |
     |            --MRHA---     |MNP |   ...  |      site:      |
     |   proxyHA  >>>>>>>>>> MR-|    .     .. |      mnp::      |
     |            ---------     |    |     ...|       /64       |
     |                 |             .      ..|        ^        |
     | egress satellite|<- Home::/16 |      . |Foreign ^ site   |
      -----------------              .      .. ------| ^ |------
                  - . - . - . - .- . - . - . -       | ^ |
                      ...                  ..  ------| ^ |------
                         ..                ...|        ^        |
                       ...         CN >>>>Home::/16>>>>>        |
                        ...                 ..|                 |
                         ..                 ..|                 |
                          .....   Home::/16 ->|                 |
                             .....    ....... |ingress satellite|
                                 ..........    -----------------

         Figure 14: The path from CN to MR bypasses the primary HA

   This bypasses the primary home agent for packet forwarding.  Note
   that the packets still flow within the HAHA network between the
   ingress site close to the correspondent and the egress (satellite)
   site.

   Note also that when the proxy HA binds to either its parent or the
   primary HA, it uses an address from within the HAHA network (its HAHA
   Address), as CareOf.






Thubert, et al.        Expires September 19, 2008              [Page 16]


Internet-Draft                 Global-HAHA                    March 2008


5.3.2.  On-demand proxy routes

   The proxy can establish a secondary binding with the correspondent's
   proxy provided there's such a node.  It might be envisioned to adapt
   NHRP [RFC2735] for IPv6 in order to discover the remote tunnel end
   point.

               -----------------            ....
              |                 |  ....             ..
              | egress satellite|<- Home::/16 |    . ..
              |                 |  ..                  .
              |            --MRHA---      |MNP1         ..
              |   proxyHA  >>>>>>>>>> MR1-|              ..
              |            ---------      |              ...
              |        ^        |                      ..
               ------| ^ |------                         ..
                .... | ^ |                               .
               ..    | ^ | proxy-to-proxy             ...
               ...   | ^ | on demand tunnel            ...
                ..   | ^ |                              ..
                - . -| ^ |. - . - . - .- . - . - . - . -
               ------| ^ |------                       ..
              |        ^        |                    .....
              |        ^   --MRHA---      |MNP2         .....
              |   proxyHA  <<<<<<<<<< MR2-|              ....
              |            ---------      |              ...
              |                 |.                      ..
              |ingress satellite|<- Home::/16       ...
              |                 |  ...              ....
               -----------------         ............

           Figure 15: The path is now direct between the proxies

   An example of application is when two proxies from a same Home
   establish a cross binding.  In fact, the Mobile Routers are unaware
   of the Route Optimization that takes place.  This feature might be
   desirable when the privacy of the location is an issue for the
   service provider.

   As part of the secondary binding to the ingress proxy, the egress
   proxy passes all the MNPs for the MR.  This can be done using HAHA
   signalling, as explicit prefix routes.  It is expected that the
   proxies belong to a chain of trust that links the primary and the
   satellite sites together.  This, the ingress proxy trusts the egress
   proxy both for the binding and for the explicit prefixes.

   The routes are literally projected from a proxy to the other while
   unseen by node in between; this is why this model is called Route



Thubert, et al.        Expires September 19, 2008              [Page 17]


Internet-Draft                 Global-HAHA                    March 2008


   Projection, by opposition with the traditional model of route
   injection which impacts the nodes on the way and is problematic with
   mobility.

   Note that in that case, the binding uses the proxy's external address
   as careof.  The packets are thus routed straight between the proxies,
   outside of the HAHA network.












































Thubert, et al.        Expires September 19, 2008              [Page 18]


Internet-Draft                 Global-HAHA                    March 2008


6.  Terminology and concepts

   Most of the mobility related terms used in this document are defined
   in the Mobility Related Terminology document [RFC3753] and in the
   Mobile IPv6 specification [RFC3775].

   Additionally, some terms were created or extended for NEMO.  These
   specific terms are defined in the NEMO Terminology document
   [RFC4885].

   This draft introduces the following definitions:

   Distributed Home Network:  In distributed home network, a global Home
      is advertised by several sites that are geographically distributed
      and meshed using tunnels in a VPN fashion.  Mobile Nodes locate
      the closest site using DHAAD and bind there.  More in Section 7...

   Partitioned Home Network:  A Partitioned Home is a specific
      deployment of a Distributed Home Network where each location owns
      a subnet of Home.  The local Home Agents accept registration for
      the local partition.  The local HAs also act as NEMO proxy HAs for
      the rest of Home.

   Primary Home Agent:  A Home Agent that can serve a Binding Update
      from a Mobile Router.  The Mobile Router is always associated with
      a (set of) primary Home Agent (s) to register its binding.

   Proxy Home Agent:  This is a form of proxy, for the NEMO protocol.  A
      proxy HA acts as a HA for MRs to register, but needs to register
      to a primary HA in order to accept the binding.

   Primary site:  A site is primary for a MR if at least one local HA on
      that site can accept a registration for that MR.  When Home is not
      partitioned and sites overlap, primary HAs for a same subnet have
      to be aware of each other in order to find if a binding already
      exists in one of the sites and in which Home Agent.

   satellite site:  A site that is not primary for any binding.  It is
      dependent on a parent primary site for HAHA operations. satellite
      sites are deployed around central primary sites, and one final
      goal for HAHA is to dynamically draw routes between satellite
      sites in order to shortcut the backbone of primary HAs.

   Secondary site:  A site is secondary for a MR if it is primary for
      other MRs but not that one.  HAs in a secondary site can act as
      proxies for that MR, and the site is its own parent.





Thubert, et al.        Expires September 19, 2008              [Page 19]


Internet-Draft                 Global-HAHA                    March 2008


   Primary Binding:  A Binding is primary if it happens with a primary
      Home Agent, whether the client is a MR or a proxy HA.

   Secondary Binding:  A Binding is secondary if it happens between a
      proxy and a non primary Home Agent.  It is used to improve the
      path between sites towards the HA where a MR is registered.

   Proxy Binding:  A Binding is proxy if it happens between a MR and a
      proxy HA, whether the proxy is a pure proxy HA or a secondary HA
      acting as proxy for that MR.  The proxy HA relays the proxy
      binding to a primary HA in a primary binding.  It may maintain a
      set of secondary bindings, depending on the deployment.

   Direct Binding:  A Binding that does not pass via a proxy, straight
      between the MR and its Home Agent.




































Thubert, et al.        Expires September 19, 2008              [Page 20]


Internet-Draft                 Global-HAHA                    March 2008


7.  Distributed Home Network

   This section describes a detailed example how multiple Home Agents
   are configured in different routing domains.  You are encouraged to
   read the nemo basic Home Network Models [RFC4887] draft before going
   through this section.


                HA                                     HA
                |                  ______              |
     --+-----+--+- . -+- . -+--    TUNNEL   --+-----+--+- . -+- .. -+--
       |     |        |     |      ______     |     |        |      |
      MR1   MR2      MRi   MRN               MR1   MR2      MRi    MRN
    ------  ------  ------ ------           ------  ------  ---- - ----
     /64        A:B:1:i::/64                 /64         A:B:n:i::/64


                       Distributed Home Network /48
    <------------------------------------------------------------------>

        extended HN             Aggregated HN              Virtual HN
    <----------------------><---------------------->...<--------------->

     Home    Mob       Mob    Mob    Mob       Mob       Mob       Mob
    <-----><----->...<-----><-----><----->...<----->...<----->...<----->



   In distributed home network, a global Home is advertised by several
   sites that are geographically distributed and meshed using tunnels in
   a VPN fashion.  Mobile Nodes locate the closest site using DHAAD
   against the global Home Network and bind there.  Some form of inter-
   site synchronization (e.g. a routing protocol), which Mobile IPv6 and
   Nemo Basic Support do not provide, must take place in order to allow
   packets to be routed between the incoming site to the Mobile Node.
   The HAHA (Home Agent to Home Agent) protocol is being designed for
   that purpose.

   In one model, called the Partitioned Home Network each site is
   responsible for a subnet of Home.  When a Mobile Node roams far from
   its natural (primary) site, it registers to a Home Agent on a remote
   site, that takes the registration and notifies at least the natural
   site of the foreign registration.

   One specific advantage of not relying on a Home Link for HAHA
   communication is that for a large configuration, the Home Agents can
   be organized hierarchically and distributed geographically, as a set
   of local clusters linked together to form a global Home Network.



Thubert, et al.        Expires September 19, 2008              [Page 21]


Internet-Draft                 Global-HAHA                    March 2008


8.  Message Formats

   A traditional IGP coul be used over the HAHA tunnel.  But in order to
   integrate HAHA smoothly with the rest of the MIP operation, this
   drafts suggest to use the messages and formats detailed in the HAHA
   specification [I-D.wakikawa-mip6-nemo-haha-spec].


9.  Mobile Router Operation

9.1.  Locating Home

9.2.  Proxy MIP client


10.  Home Agent Operation

10.1.  Locating the other HAs that serve the same Home

10.2.  Locating the HA that owns the binding for a HoA

   At the time of processing a binding update, a Home Agent (be it
   primary or simply proxy for the binding Home Address) needs to
   discover if the binding already exists with a primary Home Agent.
   There are at least 3 approaches that might be deployed for that
   purpose:

   Reactive:  This method is also referred to as 'on-demand'.  In case
      of a binding cache miss, a primary Home Agent floods a Binding
      Information Request message to all the other primary Home Agents
      for the home address that is sought for.  The reactive approach
      can be used between a satellite site and its parent site even when
      the primary HAs use an other method in the backbone.

   Proactive:  The binding information is shared proactively between the
      primary Home Agents for the existing bindings.  All primary HAs
      know at any point of time which Home Addresses are bound and with
      which primary Home Agent.  This approach is preferred for stable
      configurations, for instance if NEMO is used as a tool to simplify
      the configuration and reconfiguration of mostly stable networks.

   Predictive:  Ranges of Home Addresses and prefixes are preassigned to
      the Home Agents, following a rule that is shared or commonly
      computed by all HAs.  A partitioned Home Network is an example of
      that, but this is mostly useful within a site between local Home
      Agents.





Thubert, et al.        Expires September 19, 2008              [Page 22]


Internet-Draft                 Global-HAHA                    March 2008


11.  Acknowledgements

   The authors wish to thank:


12.  IANA considerations

   This document does not require any IANA action.


13.  Security Considerations

   This document explores how t use the haha protocol but does not
   standardize any new operation that would be harmful.


14.  References

14.1.  informative reference

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

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

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

   [RFC4886]  Ernst, T., "Network Mobility Support Goals and
              Requirements", RFC 4886, July 2007.

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

   [RFC4980]  Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of
              Multihoming in Network Mobility Support", RFC 4980,
              October 2007.

14.2.  normative reference

   [RFC2735]  Fox, B. and B. Petri, "NHRP Support for Virtual Private
              Networks", RFC 2735, December 1999.

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



Thubert, et al.        Expires September 19, 2008              [Page 23]


Internet-Draft                 Global-HAHA                    March 2008


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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.


Authors' Addresses

   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 4 97 23 26 34
   Email: pthubert@cisco.com


   Ryuji Wakikawa
   Keio University Department of Environmental Information
   5322 Endo Fujisawa Kanagawa
   252-8520
   JAPAN

   Phone: +81-466-49-1100
   Email: ryuji@sfc.wide.ad.jp


   Vijay Devarapalli
   Azaire Networks
   3121 Jay Street
   Santa Clara, CA  94054
   USA

   Email: vijay.devarapalli@azairenet.com











Thubert, et al.        Expires September 19, 2008              [Page 24]


Internet-Draft                 Global-HAHA                    March 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Thubert, et al.        Expires September 19, 2008              [Page 25]