One document matched: draft-thubert-dmm-global-haha-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="info" docName="draft-thubert-dmm-global-haha-00">" ipr="trust200902">
<front>
<title abbrev='Global-HAHA'>
Global HA to HA protocol
</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco">Cisco Systems, Inc</organization>
<address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200 </street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<author initials="R" surname="Wakikawa" fullname="Ryuji Wakikawa">
<organization>Softbank Mobile</organization>
<address>
<postal>
<street>1-9-1,Higashi-Shimbashi,Minato-Ku</street>
<city>Tokyo</city> <code>06254105-7322</code>
<country>Japan</country>
</postal>
<email>ryuji.wakikawa@gmail.com</email>
</address>
</author>
<author initials="V" surname="Devarapalli" fullname="Vijay Devarapalli">
<organization>WiChorus</organization>
<address>
<postal>
<street>3590 North First St</street>
<city>San Jose, CA</city> <code>95134</code>
<country>USA</country>
</postal>
<email>vijay@wichorus.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>DMM</workgroup>
<keyword>RFC</keyword><keyword>Request for Comments</keyword>
<keyword>I-D</keyword><keyword>Internet-Draft</keyword>
<keyword>Basic</keyword><keyword>Nemo Basic Support</keyword>
<keyword>MIP</keyword><keyword>Mobile IP</keyword>
<keyword>MIPv6</keyword>
<keyword>HAHA</keyword>
<abstract>
<t>This HAHA protocol extends <xref target="RFC6275"> MIPv6 </xref>
and
<xref target='RFC3963'>NEMO</xref> 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.</t>
</abstract>
</front>
<middle>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='introduction' title="Introduction">
<t> This draft was initially submitted as draft-thubert-nemo-global-haha
in 2004, but the object of the work is now being considered at DMM, so the
draft is republished there to provide an historical reference.</t>
<t>Over the ten years since the draft was originally published, IPv6 mobility
evolved in particular with the introduction of
<xref target="RFC5213"> Proxy Mobile IPv6 (PMIP)</xref> and the <xref target="RFC6830">
Locator/ID Separation Protocol (LISP)</xref>. It can be noted that the MIP proxy
introduced in this document is a Route Optimization function, entirely different
from a PMIP proxy function. </t>
<t>
The MIP proxy in global HAHA is probably still relevant since it allows the
separation of the interaction with 1) the client, 2) the HAs and 3)other
MIP proxies, which can be individually based on traditional protocols such as
<xref target="RFC6275"> Mobile IPv6 </xref> and <xref target="RFC3963"> NEMO </xref>,
or more recent approaches such as PMIP and LISP.
</t>
<t> The reader of this document is expected to be familiar with
both the <xref target="RFC6275"> Mobile IPv6 </xref> and
<xref target='RFC3963'> NEMO Basic Support
</xref> 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.
</t>
<t> 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. </t>
<t> 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.
</t>
<t> 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.</t>
<t> 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.
</t>
<t> 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.
</t>
<t> 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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<vspace blankLines="100" />
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='motivation' title="Motivations">
<section anchor='reqs' title="Requirements">
<t>
This draft addresses two generic requirements expressed in
<xref target='RFC4886'> the Nemo requirements </xref>:
<list style="hanging" >
<t hangText="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.</t>
<t hangText="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.</t>
</list>
</t>
<t>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 <xref target='RFC4980'> NEMO multihoming issues
</xref> draft:
"Single MR, Multiple HAs, Single NEMO-Prefix".
</t>
<t>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.
</t>
</section>
<section anchor='L3o' title="Layer 3 operations">
<t><xref target="RFC6275"> Mobile IPv6 </xref>
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.
</t>
<t> So the model for MIPv6 is Home Link centric and it is no surprise that it
extends <xref target="RFC4861"> IPv6 Neighbor Discovery </xref> 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.
</t>
<t><xref target='RFC3963'> the NEMO Basic Support
</xref> 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. </t>
<t>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.
</t>
<t>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.
</t>
</section>
<section anchor='dis' title="Route Optimization">
<t>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.</t>
<t>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:
<figure anchor='figmod' title="Current model with a Home Link">
<artwork><![CDATA[
CN1 <--------------------- -- -- -----------------+ +---> CN2
(NYC) | | (NICE)
| |
| |
| |
| |
MRHA tunnel | |
===================== == == ================
MR <--------------------- -- -- ----------------- HA (BRITTANY)
(NJ) ===================== == == ================
|
|
-----
/////
Home Link
]]></artwork>
</figure>
The routing overhead becomes costly when:
<list>
<t>The distance ||MR, CN|| is much smaller then the
sum of the distances ||MR, HA|| + ||HA, CN||.</t>
<t>AND</t>
<t>||MR, HA||+||HA, CN|| is costly. If the 3 points are very close, the
overhead is relatively important, but small in absolute terms.</t>
</list>
</t>
<t>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.
</t>
<t>
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.
</t>
<t>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.
</t>
<t>
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.
<figure anchor='figdis'
title="Globally Distributed HA for World Wide service">
<artwork><![CDATA[
CN1 <-----+ +-----> CN2
(NYC) | | (NICE)
| |
| |
| |
| long distance |
| HAHA tunnel |
=========== == == =================
HA' ------------ -- -- ------------------ HA (BRITTANY)
(DC) =========== == == =================
|| | || (under the Atlantic :)
|| | ||
|| | || short distance
|| | || MRHA Tunnel
|| | ||
v
MR (NJ)
]]></artwork>
</figure>
</t>
<t>
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.
<figure anchor='overhead'
title="Illustrating that the overhead can be relatively small">
<artwork><![CDATA[
CN2 (NICE)
^
|
HA'(DC) ------------------------------------------------- HA
| (BRITTANY)
v
MR (NJ)
<------------------------------------------------------------->
Diagonal (direct path) cost
<--------------------------------------------------------------->
Via HAs
]]></artwork>
</figure>
</t>
</section>
<section anchor='RAS' title="Single point of failure">
<t>The Home Link is a single point of failure for MIPv6/NEMO operations.</t>
<t>
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:</t>
<t>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.
</t>
<t>
In turn this makes the HA a single point of failure, and disables
the scalability that the DHAAD mechanism provides to MIPv6.
</t>
</section>
</section>
<section anchor='rationale' title="Rationale for the proposed solution">
<t>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.
</t>
</section>
<section anchor='mip proxy Home Agent' title="A proxy for Mobile IP">
<t>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.
</t>
<t>
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.
</t>
<figure anchor='fig1' title="MIP proxy Home Agent">
<artwork><![CDATA[
+-------+ +-------+
| | | |
| 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 |
+-------+ +-------+
]]></artwork>
</figure>
<t>Distributing widely the MIP proxies presents a number of advantages:
<list style="hanging">
<t hangText="Route Optimization:"> a proxy-to-proxy path between to
MNs/MRs could be much shorter then the path via the HAs.
</t>
<t hangText="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.
</t>
<t hangText="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
</t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<vspace blankLines="100" />
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='overview' title="Overview">
<t>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.
<figure anchor='overvw' title="Overview">
<artwork><![CDATA[
## ##
## ## ##
##\ || ||proxy/parent
\\ || || tunnel
\\ ---||---- ...... ... ----||---
\\| | .... .... ... | |
\ @---@ | .... ..... | @---@ |
## ----- | X | --------------------------------- \ / ------##
## ----- @---@ .... HAHA tunnel .... @ ------##
| --------------------------------- |
------\ \ ... .... / /-||---
\ \... .../ / ||
\.\. /./ ||
.\.\ internet /./. ||
.\.\ ........... / /... ##
...\ \ / / .. ##
.. \ \ / / ...
...\ \ / / ...
..\ \ ...... / /...
\.\ . ...... .././
@ primary HA \ \ .. / /
\ \ --------- / /
## proxy HA or \ \ @ @ / /
## satellite site \ \ / /
\ @ /-----##
-- | / \ ------##
| | primary site | @ @ |
-- ---------
]]></artwork>
</figure>
</t>
<t>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.
</t>
<section anchor='rtin' title="Initial routing">
<section anchor='extrtr' title="External routing">
<t>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.
<figure>
<artwork><![CDATA[
. .. /
--------- ........ ..;. ---------
| | .. / ..... | |
| ::/0 -> .... ; ... <- ::/0 |
| ============HAHA=TUNNEL=========== |
| | .... ; .... | |
| | .<- Home::/16 / Home::/16 ->..| |
--------- ... ; ... ---------
..... / ..
. ;.... ......
/ ..........
]]></artwork>
</figure>
</t>
<t>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.
<figure>
<artwork><![CDATA[
......
--------- ....... .../ ---------
| | ..... ; .... | |
| ---------------------------------- |
| <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< |
| v ------------HAHA-tunnel----------- ^ |
| v | / .| ^ |
| \ ==MRHA== / ... | ^ |
| HA >---------- MR ; .. | ^ |
| / =tunnel= / .| ^ |
| v | ; | ^ |
| >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CN >>>>>> HA |
| | . ; ... | |
--------- . / ... ---------
... ;.... ......
/ ..........
]]></artwork>
</figure>
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.
</t>
</section>
<section anchor='intrtr' title="Internal routing">
<t>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.
</t>
<t>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.
</t>
<figure>
<artwork><![CDATA[
......
--------- ....... .../ ---------
| site1 | ..... ; .... | Site2|
| ---------------------------------- |
| Home:Site2::/48 -> <- Home:Site1::/48 |
| ------------HAHA-tunnel----------- |
| @ @ @ | / .| @ @ |
| @ @ | <- Home::/16 ; Home::/16 -> | @ @ @ |
--------- . / ... ---------
... ....; ......
/..........
]]></artwork>
</figure>
<t>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.
</t>
<figure>
<artwork><![CDATA[
......
--------- ....... .../. ---------
| Sat1 | ..... ; .... | Site1 |
| ---------------------------------- |
| Home::/16 -> <- Home:Site1:Sat1:/64 |
| ----proxyHAHA-tunnel-------------- |
| #### | / .| @ @ @ |
| #### | <- Home::/16 ; Home::/16 -> | @ @ |
--------- . / ... ---------
... ....; ......
/..........
]]></artwork>
</figure>
<t>
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 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.
</t>
</section>
</section>
<section anchor='bin' title="Binding">
<t>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.
</t>
<t>
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.
</t>
<section anchor='lpb' title="Direct primary binding">
<t> 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 <xref target="lochab"/>.
</t>
<figure anchor='hainj' title="Primary HA injects necessary MR routes in area">
<artwork><![CDATA[
......
......../. ... ---------------------------
... ; .. | Site1 |
.. / Home::/16 ->.| @--@--@ |
... ; .. | / |
.... / MR ==MRHA==== @ <- Home:site1:MNP::/64 |
.... ; | .. | \ |
... / ------ ... | @--@ |
... ; MNP | |
... / .. ... ---------------------------
...........
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section anchor='lxb' title="local proxy binding">
<t>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 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.</t>
<figure>
<artwork><![CDATA[
.. ........
--------- .. . ... ------------------
| Sat1 | .. /. | Site1 |
| | <- Home::/16 ; . | |
| | .. / .. | |
| ---> =========================== @ <- Home:site1 |
| | |. / .. | :MNP::/64 |
| -- # ======= MR ; ... | |
| | . | / | |
--------- . ----- ; ... ------------------
MNP.../..
]]></artwork>
</figure>
<t>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.
</t>
</section>
<section anchor='fxb' title="Foreign proxy binding">
<t>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.
</t>
<figure>
<artwork><![CDATA[
----------------- .. .. ... -----------------
| Foreign site | .. .. | . | MR primary Site |
| ------------------------ |
| +-------------------------------------- primary |
| | +----------proxyHAHA----------------- |
| | | ------------------------ ^ |
| | | | . | ^ |
-------|| ||----- .. | .. -----------------
|| || - . - . - . - . - .
-------|| ||----- | .
| | | |. |MNP . ..
| proxy --MRHA--- MR-| | ...
| HA --------- | | ...
| | .. . .
|Foreign satellite|<- Home::/16 | .
----------------- ... .. ...
]]></artwork>
</figure>
</section>
</section>
<section anchor='pfw' title="Route Optimizations">
<t>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.
</t>
<t>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.
</t>
<figure anchor='notopt' title="The path from CN to MR is not optimized">
<artwork><![CDATA[
.. .. |...
----------------- .. . ... -----------------
| 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|
.......... -----------------
]]></artwork>
</figure>
<t>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.
</t>
<t>In order to improve this, various possibilities are offered:
</t>
<section anchor='pfwl' title="Leaking MNP routes in the HAHA network">
<t>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. </t>
<figure anchor='peuopt' title="The path from CN to MR bypasses the primary HA">
<artwork><![CDATA[
.. .. |...
----------------- .. . ..
| 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|
.......... -----------------
]]></artwork>
</figure>
<t>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.
</t>
<t>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.</t>
</section>
<section anchor='pfwo' title="On-demand proxy routes">
<t>The proxy can establish a secondary binding with the correspondent's proxy
provided there's such a node. It might be envisioned to adapt
<xref target="RFC2735"> NHRP </xref> for IPv6 in order to discover
the remote tunnel end point.</t>
<figure anchor='opt' title="The path is now direct between the proxies">
<artwork><![CDATA[
----------------- ....
| | .... ..
| egress satellite|<- Home::/16 | . ..
| | .. .
| --MRHA--- |MNP1 ..
| proxyHA >>>>>>>>>> MR1-| ..
| --------- | ...
| ^ | ..
------| ^ |------ ..
.... | ^ | .
.. | ^ | proxy-to-proxy ...
... | ^ | on demand tunnel ...
.. | ^ | ..
- . -| ^ |. - . - . - .- . - . - . - . -
------| ^ |------ ..
| ^ | .....
| ^ --MRHA--- |MNP2 .....
| proxyHA <<<<<<<<<< MR2-| ....
| --------- | ...
| |. ..
|ingress satellite|<- Home::/16 ...
| | ... ....
----------------- ............
]]></artwork>
</figure>
<t>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.
</t>
<t>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.</t>
<t>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 Projection, by
opposition with the traditional model of route injection which impacts the
nodes on the way and is problematic with mobility.</t>
<t>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.
</t>
</section>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<vspace blankLines="100" />
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='terms'
title="Terminology and concepts">
<!--
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
-->
<t>Most of the mobility related terms used in this document are
defined in the <xref target="RFC3753">
Mobility Related Terminology document</xref> and in the
<xref target="RFC6275">Mobile IPv6 specification</xref>.
</t>
<t>Additionally, some terms were created or extended for NEMO.
These specific terms are defined in the
<xref target="RFC4885">
NEMO Terminology document</xref>.
</t>
<t>This draft introduces the following definitions:
<list style="hanging">
<t hangText="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 <xref target="distha"/>...</t>
<t hangText="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.</t>
<!--t hangText="Replicated Home Network:">
A Replicated Home is a specific deployment of a Distributed Home
Network where each location is configured with the same prefixes.
So the local Home Agents can accept every possible registration
and there is no proxying.</t-->
<t hangText="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.</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="Primary Binding:">
A Binding is primary if it happens with a primary Home Agent,
whether the client is a MR or a proxy HA.</t>
<t hangText="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.</t>
<t hangText="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. </t>
<t hangText="Direct Binding:">
A Binding that does not pass via a proxy, straight between the
MR and its Home Agent.</t>
<!--t hangText="Assigned Home Agent:">
The Assigned Home Agent is the well known preferred HA for
owning a given registration in a predictive model.
</t-->
<!--t hangText="Local Acting Home Agent:">
The local Acting Home Agent is locally the well known
preferred HA for owning a given registration in a predictive model.
</t-->
</list>
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<vspace blankLines="100" />
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='distha' title="Distributed Home Network">
<t>
This section describes a detailed example how multiple Home Agents
are configured in different routing domains. You are encouraged to read
<xref target='RFC4887'> the nemo basic
Home Network Models </xref> draft before going through this section.
<figure>
<artwork><![CDATA[
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
<-----><----->...<-----><-----><----->...<----->...<----->...<----->
]]></artwork>
</figure>
</t><t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<vspace blankLines="100" />
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='formats'
title="Message Formats">
<t>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
<xref target='I-D.wakikawa-mip6-nemo-haha-spec'>the HAHA specification</xref>.
</t>
</section>
<section anchor='MRO'
title="Mobile Router Operation">
<section anchor='locmrh' title="Locating Home">
</section>
<section anchor='proxmr' title="Proxy MIP client">
</section>
</section>
<section anchor='HAO'
title="Home Agent Operation">
<section anchor='lochah' title="Locating the other HAs that serve the same Home">
</section>
<section anchor='lochab' title="Locating the HA that owns the binding for a HoA">
<t>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:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.</t>
</list>
</t>
</section>
</section>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<section anchor='sec_acknowledgements' title="Acknowledgements">
<t>The authors wish to thank:</t>
<t>
</t>
</section>
<section title="IANA considerations">
<t>This document does not require any IANA action.</t>
</section>
<section title="Security Considerations">
<t>
This document explores how t use the haha protocol but does not
standardize any new operation that would be harmful.
</t>
</section>
<!--
<section anchor='change' title="Changes">
<section anchor='changes01' title="Changes from version 00 to 01">
<list>
<t> Added a proxy section to introduce the concept
</t>
</list>
</section>
<section anchor='changes02' title="Changes from version 01 to 02">
<list>
<t> Address aggregation that can be done between ISPs so that a shorter prefix is injected in the DFZ.
</t>
</list>
</section>
</section>
-->
</middle>
<back>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<references title="informative reference">
<!--?rfc include="reference.I-D.wakikawa-mext-global-haha-spec.xml" ?-->
<?rfc include="reference.RFC.3753" ?>
<?rfc include="reference.RFC.4887" ?>
<?rfc include="reference.RFC.4885" ?>
<?rfc include="reference.RFC.4886" ?>
<?rfc include="reference.RFC.4980" ?>
</references>
<references title="normative reference">
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.2735" ?>
<?rfc include="reference.RFC.6275" ?>
<?rfc include="reference.RFC.3963" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.6830" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:38:55 |