MEXT Working Group R. Wakikawa
Internet-Draft Toyota ITC
Intended status: Experimental Z. Zhu
Expires: January 7, 2010 L. Zhang
UCLA
July 6, 2009
Global HA to HA Protocol Specification
draft-wakikawa-mext-global-haha-spec-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Wakikawa, et al. Expires January 7, 2010 [Page 1]
Internet-Draft Global HAHA Specification July 2009
Abstract
This document presents a revised version of the global HAHA protocol
specification. This version clarified several issues that were vague
in the original specification. All the protocol specifications for
the global HAHA are now added on top of the Home Agent Reliability
protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Initial Binding Registration . . . . . . . . . . . . . . . 8
3.2. Primary Home Agent Switch . . . . . . . . . . . . . . . . 9
3.3. Routing Packets . . . . . . . . . . . . . . . . . . . . . 9
4. Home Agent Configurations . . . . . . . . . . . . . . . . . . 11
4.1. Home Agent and Subnet Distributions . . . . . . . . . . . 11
4.2. Anycast Routing Consideration . . . . . . . . . . . . . . 12
5. Global HAHA Protocol . . . . . . . . . . . . . . . . . . . . . 14
5.1. Home Agents Bootstrap . . . . . . . . . . . . . . . . . . 14
5.2. Management of Global Home Agent set . . . . . . . . . . . 14
5.2.1. Home Agent List for the global HAHA . . . . . . . . . 15
5.2.2. Modified Home Agent Hello Message . . . . . . . . . . 15
5.2.3. Sending Home Agent Hello Messages . . . . . . . . . . 16
5.2.4. Receiving Hello Message . . . . . . . . . . . . . . . 17
5.3. Primary Home Agent Receiving Binding Update . . . . . . . 17
5.4. GLobal Binding Management . . . . . . . . . . . . . . . . 18
5.4.1. Global Binding . . . . . . . . . . . . . . . . . . . . 18
5.4.2. Modified State Synchronization Message and
Mobility Option . . . . . . . . . . . . . . . . . . . 19
5.4.3. Global Binding Registration . . . . . . . . . . . . . 21
5.5. Primary Home Agent Switch . . . . . . . . . . . . . . . . 23
5.6. Packet Interception and Delivery . . . . . . . . . . . . . 24
5.7. Home Agents Discovery . . . . . . . . . . . . . . . . . . 24
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 27
Wakikawa, et al. Expires January 7, 2010 [Page 2]
Internet-Draft Global HAHA Specification July 2009
A.1. Normative References . . . . . . . . . . . . . . . . . . . 27
A.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Wakikawa, et al. Expires January 7, 2010 [Page 3]
Internet-Draft Global HAHA Specification July 2009
1. Introduction
The Global HAHA protocol [ID-HAHA] has been discussed for a few years
in MIP6, NEMO and now MEXT working group. We have published several
documents [ID-HAHA] [ID-HAHAPROTO] [ID-HAHAINTEROP] and presented
several times in past IETF meetings, and received valuable feedback.
This document presents a revised version of the global HAHA protocol
specification. This version clarified several issues that were vague
in the original specification [ID-HAHA]. All the protocol
specifications for the global HAHA are now added on top of the Home
Agent Reliability protocol [ID-HARELIABILITY] which has been
standardized at the MEXT working group.
The global HAHA concept has been evaluated through prototype
implementations in several places and the results show that the
design is simple and effective in reducing triangle routing. Several
industry sectors such as aviation and automobile have shown their
interests in using global HAHA to meet the need for their mobility
managements. The main advantages of the global HAHA can be
summarized as follows:
o It can provide a more optimized route compared to the non-direct
path via a single home agent so called dog-leg routing;
o It eliminates the single point of failure and bottleneck in Mobile
IPv6 and NEMO protocols.
As every coin has two sides, the global HAHA protocol is not an
exception. It achieves the above goals through utilizing anycast
routing, which has raised concerns by various people, and it
introduces new overheads due to the need to synchronize the mobility
state among distributed home agents. By presenting a complete design
together with the design justifications, we hope that this document
will help move the discussion towards a converged understanding on
the pros and cons of the global HAHA protocol.
Wakikawa, et al. Expires January 7, 2010 [Page 4]
Internet-Draft Global HAHA Specification July 2009
2. Terminology
This document uses terms defined in [RFC-3753], [RFC-3775], [RFC-
3963] and [ID-HARELIABILITY]. A few new terms are also introduced in
this document:
Home Subnet Prefix
It is assigned to a home subnet, and the home agent address of a
mobile node is assigned out of this prefix block. In this global
HAHA specification, the home subnet prefix is assumed to be a
provider independent prefix.
Home Agent Address
An address created from the home subnet prefix and assigned to a
home agent.
Home Agent Locator Address
An IP address assigned to a home agent by the ISP who provides the
Internet connectivity for the home agent. This address is used to
exchange mobility messages between globally distributed home
agents.
Global Home Agent Set
The set of home agents serving the same home subnet prefix. The
home agents can be located in topologically or geographically
different locations. A global home agent set is identified with a
16-bit group ID.
HAHA link
Because all the home agents in the same global home agent set
share the same home subnet prefix, yet they may be lcoated in
different parts on Internet, in order for each of them to reach
all the others directly as required by IP subnet definition,
logical connectivity links are created between each pair of home
agents. These logical links, called HAHA links. can be realized
using IP tunnel technologies such as IP tunnel, IPsec tunnel,
L2TP, PPTP, and so on.
Primary Home Agent
Wakikawa, et al. Expires January 7, 2010 [Page 5]
Internet-Draft Global HAHA Specification July 2009
The home agent which a mobile node is currently registered with.
Among all the available home agent in the same set, this primary
home agent should be topologically closest to the mobile node.
Each mobile node has one primary home agent.
Global Binding
When a mobile node registers with a primary home agent, the home
agent notifies this binding, called the global binding, to all the
other home agents in the same global home agent set. The
receivers of this global binding informaiton learns the pair of a
mobile node and its current primary home agent, and creates a
route entry for the mobile node with the next hop pointing to the
primary home agent. This route entry has a lifetime which can be
different from the lifetime carried in the original binding
message. When the lifetime expires, the route is deleted.
Wakikawa, et al. Expires January 7, 2010 [Page 6]
Internet-Draft Global HAHA Specification July 2009
3. Overview
This protocol is defined as an extension to the Home Agent
Reliability protocol. The Home Agent Reliability protocol extends
Mobile IPv6 [RFC-3775] to provide reliability to home agents at the
local home link. Its concept is similar to the router's redundancy
protocols such as VRRP and HSRP. When one home agent fails, another
standby home agent can immediately take over the function of the
failed one, so that ongoing session of mobile nodes will not be
interrupted by any single home agent failures.
Similar to the Home Agent Reliability protocol, the global HAHA
protocol requires no modification to mobile nodes and mobile routers
(i.e. end mobile entity). Supporting Mobile IPv6 [RFC-3775] and Home
Agent Switch message [RFC-5142] is sufficient to run mobile nodes
with globally distributed home agents. However different from the
Home Agent Reliability protocol, the global HAHA places multiple home
agents at geographically and topologically different locations and
can provide uninterrupted services in the face of multiple Home Agent
failures. This robustness feature is achieved through the use of IP
anycast routing, where all the Home Agents in a deployed global HAHA
system share one anycast address, so that packets from mobile nodes
can be forwarded to remaining functional home agent in a way that is
completely transparent to the mobile nodes.
Figure 1 shows the protocol sequence of the Global HAHA. As an
assumption, each home agent in the same global home agent set MUST
establish HAHA links for interconnecting other home agents. The
detail of HAHA link establishment is described in Section 5.1.
Wakikawa, et al. Expires January 7, 2010 [Page 7]
Internet-Draft Global HAHA Specification July 2009
MN HA1 HA2 CN
| | | |
|----> (Primary) | | 1. Binding Registration
| |-------->| | 2. State Synchronization
|<========|<========|<--------| 3. From CN to MN
|========>|------------------>| 4. From MN to CN
| | | |
: : : : MN MOVEMENT
| | | |
|------------------+| | 5. Binding Registration
| |<=======+| |
|<--------| | | 6. Home Agent Switch
|--------------> (Primary) | 7. Binding Re-registration
| |<--------| | 8. Binding Notification
|<==================|<--------| 9. From CN to MN
|==================>|-------->| 10. From MN to CN
| | | |
==== for tunneling
---- for direct packets
Figure 1: Overview of Global HAHA
3.1. Initial Binding Registration
When the mobile node attempts the binding registration to a home
agent (operation 1 in Figure 1), the binding update is routed to the
topologically closest home agent of the mobile node via IP anycast
routing. The closest home agent which the mobile node registers its
binding with is called a primary home agent for the mobile node.
This specification assumes that the route of home subnet prefix is
advertised from each of different locations where an HAHA home agent
resides. Each HAHA home agent can be reached through both the HAHA
anycast address and the unicast IP address assigned by the local
service provider.
After registering binding cache for the mobile node, the primary home
agent (HA1) sends State Synchronization messages to all the other
home agent (i.e. HA2) in the same global home agent set (operation 2
in Figure 1). Then, HA2 creates a global binding for the mobile node
and creates the mobile node's route entry with the next hop set to
the primary home agent (HA1). The global binding needs to be updated
when a mobile node changes its primary home agent. It must also be
refreshed before its lifetime expiration.
When HA2 receives packets destined to the mobile node, it forwards
them to the primary home agent (HA1) over the HAHA link according to
Wakikawa, et al. Expires January 7, 2010 [Page 8]
Internet-Draft Global HAHA Specification July 2009
the global binding (operation 3 in Figure 1). When a mobile node
sends data to the correspondent node, the traffic is tunneled to the
primary home agent, which then routes directly to the destination
(operation 4 in Figure 1).
3.2. Primary Home Agent Switch
In this example, from the routing perspective, the closest home agent
of the mobile node is now changed from HA1 to HA2 after mobile node's
movement. Thus, the primary home agent of the mobile node needs to
be updated from HA1 to HA2. The Primary Home Agent switch operation
consists of two binding updates exchange. The first binding update
is used to detect the closer home agent by the current primary home
agent. The second binding update is to let the mobile node change
its primary home agent.
When a mobile node changes its point of attachment, it simply sends a
first Binding Update to the current primary home agent (i.e. HA1 in
Figure 1) in order to renew its binding as [RFC-3775]. However, HA2
also advertises the home subnet prefix which is the same prefix of
the binding update's destination address (HA1's home agent address),
the Binding Update is first routed to the HA2 by IP anycast routing
and then forwarded to its destination (HA1) over the HAHA link by HA2
(operation 5 in Figure 1).
Due to fact that the binding update is forwarded from one of other
home agents in the same global home agent set, the HA1 now detects
that the primary home agent is changed to the HA2. The HA1 first
processes the Binding Update and returns a Binding Acknowledgment to
the mobile node. In parallel, it triggers a Home Agent Switch
message [RFC-5142] to the mobile node. In the Home Agent switch
message, the address of the HA2 is stored in the Home Agent Address
field so that the mobile node can associate with the closest home
agent (operation 6 in Figure 1).
When the mobile node receives the Home Agent Switch message from the
HA1, it switches its home agent to the HA2 according to [RFC-5142] .
The mobile node sends another Binding Update to the HA2. After
receiving the Binding Update, the HA2 creates the binding cache and
sends a State Synchronization message to the other Home Agents (i.e.
HA1) in the global home agent set. The HA1 removes the binding cache
entry of the mobile node and creates the route for the mobile node
with the next hop set to the HA2 over the HAHA link.
3.3. Routing Packets
The packets originated by the mobile node are always routed through
the primary home agent as shown in operations 3, 4, 9, 10 in
Wakikawa, et al. Expires January 7, 2010 [Page 9]
Internet-Draft Global HAHA Specification July 2009
Figure 1. They are tunneled to the primary home agent to which the
mobile node is currently registering and, then, routed directly to
the CN.
On the other hand, the packets originated by the correspondent node
are routed to the closest home agent by IP anycast routing. If the
home agent is not the primary home agent of the mobile node
(destination), the home agent looks up the global binding and routes
them to the primary home agent of the mobile node over the HAHA link.
Then, the primary home agent routes the packets to the mobile node
over the Mobile IPv6's bi-directional tunnel.
In some scenario, the path between a mobile node and a correspondent
node becomes asymmetric. In the global HAHA, the primary home agent
does not have any specific information of the correspondent nodes and
does not forward the packets to the closest home agent of the
correspondent node.
Wakikawa, et al. Expires January 7, 2010 [Page 10]
Internet-Draft Global HAHA Specification July 2009
4. Home Agent Configurations
4.1. Home Agent and Subnet Distributions
Figure 2 shows the home agents located on the same home link as
introduced in [RFC-3775] and [ID-HARELIABILITY]. Multiple home
agents are placed on the same home subnet (2001:db8:0:1::/64) and
standby home agents are prepared for home agent reliability [ID-
HARELIABILITY]. The home agents are assigned with different IP
address as an individual home agent address. The standby home agent
for HAa, HAa', shares the same IP address with HAa.
+--------+
|Internet|
+--------+
|
--+---+---+--Home Link (2001:db8:0:1::/64)
| | |
HAa HAb (HAa')
HA Address
- HAa 2001:db8:0:1::1
- HAb 2001:db8:0:1::2
- HAa' 2001:db8:0:1::1 (Standby)
Figure 2: Home Agents Distribtuion
Figure 3 shows the combination of home agents and subnets
distribution in a global HAHA system. Home agents are connected to a
number of subnets located in various places on Internet, they are all
assigned the same Provider-Independent (PI) prefix as their home
subnet prefix. Each home subnet is connected to the global Internet
through an ISP who also assigns a prefix of out its own address block
to the home subnet. We call this ISP assigned prefix "locator
prefix". Each home agent has two IP addresses: one from its PI home
subnet prefix and another from its provider. Each ISP that hosts a
HAHA subnet also agrees to announce the HAHA's PI Home subnet prefix
to the global Internet, so that packets destinated to any of the home
agent's IP addresses are delivered to the topologically closest home
agent.
Wakikawa, et al. Expires January 7, 2010 [Page 11]
Internet-Draft Global HAHA Specification July 2009
Home Link1 (2001:db8:0:1::/64)
HA1a HA1b (HA1a')
| | |
----+----
| /|\ PA-1 Prefix
+--------+ |
| ISP1 |
+--------+ PA-2 Prefix
| --> +- HA2a
+--------+ +--------+ |
|Backbone|--| ISP2 |----+ Home Link2
+--------+ +--------+ | (2001:db8:0:1::/64)
| +- (HA2a')
+--------+
| ISP3 |
+--------+ | PA-3 Prefix
| \|/
+----+----+
| |
HA3a (HA3a')
Home Link3 (2001:db8:0:1::/64)
HA address (PI) HA Locator address (PA)
- HA1a 2001:db8:0:1::1a PA-1Prefix::1a
- HA1b 2001:db8:0:1::1b PA-1Prefix::1b
- HA1a' 2001:db8:0:1::1a PA-1Prefix::1a (Standby)
- HA2a 2001:db8:0:1::2a PA-2Prefix::2a
- HA2a' 2001:db8:0:1::2a PA-2Prefix::2a (Standby)
- HA3a 2001:db8:0:1::3a PA-3Prefix::3a
- HA3a' 2001:db8:0:1::3a PA-3Prefix::3a (Standby)
Figure 3: Home Subnets and Agents Distribtuion
4.2. Anycast Routing Consideration
IP anycast routing has been widely used in recent years. As
documented in RFC4786 [RFC-4786], anycast has become increasingly
popular for adding redundancy to DNS servers to complement the
redundancy that the DNS architecture itself already provides.
Several root DNS server operators have distributed their servers
widely around the Internet, and DNS queries are directed to the
nearest functioning servers. Another popular anycast usage is by web
service providers, where two or more web farms share the same IP
prefix, so that when all the sites are up, HTTP requests are
forwarded to the web servers closest to the browsers; when a site is
Wakikawa, et al. Expires January 7, 2010 [Page 12]
Internet-Draft Global HAHA Specification July 2009
down, requests are automatically routed to next nearest web farm.
Anycast routing provides a simple and effective means to provide
robust services.
A concept related to anycast is MOAS (Multi-Origin AS) prefixes, they
are prefixes advertised by more than one origin AS. A MOAS prefix
represents an anycast prefix, although the inverse is not necessarily
true, i.e. an anycast prefix may not be a MOAS prefix if the prefix
is announced to the routing system by one origin AS out of the AS's
multiple locations. Our measurement using BGP data collected by
RouteViews and RIPE observed about 2000 or so MOAS prefixes in
today's global routing system, which is a very small percentage of
the current routing table entries of about 300K entries.
One basic cost from providing anycast services is an additional entry
in the global routing table for each anycast prefix. When the number
of anycast applications is small, the impact on the global routing
system scalability is small. The use of anycast for important
infrastructure services, such as DNS root servers, is well justified.
Using anycast to bootstrap other important services may also be
justified, if the services are globally scoped are commonly used, and
the number of anycast prefixes needed is small. However anycast is
clearly not for everyone or for all applications usage. It is a
worthwhile investigation to consider where best to draw the line.
Wakikawa, et al. Expires January 7, 2010 [Page 13]
Internet-Draft Global HAHA Specification July 2009
5. Global HAHA Protocol
5.1. Home Agents Bootstrap
For the global HAHA protocol, each home agent SHOULD be configured
with the following information.
o An own home subnet prefix
o An own home agent address
o An own home agent locator address
o A home agent anycast address for Dynamic Home Agent Address
discovery mechanism
o A Group ID of own global home agent set
o Home Agent locator addresses of all the other home agents in the
same global home agent set.
A home agent first establishes a HAHA link with all the other home
agents. How to establish a HAHA link is out of scope in this
document. For instance, IP tunnel is established between two home
agent's locator addresses. This HAHA link is used to exchange Home
Agent HELLO message, State Synchronization message and data packets
destined to a mobile node. Although all the signal packets are
securely exchanged, it is recommended to secure every packets
exchanged over this HAHA link.
As soon as HAHA links are fully ready, the home agent now provides
its home agent service to a mobile node. Without HAHA links, a home
agent SHOULD NOT configure with its home subnet prefix and act as a
home agent of the home subnet prefix. The home agent now starts
sending its Home Agent HELLO message as described in Section 5.2 and
soliciting global bindings of all the other home agents as discussed
in Section 5.4.3.
5.2. Management of Global Home Agent set
A home agent exchanges its availability with other home agents of the
same global home agent set. These status exchange is done with a
Home Agent HELLO message defined in the Home Agent Reliability
protocol [ID-HARELIABILITY]. Unlike the Home Agent Reliability
protocol, geographically separated home agents are operated more
carefully and their availability should be always confirmed (ex. by
the Home Agent Reliability protocol). Therefore, it MAY use longer
interval value for the hello message exchange, because these messages
Wakikawa, et al. Expires January 7, 2010 [Page 14]
Internet-Draft Global HAHA Specification July 2009
are exchanged over the network (i.e. not on the same link).
5.2.1. Home Agent List for the global HAHA
[RFC-3775] specifies the data structure named the Home Agent List.
This list is used to manage home agent information at a same home
link. In this specification, the home agent list is extended to
manage geographically distributed home agents. The following
information MUST be stored for globally distributed home agents in
the home agent list.
o home agent address(es)
o home agent locator address(es)
o The remaining lifetime of this Home Agents List entry
o Group ID of global home agent set
The following two fields introduced in [RFC-3775] are not used in
this specification.
o The link-local IP address of a home agent
o The preference for this home agent
5.2.2. Modified Home Agent Hello Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Preference | Home Agent Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hello Interval | Group ID |A|R|G|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Home Agent Hello Message
Wakikawa, et al. Expires January 7, 2010 [Page 15]
Internet-Draft Global HAHA Specification July 2009
Home Agent Preference
In this specification, the equal preference value is used among
home agents in a global home agent set. A home agent is selected
by a mobile node according to routing topology (i.e. anycast
routing), but not by these preference values. This value SHOULD
be set to 0. The receiver SHOULD ignore this value.
Group Identifier
This value is used to identify a particular global home agent set.
G flag
Global HA flag. If this flag is set, the home agent sending this
HA-HELLO message is operated with this specification.
5.2.3. Sending Home Agent Hello Messages
Each home agent periodically sends HA-HELLO to the other home agents
in the same global home agent set. Each home agent MUST also
generate HA-HELLO in the following cases:
o when a home agent receives a HA-HELLO with the G and R-flag set
o When a new home agent boots up, it SHOULD solicit HA-Hello
messages by sending a HA-HELLO with the G and R-flag set in
parallel with sending its own HA-HELLO message.
When a home agent sends HA-HELLO, the following rule MUST be applied
in addition to the Section 7.3.2 of [ID-HARELIABILITY].
o It MUST set G flag in HA-HELLO.
o It MUST specify its global home agent set's ID to the Group ID
field in HA-HELLO.
o The source and destination IPv6 addresses of the IPv6 header of
the HA-HELLO MUST be the home agent locator address.
o It SHOULD protect HA-HELLO by IPsec ESP transport mode. Only if
HAHA-link is secured enough (ex. dedicated leased line), IPsec can
be eliminated.
Wakikawa, et al. Expires January 7, 2010 [Page 16]
Internet-Draft Global HAHA Specification July 2009
5.2.4. Receiving Hello Message
When a home agent receives HA-HELLO, it follows the verification
described in Section 7.3.3 of [ID-HARELIABILITY]. In addition to
this, it MUST process HA-HELLO which G flag is set as follows:
o If the HA-HELLO is not protected by IPsec ESP, it SHOULD be
discarded.
o If the source IPv6 address of HA-HELLO is not belong to one of the
home agents in the redundant home agent set, the HA-HELLO MUST be
ignored.
o If the Group ID field of the received HA-HELLO and the receiver's
Group ID is different, HA-HELLO MUST be discarded. HA-HELLO MUST
NOT be sent to home agents whose Group ID is different from the
sender.
o HA-HELLO satisfying all of above tests MUST be processed by
receiver. The receiver copies home agent information in HA-HELLO
to the corresponding home agent list entry. The home agent
address of the sender is retrieved from the Source Address field
of the IPv6 header of the HA-HELLO.
5.3. Primary Home Agent Receiving Binding Update
The binding update sent by a mobile node is routed to the one of home
agents in the global home agent set according to the anycast routing.
The receiver of the home agent processes the binding update according
to [RFC-3775] and stores a binding for the mobile node. After
successful binding registration, the home agent becomes a primary
home agent for the mobile node. The primary home agent has following
functional requirements:
o Delivering IP packets destined to the mobile node over the bi-
directional tunnel
o Updating the binding according to the mobile node's binding
refreshment
o Notifying the mobile node binding to the other home agents in the
same global home agent set.
o Sending a Home Agent Switch message if another home agent is more
preferable to be the primary home agent. Usually, this is
trigerred by the reception of a valid Binding Update via another
Home Agent of the Global Home Agent set
Wakikawa, et al. Expires January 7, 2010 [Page 17]
Internet-Draft Global HAHA Specification July 2009
o Providing state synchronization information to other home agent of
the Global home agent set when a binding is created, updated,
removed or upon request.
The binding registration and management are same as [RFC-3775]. The
global HAHA requires to register global bindings of the mobile node
by sending the state synchronization message to all the other home
agents as described in the next section.
5.4. GLobal Binding Management
5.4.1. Global Binding
A global binding has the following information. Any mobile node's
specific information can be potentially stored in the global binding.
The aim of this global binding is to forward the data packets of a
mobile node received at non primary home agent to the primary home
agent of the mobile node. It is not used to deliver a packet
directly to a mobile node from the non primary home agents.
Therefore, the mobile node's care-of address is not necessary in the
global binding, more than likely the primary home agent of the mobile
node is important in the global binding.
o The primary home agent locator address
o The mobile node's home address
o The mobile router's mobile network prefix(es)
o The binding sequence number of a binding update
o The flags of a binding update
o The lifetime of the global binding
o The mobile node's care-of address (optional)
The modified State Synchronization message [ID-HARELIABILITY] is used
to exchange the global binding among the home agents.
When a global binding is created, the home agent MAY use proxy
Neighbor Discovery to intercept the packets addressed to the mobile
node's home address. If there is only single home agent at a home
link, it simply skip the proxy neighbor discovery and intercepts the
packet according to IP routing.
When a global binding is created, the home agent MUST create a mobile
node's route entry which next hop is set to the primary home agent
Wakikawa, et al. Expires January 7, 2010 [Page 18]
Internet-Draft Global HAHA Specification July 2009
(i.e. the primary home agent locator address). If a mobile node is a
mobile router [RFC-3963], the following mobile node's routes are
created: one for the home address and one per mobile network prefix.
If the mobile router's home address is derived from its mobile
network prefix [RFC-3963] (i.e. the operation of aggregated home
network [RFC-4887]), only a single route for the mobile network
prefix is sufficient.
5.4.2. Modified State Synchronization Message and Mobility Option
Figure 5 shows the modified version of the state synchronization
message defined in [ID-HARELIABILITY]. A new G flag is introduced to
explicitly indicate the global binding registration.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. .
. Mobility Options .
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: State Synchronization Message
Global (G) flag
When State Synchronization message are exchanged between
geographically distributed home agents, the global flag MUST be
set.
Mobility Options
The same options introduced in [ID-HAREALIBILITY] can be used in
SS-REQ.
The following options can be used in SS-REP:
* Binding Cache Information Option (mandatory)
* AAA Information Option (optional)
Wakikawa, et al. Expires January 7, 2010 [Page 19]
Internet-Draft Global HAHA Specification July 2009
* Vendor Specific Mobility Option (optional)
The following options can be used in SS-ACK:
* SS Status Option (mandatory)
Figure 6 is a new mobility option of State Synchronization message.
In the global HAHA, SS-ACK is mandatory for receivers of SS-REP to
notify the global binding registration status
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Home Address |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: State Synchronization Status Option
Type
8-bit Type value. The value is TBD.
Length
8-bit length value.
Status
8 bit Status value of global binding registration.
* 0: Success
* 128: Reason unspecified
* 129: Malformed SS-REP
Wakikawa, et al. Expires January 7, 2010 [Page 20]
Internet-Draft Global HAHA Specification July 2009
* 130: Not in same global home agent set
* 131: No Mobility Option
Reserved
24 bit Reserved fields
Home Address
Corresponding home address of the status code.
5.4.3. Global Binding Registration
A State Synchronization Reply message MUST be sent by a primary home
agent to register a global binding at the following timing. If a
primary home agent notifies its State Synchronization Request message
for every binding registration from a mobile node, it causes certain
overhead to exchange messages. Unless the binding information except
for sequence number and lifetime is changed, the state
synchronization message isn't necessarily sent per mobile nodes'
binding refreshment.
o when a primary home agent registers a binding for a mobile node at
the first time. The primary home agent MUST register a global
binding to the global home agent set.
o when a global binding is expired. The primary home agent MUST
refresh the global binding.
When a primary home agent receives a binding update from a mobile
node and registers a binding for it, it sends a State Synchronization
Reply message. SS-REP is sent to all the other home agents in the
global home agent set with the following rules.
o The A and G flags MUST be set in SS-REP.
o At least, one Binding Cache Information Option MUST be stored in
the mobility option field. Multiple options can be stored in a
SS-REP.
o Other optional mobility options listed in Figure 5 MAY be stored
in the mobility option field.
o IPsec ESP transport mode SHOULD be applied. Only if HAHA-link is
secured enough (ex. dedicated leased line), IPsec can be
eliminated.
Wakikawa, et al. Expires January 7, 2010 [Page 21]
Internet-Draft Global HAHA Specification July 2009
o The source and destination address of the SS-REP MUST be home
agent locator address.
o The source and destination address MUST belong to the same global
home agent set.
When a home agent receives the SS-REP, the following rules must be
applied to the received SS-REP.
o If the SS-REP is not protected by IPsec, it SHOULD be discarded.
o If no options are carried in SS-REP, the receiver MUST ignore the
SS-REP and MUST send SS-ACK with the Status Synchronization Status
option which status value is set to [131: No Mobility Option].
o If the sender of SS-REP is not in the same global home agent set,
the receiver MUST reject the SS-REP and MUST send SS-ACK with the
Status Synchronization Status option which status value is set to
[130: Not in same global home agent set].
o If the G flag is not set in RR-REP, the receiver MUST ignore the
SS-REP and MUST send SS-ACK with the Status Synchronization Status
option which status value is set to [129: Malformed SS-REP].
o If no errors are found in SS-REP, the receiver MUST register or
update the global binding per Binding Cache Information Option.
If the supplemental mobility options are specified for a mobile
node, the information MUST be stored in the global binding.
o After the successful global binding registration, it MUST create a
mobile node's route entry which next hop is set to the primary
home agent (i.e. the sender of SS-REP). If a mobile node is a
mobile router [RFC-3963], the following mobile node's routes are
created: one for the home address and one per mobile network
prefix. If the mobile router's home address is derived from its
mobile network prefix [RFC-3963] (i.e. the operation of aggregated
home network [RFC-4887]), only a single route for the mobile
network prefix is sufficient.
o The receiver of SS-REP then sends SS-ACK with state
synchronization status mobility options for all the mobile nodes
registering its global binding.
When a home agent needs to solicit SS-REP, it can send SS-REQ to a
home agent. The rules to construct SS-REQ is described in Section
7.4.1 of [ID-HARELIABILITY]. In addition, the following rules MUST
be applied:
Wakikawa, et al. Expires January 7, 2010 [Page 22]
Internet-Draft Global HAHA Specification July 2009
o IPsec ESP transport mode SHOULD be applied. Only if HAHA-link is
secured enough (ex. dedicated leased line), IPsec can be
eliminated.
o The source and destination address of the SS-REQ MUST be home
agent locator address.
o The source and destination address MUST belong to the same global
home agent set.
5.5. Primary Home Agent Switch
Primary Home Agent switch operation consists of two binding update
exchange. The first binding update is basically used by a primary
home agent to detect the better home agent in the same global home
agent set and to trigger sending a home agent switch message to
mobile nodes. The second one is to complete primary home agent
switch by registering the binding to the new primary home agent.
When a mobile node moves, it sends a binding update to its primary
home agent currently registering the binding. If The binding update
is directly routed to the destination (i.e. home agent), there is no
need to start the primary home agent switch. On the other hand, if
the binding update is first routed to one of not primary home agents,
the receiver of the binding update SHOULD become the primary home
agent of the mobile node from the routing perspective. The receiver
does not operate any inspection of the binding update and simply
forwards it to the destination address of the binding update over the
HAHA link.
Once the primary home agent receives the binding update forwarded by
one of home agents in the same global home agent set, it processes
the binding update as described in Section 5.3. In addition, it
starts sending a home agent switch message [RFC-5142] for the primary
home agent switch operation. How to send the home agent switch
message is described in [RFC-5142] and Section 9 of [ID-
HARELIABILITY].
The mobile node receiving the home agent switch message simply
updates its home agent address and re-registers its binding to the
new primary home agent. The new primary home agent sends SS-REP to
all the other home agents to update its global binding. After
receiving SS-REP, the previous primary home agent SHOULD delete its
original binding and create a global binding for the mobile node.
Wakikawa, et al. Expires January 7, 2010 [Page 23]
Internet-Draft Global HAHA Specification July 2009
5.6. Packet Interception and Delivery
When a home agent receives a packet destined to a mobile node, it
first check the binding cache. If it finds an original binding, it
tunnels the packet to the mobile node over the bi-directional tunnel.
Otherwise, it checks the global binding of the mobile node. If it
finds the global binding, it then routes the packet to the primary
home agent recorded in the global binding over the HAHA link. The
packet is delivered to the primary home agent by IP encapsulation.
In the outer IP header, the home agent locator address should be
used. If neither a binding nor a global binding is found, the packet
MUST be simply discarded. The home agent SHOULD return an ICMP
Destination Unreachable, Code 3, message to the packet's Source
Address (unless this Source Address is a multicast address).
5.7. Home Agents Discovery
When a mobile node boots up and needs to discover a home agent, it
simply sends a dynamic home agent address discovery message to the
home agent's anycast address. In that case, the dynamic home agent
address discovery message is routed to the closest home agent. The
closest home agent SHOULD return its own address with the highest
priority in the dynamic home agent address reply message so that the
mobile node can use the closet home agent for its binding
registration.
Alternatively, it discovers a home agent from DNS server.
Wakikawa, et al. Expires January 7, 2010 [Page 24]
Internet-Draft Global HAHA Specification July 2009
6. IANA considerations
TBA
Wakikawa, et al. Expires January 7, 2010 [Page 25]
Internet-Draft Global HAHA Specification July 2009
7. Security Considerations
TBA: Section 10 of [ID-HARELIABILITY] gives useful information.
Wakikawa, et al. Expires January 7, 2010 [Page 26]
Internet-Draft Global HAHA Specification July 2009
8. Acknowledgements
We would like to thank to Pascal Thubert and Vijay Devarapalli for
the original discussion of the global HAHA. We also thank to Arnaud
Ebalard for his review and valuable comments.
Appendix A. References
A.1. Normative References
A.2. Informative References
[RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[RFC-2991] D. Thaler and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991, November 2000.
[RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support
Terminology", RFC 4885, July 2007.
[RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization
Problem Statement", RFC 4888, July 2007.
[RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization
Solution Space Analysis", RFC 4889, July 2007.
[RFC-5142] Haley, B., "Mobility Header Home Agent Switch Message",
RFC 5142, November 2007.
[RFC-4786] J. Abley, and K. Lindqvist, "Operation of Anycast
Services", RFC 4886, December 2006
[RFC-4887] Pascal Thubert, Ryuji Wakikawa, Vijay Devarapalli,
"Network Mobility Home Network Models", RFC 4887, April 2007.
[ID-HARELIABILITY] Wakikawa, R. (Editor), "Home Agent Reliability
Protocol", draft-ietf-mip6-hareliability-04.txt (work in progress),
July 2008.
Wakikawa, et al. Expires January 7, 2010 [Page 27]
Internet-Draft Global HAHA Specification July 2009
[ID-HAHA] Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA
to HA protocol", draft-thubert-mext-global-haha-00.txt (Work in
Progress), March 2008
[ID-HAHAPROTO] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter
Home Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), March 2006.
[ID-HAHAINTEROP] Wakikawa, K. Shima, and N. Shigechika, "The Global
HAHA Operation at the Interop Tokyo 2008",
draft-wakikawa-mext-haha-interop2008-00.txt (work in progress), July
2008.
[ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements
for Operational Use in Aeronautics and Space Exploration Mobile
Networks", draft-ietf-mext-aero-reqs-03.txt, January 2009.
[ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements
for NEMO Route Optimization",
draft-ietf-mext-nemo-ro-automotive-req-02.txt, January 2009.
[PAPER-CONEXT] Ryuji wakikawa, Guillaume Valadon, Jun Murai.,
"Migrating Home Agents towards Internet-Scale Mobility Deployments",
ACM 2nd CoNEXT Conference on Future Networking Technologies, Lisbon,
Portugal. 4-7 December 2006
Authors' Addresses
Ryuji Wakikawa
Toyota ITC / Keio University
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji@jp.toyota-itc.com
Wakikawa, et al. Expires January 7, 2010 [Page 28]
Internet-Draft Global HAHA Specification July 2009
Zhenkai Zhu
UCLA
420 Westwood Plaza
Los Angeles, CA 90095
US
Phone: +1 310 993 7128
Email: zhenkai@cs.ucla.edu
Lixia Zhang
UCLA
3713 Boelter Hall, UCLA
Los Angeles, CA 90095
US
Phone: +1 310 825 2695
Email: lixia@cs.ucla.edu
Wakikawa, et al. Expires January 7, 2010 [Page 29]