One document matched: draft-wakikawa-mext-global-haha-spec-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc6275 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275'>
<!ENTITY rfc3963 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3963'>
<!ENTITY rfc5142 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5142'>
<!ENTITY rfc2526 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2526'>
<!ENTITY rfc5026 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5026'>
<!ENTITY rfc3753 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3753'>
<!ENTITY rfc2991 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2991'>
<!ENTITY rfc4885 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4885'>
<!ENTITY rfc4887 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4887'>
<!ENTITY rfc4888 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4888'>
<!ENTITY rfc4889 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4889'>
<!ENTITY rfc4786 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4786'>
<!ENTITY rfc5522 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5522'>
<!ENTITY idHARP PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mip6-hareliability'>
<!ENTITY idHAHA PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thubert-mext-global-haha'>
<!ENTITY idHAHAPROTO PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wakikawa-mip6-nemo-haha-spec'>
<!ENTITY idHAHAINTER PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wakikawa-mext-haha-interop2008'>
<!ENTITY idNEMOAUTO PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-ro-automotive-req'>
<!ENTITY idDMMSUMMARY PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kuntz-dmm-summary'>
]>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>
<rfc category="exp" ipr="trust200902" docName="draft-wakikawa-mext-global-haha-spec-02">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!------------------------------------------------>
<!-- Front Section -->
<!------------------------------------------------>
<front>
<title abbrev="Global HAHA Specification">
Global HA to HA Protocol Specification
</title>
<!-- AUTHORS -->
<author fullname="Ryuji Wakikawa" initials="R.W." surname="Wakikawa">
<organization abbrev="Toyota ITC"> Toyota InfoTechnology Center USA, Inc. </organization>
<address>
<postal>
<street>465 Bernardo Ave</street>
<city>Mountain View</city>
<code>94045</code>
<region>California</region>
<country>USA</country>
</postal>
<email> ryuji@us.toyota-itc.com </email>
</address>
</author>
<author fullname="Romain Kuntz" initials="R.K." surname="Kuntz">
<organization abbrev="Toyota ITC"> Toyota InfoTechnology Center USA, Inc. </organization>
<address>
<postal>
<street>465 Bernardo Ave</street>
<city>Mountain View</city>
<code>94045</code>
<region>California</region>
<country>USA</country>
</postal>
<email> rkuntz@us.toyota-itc.com </email>
</address>
</author>
<author fullname="Zhenkai Zhu" initials="Z.Z." surname="Zhu">
<organization> UCLA </organization>
<address>
<postal>
<street>420 Westwood Plaza</street>
<city>Los Angeles</city>
<code>90095</code>
<region>California</region>
<country>USA</country>
</postal>
<email> zhenkai@cs.ucla.edu </email>
</address>
</author>
<author fullname="Lixia Zhang" initials="L.Z." surname="Zhang">
<organization> UCLA </organization>
<address>
<postal>
<street>3713 Boelter Hall</street>
<city>Los Angeles</city>
<code>90095-1596</code>
<region>California</region>
<country>USA</country>
</postal>
<email> lixia@cs.ucla.edu </email>
</address>
</author>
<date year="2011" />
<area>Internet</area><workgroup>MEXT Working Group</workgroup>
<abstract>
<t>This document presents a revised version of the global HAHA
protocol specification. Global HAHA allows the deployment of
Home Agents over the Internet for reliability, scalability and
performance purposes. This version clarifies several
issues that were vague in the original specification. Global HAHA
makes use of the signaling defined by the Home Agent Reliability
protocol (HARP) although it is not designed to operate in
conjunction with HARP.
<!--
All the protocol specifications for the global HAHA are now
added on top of the Home Agent Reliability protocol.
-->
</t>
</abstract>
</front>
<middle>
<!------------------------------------------------>
<!-- SECTION 1: INTRODUCTION -->
<!------------------------------------------------>
<section title="Introduction">
<t>The global HAHA protocol aims at leveraging the global deployment
of Home Agents over the Internet, by proposing reliability, scalability
and better performances to Mobile IPv6 <xref target="RFC6275" />
deployments.
</t>
<t>The original global HAHA protocol <xref target="I-D.thubert-mext-global-haha" />
has been discussed for several years in MIP6, NEMO and now MEXT
working groups. Several documents <xref target="I-D.thubert-mext-global-haha" />
<xref target="I-D.wakikawa-mip6-nemo-haha-spec" />
<xref target="I-D.wakikawa-mext-haha-interop2008" /> have been
published and presented in past IETF meetings, and received
valuable feedback. This document presents a revised version of
the global HAHA protocol specification. This version clarified
several issues that were vague in the original specification
<xref target="I-D.thubert-mext-global-haha" />.
</t>
<!--
All the protocol specifications for the global HAHA
are now added on top of the Home Agent Reliability protocol
<xref target="I-D.ietf-mip6-hareliability" /> which has been standardized at the MEXT working
group.
-->
<t>Global HAHA makes use of the signaling defined by the Home Agent
Reliability protocol (HARP) <xref target="I-D.ietf-mip6-hareliability" /> which is being
standardized in the MEXT working group. On one hand, HARP provides a redundancy
mechanism for the Home Agents located on the same layer-2 link (or in
different layer-2 links provided that proper routing updates are
performed between links upon failure). On the other hand, global HAHA builds on anycast
routing to not only provide redundancy but also achieve a better
distributed mobility management for Mobile IPv6. More specifically, global
HAHA provides the following advantages:
</t>
<t><list style="symbols">
<t>It eliminates the single point of failure and bottleneck in Mobile
IPv6 and NEMO protocols. By distributing multiple Home Agents
over wide areas, scalability and robustness of the mobility
infrastructure can be improved.
</t>
<t>It provides very flexible deployment schemes. When home agents
are placed at Internet Exchange Points, they can improve the performances of
mobility over long distances (such as depicted in aeronautics scenarios
<xref target="RFC5522" />) by minimizing triangle routing as
compared to the path utilizing a single home agent (so called
dog-leg routing). Alternatively, when home agents are placed
closer to the edge of the network, a more flat design can
be achieved. Offloading near the edge of the network becomes
possible, to the benefit of the core network load
<xref target="I-D.kuntz-dmm-summary" />.
</t>
<t>It makes use of existing protocols (HARP signaling
<xref target="I-D.ietf-mip6-hareliability" />, Home Agent Switch messages
<xref target="RFC5142" />) while confining the required changed
to the home agent only.
</t>
<!--<t>It can provide distributed operations to Mobile IPv6 and NEMO
protocols; and </t>-->
<!-- LZ: I am not sure what this means
RW: agree.. removed.
-->
</list>
</t>
<t>Global HAHA also provides reliability in case of a home agent failure.
Whether it would be useful to be able to combine HARP with
global HAHA for local reliability of a home agent is open for future
discussion. Such combination can bring better performances in cases
that may be unlikely to happen often, at the cost of an increased complexity.
Furthermore, whether Global HAHA should be independent from HARP and define
its own signaling protocol is also open for further discussion.
</t>
<t>The global HAHA concept has been evaluated through prototype
implementations in several places <xref target="PAPER-CONEXT" /> and the results
show that the design is simple and effective in reducing triangle routing.
Several industry sectors such as aviation <xref target="RFC5522" /> and automobile
<xref target="I-D.ietf-mext-nemo-ro-automotive-req" /> have shown their
interests in using global HAHA to meet the need for their mobility managements.
</t>
<t>As every coin has two sides, the global HAHA protocol is not an
exception. It achieves the above goals through utilizing anycast
routing, which has raised a concern on routing scalability, and it
introduces additional overheads due to the need to synchronize the
mobility state among distributed home agents. By presenting a
complete design together with the design justifications, we hope that
this document will help move the discussion towards a converged
understanding on the pros and cons of the global HAHA protocol.
</t>
</section> <!-- Intro -->
<section anchor="term" title="Terminology">
<t> This document uses terms defined in <xref target="RFC3753" />,
<xref target="RFC6275" />, <xref target="RFC3963" /> and
and <xref target="I-D.ietf-mip6-hareliability" />. A few new terms are also
introduced in this document:</t>
<t><list style="hanging">
<t hangText="Home subnet prefix"/>
<t>It is assigned to a home subnet, and the home agent unicast address
(defined below) of a mobile node is assigned out of this prefix
block. In this global HAHA specification, the home subnet prefix is
assumed to be a provider independent prefix. </t>
<t hangText="Home agent unicast address"/>
<t>A unicast IP address created from the home subnet prefix and assigned
to a home agent. This is the address used by Mobile
nodes when sending Binding Updates to their Home Agent.</t>
<t hangText="Home agent locator address"/>
<t>A unicast IP address assigned to a home agent by the ISP who provides the
Internet connectivity for the home agent. This address is
used to exchange mobility messages between globally distributed
home agents.</t>
<t hangText="Home agent anycast address"/>
<t>The anycast address defined as per <xref target="RFC2526" /> and used by mobile
nodes for Dynamic Home Agent Address Discovery purposes.
</t>
<t hangText="Global home agent set"/>
<t>The set of home agents serving the same home subnet prefix. The home
agents are located in topologically and/or geographically different locations.
A global home agent set is identified with a 8-bit group ID. </t>
<!-- LZ: What is a "group ID"? This term has not been defined so far.
-->
<t hangText="HAHA link"/>
<t>All the home agents in the same global home agent set
share the same home subnet prefix although they may be located in
different parts on Internet. In order for each of them to reach
all the others directly as required by IP subnet definition,
logical connectivity links are created between each pair of home
agents. These logical links, called HAHA links, can be realized
using IP tunnel technologies such as IP tunnel, IPsec tunnel,
L2TP, PPTP, and so on. Data packets and Binding Updates that
need to be forwarded between home agents are sent over these
HAHA links.</t>
<!--RW: REMOVED. Commends from Arnaud 7/3
If there is a dedicated link for a HAHA link, geographically
distributed home agents share a home link and can be seen
on-link each others. Therefore, no protocol extensions to Mobile
IPv6 <xref target="RFC6275" /> is required.-->
<!-- LZ: I added some clarification on what is HAHA links
-->
<t hangText="Primary Home Agent"/>
<t>The home agent which a mobile node is currently registered
with. Among all the available home agents in the same set, this
primary home agent should be topologically closest to the mobile
node. At any given time each mobile node has one primary home agent.</t>
<t hangText="Global Binding"/>
<t>When a mobile node registers with a primary home agent, the home
agent notifies this binding, called the global binding, to all the
other home agents in the same global home agent set. The receiver
of this global binging information learns the mapping between the
mobile node and its current primary home agent, and creates a
route entry for the mobile node with the next hop pointing to
the primary home agent locator address. This route entry has a
lifetime which can be different from the lifetime carried in the
original binding message. <!-- Since a care-of address information
is not used in the global binding, the relatively longer
lifetime MAY be used for the global binding.--> When the
lifetime expires, the route is deleted.</t>
</list>
</t>
</section>
<section anchor="Overview" title="Overview">
<t>
Global HAHA relies on IP anycast routing between geographically
and topologically different home agent locations. The home subnet
prefix is announced by all the home agents in a deployed global HAHA
system, so that packets from and to mobile nodes are always routed
towards the closest home agents in a way that is completely transparent
to the mobile and correspondent nodes.
</t>
<t>
Global HAHA does not require any modification to mobile nodes and
mobile routers (i.e. end mobile entity). Supporting Mobile IPv6
<xref target="RFC6275" /> and Home Agent Switch message <xref target="RFC5142" />
is sufficient to run mobile nodes with globally distributed home
agents.
</t>
<t><xref target="fig:overview"/> shows the protocol sequence of
the global HAHA. As an assumption, each home agent in the same
global home agent set MUST establish HAHA links for
interconnecting other home agents. The detail of HAHA link
establishment is described in <xref target="sec:HAsboot"/>.</t>
<figure anchor="fig:overview" title="Overview of global HAHA">
<artwork>
<![CDATA[
MN HA1 HA2 CN
| | | |
|----> (Primary) | | 1. Binding Update
|<--------| | | 2. Binding Acknowledgment
| |-------->| | 3. State Synchronization
|<========|<========|<--------| 4. From CN to MN
|========>|------------------>| 5. From MN to CN
| | | |
: : : : MN MOVEMENT
| | | |
|------------------+| | 6. Binding Update
| |<=======+| |
|<--------| | | 7. Binding Acknowledgment
|<--------| | | 8. Home Agent Switch
|--------------> (Primary) | 9. Binding Re-registration
| |<--------| | 10. State Synchronization
|<==================|<--------| 11. From CN to MN
|==================>|-------->| 12. From MN to CN
| | | |
==== for tunneling
---- for direct packets
]]>
</artwork>
</figure>
<section title="Initial Binding Registration">
<t>Global HAHA home agents can be reached by the mobile node through
both the home agent anycast address (e.g. obtained with Dynamic Home Agent
Address Discovery <xref target="RFC6275" />) and the Home agent unicast address (e.g.
obtained from the DNS) created from the home agent home subnet prefix
(see <xref target="sec:discovery"/>).
Note that the home agent locator address is not known by the mobile
nodes and is only used between global home agents to exchange mobility
messages among them.
</t>
<t>When the mobile node attempts the binding registration to a
home agent using the HA anycast address (operation 1 in
<xref target="fig:overview"/>), the binding update is routed to the
topologically closest home agent of the mobile node via IP anycast
routing. The closest home agent which the mobile node registers its
binding with is called a primary home agent for the mobile node. This
specification assumes that the route of home subnet prefix is advertised
from each of different locations where an HAHA home agent resides.
</t>
<t>After sending a binding Acknowledgment to the mobile node (operation
2 in <xref target="fig:overview"/>) and registering a binding cache for
the mobile node, the primary home agent (HA1) sends State Synchronization
messages to all the other home agent (i.e. HA2) in the same global home agent
set (operation 3 in <xref target="fig:overview"/>). Then, HA2 creates a
global binding for the mobile node and creates the mobile node's route entry
with the next hop set to the locator address of the primary home agent (HA1).
The global binding needs to be updated when a mobile node changes its primary
home agent. It must also be refreshed before its lifetime expiration.
</t>
<t>When HA2 receives packets from a correspondent node destined to the
mobile node, it forwards them to the primary home agent (HA1) over the
HAHA link according to the global binding (operation 4 in
<xref target="fig:overview"/>). When a mobile node sends data to the
correspondent node, the traffic is tunneled to the primary home agent,
which then routes directly to the destination (operation 5 in
<xref target="fig:overview"/>).
</t>
<t>If the mobile node obtained the home agent unicast address through
the DNS, and that address does not correspond to the topologically closest
home agent, a home agent switch will be performed as described in the next
section.
</t>
</section>
<section title="Primary Home Agent Switch">
<t>In this example, from the routing perspective, the closest
home agent of the mobile node is now changed from HA1 to HA2
after a mobile node's movement. Thus, the primary home agent of
the mobile node needs to be updated from HA1 to HA2. This case can also
happen if the home agent unicast address obtained from the DNS (during the
bootstrapping phase of the mobile node) is set to HA1 whereas the
mobile node is initially closer to HA2.
</t>
<t>The Primary Home Agent switch operation consists of two binding
updates exchange. The first binding update is used to detect
the closer home agent by the current primary home agent. The
second binding update is to let the mobile node change its
primary home agent. </t>
<!-- LZ: We need to add a sentence to the beginning of this
paragraph to explain when a mobile node may change its
point of attachment.
-->
<t>When a mobile node changes its point of attachment, it
simply sends the first Binding Update to its current primary
home agent (i.e. HA1 in <xref target="fig:overview"/>) in
order to renew its binding as per <xref target="RFC6275" />.
However, since HA2 also advertises the same home subnet prefix, the
Binding Update is first routed to the HA2 by IP anycast
routing. HA2 knows that HA1 belongs to the same global Home Agent
set, and thus forwards the Binding Update to its destination
(HA1) over the HAHA link (operation 6 in
<xref target="fig:overview"/>).</t>
<t>Due to fact that the binding update is forwarded from one
of other home agents in the same global home agent set, the
HA1 now detects that the primary home agent is changed to
the HA2. The HA1 first processes the Binding Update and
returns a Binding Acknowledgment to the mobile node (operation 7
in <xref target="fig:overview"/>). In parallel, it triggers a
Home Agent Switch message <xref target="RFC5142" /> to the mobile node
(operation 8 in <xref target="fig:overview"/>).
In the Home Agent switch message, the home agent unicast address of HA2
is stored in the Home Agent Address field so that the mobile node
can associate with the closest home agent.</t>
<t>When the mobile node receives the Home Agent Switch message
from the HA1, it switches its home agent to the HA2 according
to <xref target="RFC5142" />. The mobile node sends another Binding Update
to the HA2 (operation 9 in <xref target="fig:overview"/>).
After receiving the Binding Update, the HA2
creates the binding cache and sends a State Synchronization
message to the other Home Agents (i.e. HA1) in the global home
agent set (operation 10 in <xref target="fig:overview"/>).
The HA1 removes the binding cache entry of the
mobile node and creates a global binding as well as the route
for the mobile node with the next hop set to the locator address of
HA2 over the HAHA link.</t>
</section>
<section title="Routing Packets">
<t>The packets originated by the mobile node are always routed
through the primary home agent as shown in operations 5 and
12 in <xref target="fig:overview"/>. They are tunneled to the
primary home agent and, then, routed directly to the CN. </t>
<t>On the other hand, the packets originated by the
correspondent node are routed to the closest home agent by IP
anycast routing as shown in operations 4 and 11 in
<xref target="fig:overview"/>. If the home agent is not the primary home
agent of the mobile node (destination), the home agent looks
up the global binding and routes them to the primary home
agent of the mobile node over the HAHA link. Then, the primary
home agent routes the packets to the mobile node over the
Mobile IPv6's bi-directional tunnel.</t>
<t>In some scenario, the path between a mobile node and a
correspondent node becomes asymmetric. In the global HAHA, the
primary home agent does not have any specific information of
the correspondent nodes and does not forward the packets to
the closest home agent of the correspondent node. </t>
</section>
<section title="Differences between global HAHA and HARP">
<!--
This protocol is defined as an extension to the Home Agent
Reliability protocol.
-->
<t>The global HAHA protocol makes use of the signaling defined
by the Home Agent Reliability protocol (HARP) <xref target="I-D.ietf-mip6-hareliability" />
which is being standardized in the MEXT working group.
However, global HAHA is not designed to be operated in conjunction
with HARP. HARP extends Mobile IPv6 <xref target="RFC6275" /> to
provide reliability to home agents. Its concept is similar to the
router's redundancy protocols such as VRRP and HSRP. When one home
agent fails, another standby home agent located in the same home link
or in a different network can immediately take over the function of
the failed one, so that ongoing sessions of mobile nodes will not be
interrupted by any single home agent failures.
</t>
<t>
<!-- However, when HARP is used with home agents distributed across
different networks, routing updates are required to redirect traffic
from the home link to the recovery link.
-->
Global HAHA can also achieve reliability by relying on IP anycast
routing. The home subnet prefix being announced by all the home agents,
packets from and to mobile nodes can be forwarded to remaining functional
home agents in a transparent manner. In addition, global
HAHA can achieve better scalability and provide optimized paths
between a mobile node and its correspondents, by always
associating the nearest home agent to the mobile node.
</t>
</section>
</section><!--Overview-->
<section anchor="sec3:configuration" title="Home Agent Configurations">
<section anchor="sec3:haditribution" title="Home Agent and Subnet Distributions">
<!--
<t><xref target="fig:hadist"/> shows the home agents located on
the same home link as introduced in <xref target="RFC6275" /> and
<xref target="I-D.ietf-mip6-hareliability" />. Multiple home agents are placed on the same
home subnet (2001:db8:0:1::/64) and standby home agents are
prepared for home agent reliability <xref target="I-D.ietf-mip6-hareliability" />. The home
agents are assigned with different IP address as an individual
home agent address. The standby home agent for HAa, HAa', shares the
same IP address with HAa.</t>
<figure anchor="fig:hadist" title="Home Agents Distribtuion">
<artwork>
<![CDATA[
+--------+
|Internet|
+--------+
|
--+---+---+--Home Link (2001:db8:0:1::/64)
| | |
HAa HAb (HAa')
HA Address
- HAa 2001:db8:0:1::1
- HAb 2001:db8:0:1::2
- HAa' 2001:db8:0:1::1 (Standby)
]]>
</artwork>
</figure>
-->
<!-- <figure anchor="fig:hsubnetdist" title="Home Subnets Distribtuion">
<artwork>
<![CDATA[
2001:db8::/n (PI Prefix)
Home Link1
----+----
|
+--------+
| ISP1 |
+--------+
|
+--------+ +--------+ |
|Backbone|--| ISP2 |----+ Home Link2
+--------+ +--------+ | 2001:db8::/n
| (PI Prefix)
+--------+
| ISP3 |
+--------+
|
----+------
Home Link3
2001:db8::/n
(PI Prefix)
]]>
</artwork>
</figure>-->
<!--
<t><xref target="fig:combdist"/> shows the combination of home
agents and subnets distribution in a global HAHA system. Home
agents are connected to a number of subnets located in various
places on Internet, they are all assigned the same
Provider-Independent (PI) prefix as their home subnet prefix. Each
home subnet is connected to the global Internet through an ISP who
also assigns a prefix out of its own address block to the home
subnet. We call this ISP assigned prefix "Locator Prefix" (LP).
Each home agent has two IP addresses: one from its PI home
subnet prefix and another from its provider.
Each ISP that hosts a HAHA subnet also agrees to announce the
HAHA's PI Home subnet prefix to the global Internet, so that
packets destined to any IP address that belongs to the home
subnet prefix are delivered to the topologically closest home
agent.
</t>
<figure anchor="fig:combdist" title="Home Subnets and Agents Distribution">
<artwork>
<![CDATA[
Home Link1 (2001:db8:0:1::/64)
HA1a HA1b (HA1a')
| | |
----+----
| /|\ LP-1 Prefix
+--------+ |
| ISP1 |
+--------+ LP-2 Prefix
| --> +- HA2a
+--------+ +--------+ |
|Backbone|--| ISP2 |----+ Home Link2
+--------+ +--------+ | (2001:db8:0:1::/64)
| +- (HA2a')
+--------+
| ISP3 |
+--------+ | LP-3 Prefix
| \|/
+----+----+
| |
HA3a (HA3a')
Home Link3 (2001:db8:0:1::/64)
HA address (PI) HA Locator address (LP)
- HA1a 2001:db8:0:1::1a LP-1Prefix::1a
- HA1b 2001:db8:0:1::1b LP-1Prefix::1b
- HA1a' 2001:db8:0:1::1a LP-1Prefix::1a (Standby)
- HA2a 2001:db8:0:1::2a LP-2Prefix::2a
- HA2a' 2001:db8:0:1::2a LP-2Prefix::2a (Standby)
- HA3a 2001:db8:0:1::3a LP-3Prefix::3a
- HA3a' 2001:db8:0:1::3a LP-3Prefix::3a (Standby)
]]>
</artwork>
</figure>-->
<t><xref target="fig:hahadist"/> shows the subnet and home agent
distribution in a global HAHA system. Home agents are connected to a
number of subnets located in various places on Internet, they are all
assigned the same Provider-Independent (PI) prefix as their home subnet
prefix. Each home subnet is connected to the global Internet through
an ISP who also assigns a prefix out of its own address block to the home
subnet. We call this ISP assigned prefix "Locator Prefix" (LP).
Each home agent has two unicast IP addresses: one from its PI home
subnet prefix (the "home agent unicast address") and another from its
provider (the "home agent locator address"). Each ISP that hosts a
HAHA subnet also agrees to announce the HAHA's PI Home subnet prefix
to the global Internet, so that packets destined to any IP address
that belongs to the home subnet prefix are delivered to the topologically
closest home agent.
</t>
<figure anchor="fig:hahadist" title="Home Subnets and Agents Distribution">
<artwork>
<![CDATA[
Home Link1 (2001:db8:0:1::/64)
HA1
|
--+--
| /|\ LP-1 Prefix
+--------+ |
| ISP1 |
+--------+ LP-2 Prefix
| -->
+--------+ +--------+ |
|Backbone|--| ISP2 |----+- HA2 Home Link2
+--------+ +--------+ | (2001:db8:0:1::/64)
|
+--------+
| ISP3 |
+--------+ | LP-3 Prefix
| \|/
--+--
|
HA3
Home Link3 (2001:db8:0:1::/64)
HA unicast address (PI) HA locator address (LP)
- HA1 2001:db8:0:1::1 LP-1Prefix::1
- HA2 2001:db8:0:1::2 LP-2Prefix::2
- HA3 2001:db8:0:1::3 LP-3Prefix::3
]]>
</artwork>
</figure>
</section>
<section anchor="sec3:anycast" title="Anycast Routing Consideration">
<t><!-- TBA: Explanation of MOAS PREFIX OPERATION -->
IP anycast routing has been widely used in recent years. As
documented in <xref target="RFC4786" />, anycast has become
increasingly popular for adding redundancy to DNS servers to
complement the redundancy that the DNS architecture itself
already provides. Several root DNS server operators have
distributed their servers widely around the Internet, and DNS
queries are directed to the nearest functioning
servers. Another popular anycast usage is by web service
providers, where two or more web farms share the same IP
prefix, so that when all the sites are up, HTTP requests are
forwarded to the web servers closest to the browsers; when a
site is down, requests are automatically routed to next
nearest web farm. Anycast routing provides a simple and
effective means to provide robust services.
</t>
<t><!-- TBA: Consideration of BGP Impact -->
A concept related to anycast is MOAS (Multi-Origin AS)
prefixes, they are prefixes advertised by more than one origin
AS. A MOAS prefix represents an anycast prefix, although the
inverse is not necessarily true, i.e. an anycast prefix may
not be a MOAS prefix if the prefix is announced to the routing
system by one origin AS out of the AS's multiple locations.
Our measurement using BGP data collected by RouteViews and
RIPE observed about 2000 or so MOAS prefixes in today's global
routing system, which is a very small percentage of the
current routing table entries of about 300K entries.</t>
<t>One basic cost from providing anycast services is an
additional entry in the global routing table for each anycast
prefix. When the number of anycast applications is small, the
impact on the global routing system scalability is small. The
use of anycast for important infrastructure services, such as
DNS root servers, is well justified. Using anycast to bootstrap
other important services may also be justified, if the
services are globally scoped are commonly used, and the number
of anycast prefixes needed is small. However anycast is
clearly not for everyone or for all applications usage. It is
a worthwhile investigation to consider where best to draw the
line.
</t>
<!-- <t>Since the same home subnet prefix is advertised from multiple
Autonomous System's in anycast manner, each home agent MUST
provider the same service to the home agent. In this
specification, a mobile node can use any of home agents in the
same global home agent set. </t>-->
<!-- LZ: this last paragraph seems out of place?
RW: Agreed and removed.
-->
</section>
</section>
<section anchor="sec:globalhaha" title="Global HAHA Protocol">
<section anchor="sec:HAsboot" title="Home Agents Bootstrap">
<t>For the global HAHA protocol, each home agent SHOULD be
configured with the following information:</t>
<t><list style="symbols">
<t>An own home subnet prefix (Provider Independent prefix, PI)</t>
<t>An own home agent unicast address (created from the PI)</t>
<t>An own home agent locator address (created from the Locator Prefix, LP)</t>
<t>A home agent anycast address for Dynamic Home Agent Address
discovery mechanism (created as per <xref target="RFC2526" />)</t>
<t>A Group ID of own global home agent set</t>
<t>Home Agent locator addresses of all the other home agents in
the same global home agent set.</t>
</list></t>
<t>A home agent first establishes HAHA links with all the other
home agents. How to establish a HAHA link is out of scope in
this document. For instance, IP tunnel is established between
two home agent's locator addresses. This HAHA link is used to
exchange data packets destined to the mobile node and binding updates
coming from the mobile node. Although all the Binding Updates are
already securely exchanged, it is recommended to secure every packets
tunneled over this HAHA link. Note that Home Agent HELLO message and
State Synchronization message do not need to be tunneled over the
HAHA link as they can be sent directly using the Home Agent
locator addresses as source and destination addresses.
</t>
<t>As soon as HAHA links are fully ready, the home agent now
provides its home agent service to a mobile node. Without HAHA
links, a home agent SHOULD NOT configure with its home subnet
prefix and act as a home agent of the home subnet prefix. The
home agent now starts sending its Home Agent HELLO message as
described in <xref target="sec:hamanagement"/> and soliciting
global bindings of all the other home agents as discussed in
<xref target="subsec:gbregist"/>.</t>
</section>
<section anchor="sec:hamanagement" title="Management of global Home Agent set">
<t>A home agent exchanges its availability with other home agents
of the same global home agent set. The status exchange is done
with a Home Agent HELLO message defined in the Home Agent
Reliability protocol <xref target="I-D.ietf-mip6-hareliability" />.
<!--
RK: Commented the below sentence, because HARP now also allows to have
HA distributed across different networks. Discussion about Hello interval
values should thus occur in the HARP draft, not here.
-->
<!--
Unlike the Home Agent
Reliability protocol, geographically separated home agents are
operated more carefully and their availability should be always
confirmed (ex. by the Home Agent Reliability
protocol). Therefore, it MAY use longer interval value for the
hello message exchange, because these messages are exchanged
over the network (i.e. not on the same link).
-->
</t>
<section anchor="subsec:hal" title="Home Agent List for the global HAHA">
<!--
RK: For the same reasons as above, commented the below paragraph.
More general discussion about Home Agent List items should be done in the HARP
draft. We should only discuss specific global HAHA items here.
-->
<!--
<t><xref target="RFC6275" /> specifies the data structure named the Home Agent
List. This list is used to manage home agent information at a same
home link. In this specification, the home agent list is
extended to manage geographically distributed home
agents. The following information MUST be stored for globally
distributed home agents in the home agent list: </t>
<t><list style="symbols">
<t>home agent address(es)</t>
<t>home agent locator address(es)</t>
<t>The remaining lifetime of this Home Agent List entry</t>
<t>Group ID of global home agent set</t>
</list></t>
-->
<t><xref target="RFC6275" /> and <xref target="I-D.ietf-mip6-hareliability" />
specify and extend the data structure
named the Home Agent List. This list is used to manage home agent
information at a same home link. The following two fields introduced
in <xref target="RFC6275" /> are not used in this specification:
</t>
<t><list style="symbols">
<t>The link-local IP address of a home agent </t>
<t>The preference for this home agent</t>
</list></t>
<!--
RK: what about VHARP capability flags? This is not clear whether global HAHA
is supposed to support VHARP too
-->
</section>
<section anchor="sec:hello" title="Modified HARP Message">
<t>This specification defines a new flag for the HARP HA-HELLO message
(Type 4):
</t>
<figure anchor="fig:hello-msg" title="HARP Message">
<artwork>
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |A|R|V|M|G| Rsvd| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. Mobility Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Home Agent Preference"/>
<t>In this specification, a same preference value is
used among home agents in a global home agent set. A home
agent is selected by a mobile node according to routing
topology (i.e. anycast routing), but not by these preference
values. This value SHOULD be set to 0. The receiver SHOULD
ignore this value.</t>
<t hangText="Group Identifier"/>
<t>This value is used to identify a particular global home
agent set.</t>
<t hangText="Global (G) flag"/>
<t>Global HA flag. If this flag is set, the home agent sending
this HA-HELLO message is operated with this specification.</t>
</list></t>
</section>
<section anchor="subsec:sendinghello" title="Sending Home Agent Hello Messages">
<t>Each home agent periodically sends HA-HELLO to the other home
agents in the same global home agent set. Each home agent MUST
also generate HA-HELLO in the following cases:</t>
<t><list style="symbols">
<t>when a home agent receives a HA-HELLO with the G (Global HA) and R (Request) flag set</t>
<t>When a new home agent boots up, it SHOULD solicit HA-HELLO
messages by sending a HA-HELLO with the G and R-flag set
in parallel with sending its own HA-HELLO message.</t>
</list></t>
<t>When a home agent sends HA-HELLO, the following rule MUST be
applied in addition to the Section 4.3.2.1 of <xref target="I-D.ietf-mip6-hareliability" />.</t>
<t><list style="symbols">
<t>It MUST set G flag in HA-HELLO.</t>
<t>It MUST specify its global home agent set's ID to the Group
ID field in HA-HELLO.</t>
<t>The source and destination IPv6 addresses of the IPv6
header of the HA-HELLO MUST be the source and destination
home agent locator addresses. They MUST belong to the
same global home agent set.</t>
<t>It MUST protect HA-HELLO by IPsec ESP.</t>
</list></t>
</section>
<section anchor="subsubsec:reccvhello" title="Receiving Hello Message">
<t>When a home agent receives HA-HELLO, it follows the
verification described in Section 4.3.2.2 of
<xref target="I-D.ietf-mip6-hareliability" />. In addition to this, it MUST process
HA-HELLO which G flag is set as follows: </t>
<t><list style="symbols">
<t>If the HA-HELLO is not protected by IPsec ESP, it MUST be
discarded.</t>
<t>If the source IPv6 address of HA-HELLO does not belong to one
of the home agents in the redundant home agent set, the
HA-HELLO MUST be ignored.</t>
<t>If the Group ID field of the received HA-HELLO and the
receiver's Group ID are different, HA-HELLO MUST be
discarded. HA-HELLO MUST NOT be sent to home agents whose
Group ID is different from the sender.</t>
<t>HA-HELLO satisfying all of above tests MUST be processed by
receiver. The receiver copies home agent information in
HA-HELLO to the corresponding home agent list entry. The
home agent locator address of the sender is retrieved from the
source address field of the IPv6 header of the
HA-HELLO. </t>
</list></t>
</section>
</section>
<section anchor="sec:BU" title="Primary Home Agent Receiving Binding Update">
<t>The binding update sent by a mobile node is routed to the one
of home agents in the global home agent set according to the
anycast routing. If the receiver does not have any binding cache entry
nor global binding for this mobile node, it processes the
binding update according to <xref target="RFC6275" /> and stores a binding cache entry
for the mobile node. After successful binding registration, the home
agent becomes a primary home agent for the mobile node. The
primary home agent has the following functional requirements:</t>
<t><list style="symbols">
<t>Delivering IP packets destined to the mobile node over the
bi-directional tunnel</t>
<t>Updating the binding according to the mobile node's binding
refreshment</t>
<t>Notifying the mobile node binding to the other home agents in
the same global home agent set</t>
<t>Sending a Home Agent Switch message if another home agent is
more preferable to be the primary home agent. Usually, this is
trigerred by the reception of a valid Binding Update via another home agent of the
global home agent set</t>
<t>Providing state synchronization information to other home
agents of the global home agent set when a binding is created,
updated, removed or upon request. </t>
</list></t>
<t>The binding registration and management are the same as specified in
<xref target="RFC6275" />. The global HAHA requires to register global bindings
of the mobile node by sending the state synchronization message
to all the other home agents as described in the next
section.</t>
</section>
<section anchor="sec:BN" title="Global Binding Management">
<section anchor="subsec:globalBinding" title="Global Binding">
<t>A global binding has the following information. Any mobile
node's specific information can be potentially stored in the
global binding. The aim of this global binding is to forward
the data packets of a mobile node received at non-primary home
agent to the primary home agent of the mobile node. It is not
used to deliver a packet directly to a mobile node from the
non-primary home agents. Therefore, the mobile node's care-of
address is not necessary in the global binding, more than
likely the primary home agent of the mobile node is important
in the global binding.</t>
<t><list style="symbols">
<t>The primary home agent locator address</t>
<t>The mobile node's home address</t>
<t>The mobile router's mobile network prefix(es)</t>
<t>The binding sequence number of a binding update</t>
<t>The flags of a binding update</t>
<t>The lifetime of the global binding</t>
<t>The mobile node's care-of address (optional)</t>
</list></t>
<t>The modified State Synchronization message <xref target="I-D.ietf-mip6-hareliability" />
described in the next section is used to exchange the global bindings
among the home agents.</t>
<t>When a global binding is created, the home agent MAY use
proxy Neighbor Discovery or IP routing to intercept the packets
addressed to the mobile node's home address.
</t>
<!--If there is only a single home
agent at a home link, it simply skips the proxy neighbor
discovery and intercepts the packet according to IP
routing.
-->
<t>When a global binding is created, the home agent MUST create
a mobile node's route entry which next hop is set to the locator
address of the primary home agent. If a mobile node is a mobile router
<xref target="RFC3963" />, the following mobile node's routes are
created: one for the home address and one per mobile network prefix.
If the mobile router's home address is derived from its mobile network
prefix <xref target="RFC3963" /> (i.e. the operation of aggregated home
network <xref target="RFC4887" />), only a single route for the mobile
network prefix is sufficient.</t>
</section>
<section anchor="subsec:statesync" title="Modified State Synchronization Message and Mobility Option">
<t><xref target="fig:bc_syn_req-msg"/> shows the modified version
of the state synchronization (SS) message defined in
<xref target="I-D.ietf-mip6-hareliability" />. A new G flag is introduced to explicitly
indicate the global binding registration.</t>
<figure anchor="fig:bc_syn_req-msg" title="State Synchronization Message">
<artwork>
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Global (G) flag"></t>
<t>When State Synchronization messages are exchanged
for global binding registration, the Global flag MUST
be set.</t>
<t hangText="Mobility Options"></t>
<t>The Binding Cache Information Option as defined in
<xref target="I-D.ietf-mip6-hareliability" /> is mandatory for the State Synchronization
Request (SS-REQ) message (Type 0) as well as State Synchronization
Reply (SS-REP) message (Type 1).</t>
<!--One of the following options is mandatory in SS-REQ
message. Multiple same options can be stored in the same
SS-REQ message, (ex. two IP address options for two mobile
nodes):
<list style="symbols">
<t>NAI Option</t>
<t>IP Address Option (Sub-type: Home Address) defined in
<xref target="RFC5268" />. If a home agent wants the Binding Cache
information for a particular mobile node, it includes
the mobile node's home address in an IPv6 Address
Option. If a home agent want to solicit all the active
mobile nodes' states, it can include the unspecified
address (0::0) in an IPv6 address option.</t>
<t>Mobile Network Prefix Option. If a home agent wants to
know the forwarding state setup for a particular Mobile
Network Prefix, it includes a Mobile Network Prefix
Option as defined in <xref target="RFC3963" />.</t>
<t>Vendor Specific Mobility Option. If a home agent wants
vendor specific information, it can solicit with this
option as defined in <xref target="RFC5094" />.</t>
</list></t>-->
<t>Others options (e.g. AAA Information option,
Vendor Specific Mobility option, as well as the others referenced in
<xref target="I-D.ietf-mip6-hareliability" />) can be used too.</t>
<t>The SS Status Option as defined in <xref target="I-D.ietf-mip6-hareliability" /> MUST be used
in the State Synchronization Reply-Ack (SS-ACK) message (Type 2).</t>
</list></t>
<!--
RK: commented this paragraph because the SS Status option is now defined in
the HARP draft
-->
<!--
<t><xref target="fig:ss-status"/> is a new mobility option of
State Synchronization message. In the global HAHA, SS-ACK is
mandatory for receivers of SS-REP to notify the global binding
registration status</t>
<figure anchor="fig:ss-status" title="State Synchronization Status Option">
<artwork>
<![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t><list style="hanging">
<t hangText="Type"/>
<t>8-bit Type value. The value is TBD.</t>
<t hangText="Length"/>
<t>8-bit length value.</t>
<t hangText="Status"/>
<t>8 bit Status value of global binding registration.
<list style="symbols">
<t>0: Success</t>
<t>128: Reason unspecified</t>
<t>129: Malformed SS-REP</t>
<t>130: Not in same global home agent set</t>
<t>131: No Mobility Option</t>
</list></t>
<t hangText="Reserved"/>
<t>24 bit Reserved fields </t>
<t hangText="Home Address"/>
<t>Corresponding home address of the status code.</t>
</list></t>
-->
</section>
<section anchor="subsec:gbregist" title="Global Binding Registration">
<t>If a primary home agent sends a SS-REP message for every binding
registration from a mobile node, it causes certain overhead to exchange
messages. Unless the binding information is changed (except
for sequence number and lifetime), the state synchronization
reply message is not necessarily sent per mobile nodes' binding
refreshment. A SS-REP message MUST be sent by a
primary home agent to register a global binding at the
following timing:</t>
<t><list style="symbols">
<t>When a primary home agent registers a binding for a mobile
node for the first time. The primary home agent MUST
register a global binding to the global home agent
set.</t>
<t>When a global binding is expired. The primary home agent
MUST refresh the global binding.</t>
</list></t>
<t>When a primary home agent receives a binding update from a
mobile node and registers a binding for it, it sends a State
Synchronization Reply message. SS-REP is sent to all the other
home agents in the global home agent set with the following
rules:</t>
<t><list style="symbols">
<t>The A (Ack) and G (Global) flags MUST be set in SS-REP.</t>
<t>At least, one Binding Cache Information Option MUST be
stored in the mobility option field. Multiple options can be
stored in a SS-REP.</t>
<t>Other optional mobility options listed in
<xref target="subsec:statesync"/> MAY be stored in the
mobility option field. </t>
<t>IPsec ESP MUST be applied.</t>
<t>The source and destination addresses of the SS-REP MUST be
the source and destination home agent locator addresses.</t>
<t>The source and destination addresses MUST belong to the
same global home agent set.</t>
</list></t>
<t>When a home agent receives the SS-REP, the following rules
must be applied to the received SS-REP:</t>
<t><list style="symbols">
<t>If the SS-REP is not protected by IPsec ESP, it MUST be
discarded. </t>
<t>If no options are carried in SS-REP, the receiver MUST
ignore the SS-REP and MUST send SS-ACK with the Status
Synchronization Status option which status value is set to
the newly defined value [131: No Mobility Option].</t>
<t>If the sender of SS-REP is not in the same global home
agent set, the receiver MUST reject the SS-REP and MUST send
SS-ACK with the Status Synchronization Status option which
status value is set to [130: Not in same global home agent
set].</t>
<t>If the G flag is not set in RR-REP, the receiver MUST
ignore the SS-REP and MUST send SS-ACK with the Status
Synchronization Status option which status value is set to
[129: Malformed SS-REP].</t>
<t>If no errors are found in SS-REP, the receiver MUST register
or update the global binding per Binding Cache Information
Option. If the supplemental mobility options are specified
for a mobile node, the information MUST be stored in the
global binding. </t>
<t>After the successful global binding registration, it MUST
create a mobile node's route entry which next hop is set to
the primary home agent locator address (i.e. the sender of SS-REP). If a
mobile node is a mobile router <xref target="RFC3963" />, the following
mobile node's routes are created: one for the home address
and one per mobile network prefix. If the mobile router's
home address is derived from its mobile network prefix
<xref target="RFC3963" /> (i.e. the operation of aggregated home network
<xref target="RFC4887" />, only a single route for the mobile network
prefix is sufficient.</t>
<t>The receiver of SS-REP then sends SS-ACK with state
synchronization status mobility options for all the mobile
nodes registering its global binding.</t>
</list></t>
<t>When a home agent needs to solicit SS-REP, it can send SS-REQ
to a home agent. The rules to construct SS-REQ is described in
Section 4.4.3 of <xref target="I-D.ietf-mip6-hareliability" />. In addition, the
following rules MUST be applied: </t>
<t><list style="symbols">
<t>IPsec ESP MUST be applied.</t>
<t>The source and destination addresses of the SS-REQ MUST be
the source and destination home agent locator addresses.</t>
<t>The source and destination addresses MUST belong to the
same global home agent set.</t>
</list></t>
</section>
</section>
<section anchor="sec:HASWITCH" title="Primary Home Agent Switch">
<t>Primary Home Agent switch operation consists of two binding
update exchanges. The first binding update is basically used by a
primary home agent to detect the better home agent in the same
global home agent set and to trigger sending a home agent switch
message to mobile nodes. The second one is to complete primary
home agent switch by registering the binding to the new primary
home agent. </t>
<t>When a mobile node moves, it sends a binding update to its
primary home agent currently registering the binding. If the
binding update is directly routed to the destination (i.e. home
agent), there is no need to start the primary home agent
switch. On the other hand, if the binding update is first routed
to one of non-primary home agents, the receiver of the binding
update SHOULD become the primary home agent of the mobile node
from the routing perspective. The receiver does not operate any
inspection of the binding update and simply forwards it to the
destination address of the binding update over the HAHA
link.</t>
<t>Once the primary home agent receives the binding update
forwarded by one of home agents in the same global home agent
set, it processes the binding update as described in
<xref target="sec:BU"/>. In addition, it starts sending a home
agent switch message <xref target="RFC5142" /> for the primary home agent
switch operation. How to send the home agent switch message is
described in <xref target="RFC5142" /> and Section 4.5 of <xref target="I-D.ietf-mip6-hareliability" />.
</t>
<t>The mobile node receiving the home agent switch message simply
updates its home agent address and re-registers its binding to
the new primary home agent. The new primary home agent sends
SS-REP to all the other home agents to update its global
binding. After receiving SS-REP, the previous primary home agent
SHOULD delete its original binding and create a global binding
for the mobile node. According to <xref target="RFC5142" />, upon receipt of a
Home Agent Switch message, the mobile node must delete its home
binding by sending a Binding Update deregistration
message. However, the mobile node SHOULD NOT send this
de-registration in this specification, since the previous active
home agent knows the primary home agent switch by receiving the
SS-REP. Although this represents a slight modification of the mobile
node side, this helps achieving minimum latency of the primary
home agent switch by eliminating the binding de-registration process.
</t>
</section>
<section anchor="sec:routing" title="Packet Interception and Delivery">
<t>When a home agent receives a packet destined to a mobile node,
it first check the binding cache. If it finds an original
binding, it tunnels the packet to the mobile node over the
bi-directional tunnel. Otherwise, it checks the global binding
of the mobile node. If it finds the global binding, it then
routes the packet to the primary home agent recorded in the
global binding over the HAHA link. The packet is delivered to
the primary home agent by IP encapsulation. In the outer IP
header, the home agent source and destination locator addresses
should be used. If
neither a binding nor a global binding is found, the packet MUST
be simply discarded. The home agent SHOULD return an ICMP
Destination Unreachable (Code 3) message to the packet's source
address (unless this source address is a multicast address).
</t>
</section>
<section anchor="sec:discovery" title="Home Agents Discovery">
<t>When a mobile node boots up and needs to discover a home agent,
it can either use Dynamic Home Agent Address Discovery (DHAAD) or
perform a DNS lookup by home agent name or service name as
specified in <xref target="RFC5026" />.
</t>
<t>In the DHAAD case, the mobile node simply sends a DHAAD request
message to the home agent anycast address. In that case, the DHAAD
request message is routed to the closest home agent via IP anycast
routing. The closest home agent SHOULD return its own unicast address
with the highest priority in the DHAAD reply message so that the
mobile node can use the closest home agent for its binding
registration.
</t>
<t>In the DNS case, the lookup by home agent name or service name may
return either the home agent anycast address or a home agent unicast
address. In both cases, the binding update sent by the mobile node will
reach the closest home agent thanks to IP anycast routing. However,
in the second case, the binding update may be forwarded by that home
agent towards the owner of the home agent unicast address used in the
binding update. In that case, a primary home agent switch may be initiated
right after the registration of the mobile node. In order to avoid this case,
the DNS may be configured to return only the home agent anycast address, or
have the necessary mechanisms to return the unicast address of
the closest home agent for the mobile node.</t>
</section>
</section>
<section title="IANA considerations">
<!-- Messages are defined in HARP, this document does not
specify any new ones -->
<t>This document does not contain any actions for the IANA</t>
</section>
<section title="Security Considerations">
<t>TBA: Section 7 of <xref target="I-D.ietf-mip6-hareliability" />
gives useful information.</t>
</section>
<section title="Acknowledgements">
<t>We would like to thank to Pascal Thubert and Vijay Devarapalli for
the original discussion of the global HAHA. We also thank to Arnaud
Ebalard for his review and valuable comments.
</t>
</section>
<?rfc compact="yes" ?>
</middle>
<!-------------------------------------------------------->
<!-- Back Section -->
<!-------------------------------------------------------->
<back>
<!-------------------------------------------------------->
<!-- REFERENCES -->
<!-------------------------------------------------------->
<references title="Normative References">
&rfc6275;
&rfc3963;
&rfc5142;
&idHARP;
</references>
<references title="Informative References">
&rfc2526;
&rfc5026;
&rfc3753;
&rfc2991;
&rfc4885;
&rfc4887;
&rfc4888;
&rfc4889;
&rfc4786;
&rfc5522;
&idHAHA;
&idHAHAPROTO;
&idHAHAINTER;
&idNEMOAUTO;
&idDMMSUMMARY;
<reference anchor="PAPER-CONEXT">
<front>
<title>Migrating Home Agents towards Internet-Scale Mobility Deployments
</title>
<author initials="R.W." surname="Wakikawa" fullname="Ryuji Wakikawa">
</author>
<author initials="G.V." surname="Valadon" fullname="Guillaume Valadon">
</author>
<author initials="J.M." surname="Murai" fullname="Jun Murai">
</author>
<date month="December" year="2006" />
</front>
<seriesInfo name="CoNEXT 2006" value="Conference on Future Networking Technologies" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:40:53 |