Network Working Group B. Koh
Internet-Draft C. Ng
Expires: November 30, 2004 Panasonic Singapore Labs
J. Hirano
Panasonic
June 2004
Dynamic Inter Home Agent Protocol
draft-koh-dihap-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 November 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft describes a proposed Dynamic Inter Home Agent solution to
provide redundancy and load balancing of Home Agents. The proposed
solution recommends additional communication between home agents that
may be located far apart in terms of network topology but still
belonging to or are trusted by the same administrative domains
(service providers). While the mobile node is roaming away from its
home network, intervening home agents in the path of the
bidirectional tunnel between the mobile node and its registered home
Koh, et al. Expires November 30, 2004 [Page 1]
Internet-Draft DIHAP June 2004
agent may detect its presence. The intervening home agents that are
affiliated to the current home agent of the mobile node then proceed
to update it of their availability to serve as home agent for the
mobile node.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Dynamic Inter Home Agents Protocol . . . . . . . . 4
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Home Agent Change Message . . . . . . . . . . . . . . . . 5
4.2 Affiliated Home Agent Update Message . . . . . . . . . . . 6
4.3 Home Interface List Update Message . . . . . . . . . . . . 7
5. Home Interface List . . . . . . . . . . . . . . . . . . . . . 9
6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 9
6.1 Home Agent Notification . . . . . . . . . . . . . . . . . 10
6.1.1 Separate Anycast . . . . . . . . . . . . . . . . . . . 10
6.1.2 Piggy-backed Anycast . . . . . . . . . . . . . . . . . 10
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 10
7.1 Original Home Agent . . . . . . . . . . . . . . . . . . . 10
7.1.1 Solo Operation . . . . . . . . . . . . . . . . . . . . 10
7.1.2 Centralised Operation . . . . . . . . . . . . . . . . 11
7.2 Affiliated Home Agent . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 15
Koh, et al. Expires November 30, 2004 [Page 2]
Internet-Draft DIHAP June 2004
1. Introduction
For Mobile IPv6 [6], mobile nodes either tunnel its traffic through a
bi-directional tunnel via its home agent or it may employ route
optimisation with the correspondent node it is in communication with.
For NEMO Basic Support [1], the default mode of operation is to
tunnel all traffic meant for the mobile network through the home
agent serving the mobile router. As such, home agents may greatly
affect the effectiveness and efficiency with respect to the terminals
that deploy these two protocols. With the widespread prolification
of mobile terminals and supporting services, this may gain increasing
importance as a influencing factor. Sometimes, the mobile host and
its network could be closer to the correspondent node than the Home
Agent or the home agent becomes increasing congested and overloaded.
By choosing a home closer to its current location, the network
traffic could be significantly reduced as well as improving the
overall performance of the mobile host or network. One solution for
solving this problem is described in [3], the Inter Home Agents
Protocol proposes that the mobile node be provided with multiple home
agents and any of the home agents can forward packets to and from the
the mobile node. However, the downside to the proposed solution is
the constant updating between all of the home agents. This is
irregardless of whether or not the other home agents are useful to
the mobile node. There is hence a fixed increase in signalling
overhead per number of home agents involved.
This draft describes a proposed Dynamic Inter Home Agent solution to
provide redundancy and load balancing of Home Agents. The proposed
solution recommends additional communication between home agents that
may be located far apart in terms of network topology but still
belonging to or are trusted by the same administrative domains
(service providers). While the mobile node is roaming away from its
home network, intervening home agents in the path of the
bidirectional tunnel between the mobile node and its registered home
agent may detect its presence. The intervening home agents that are
affiliated to the current home agent of the mobile node then proceed
to update it of their availability to serve as home agent for the
mobile node.
The proposed solution employs the use of an addition Home Interface
List as a repository of the received updates from other home agents
including local interfaces that are serving as home agents. The
location of the Home Interface List gives rise to the two operation
modes of the solution. When the list is located on the home agent
itself, this is referred to as the solo mode of operation. However,
it is possible to locate the list on a topologically different
location. This is referred to as the centralised mode of operation.
Koh, et al. Expires November 30, 2004 [Page 3]
Internet-Draft DIHAP June 2004
2. Terminology
There are separate documents regarding Mobility terminology [5] as
well as Nemo terminology [2], which defines the terms related to
Network Mobility used in the document. This document in addition
defines the following term.
Affiliated Home Agent
A home agent that is known and trusted by a singular or group
of home agents.
3. Overview of Dynamic Inter Home Agents Protocol
When a home agent is deployed, each home agent should be configured
with the prefixes of other affiliated home agents.
A Home Interface List comprising of information such as interface and
mobile node addresses should be available to the home agent. The
list may be located on the home agent or at a remote location (e.g.
some other home agent) that is preconfigured in the home agent. This
information is different from the Binding Cache of the home agent as
its entries comprises of all the available interfaces able to serve
as a home agent. Each entry should preferably have a metric to
indicate preference for use as a home agent interface. The
preference metric should be updated as the situation requires it.
Each entry may optionally have a corresponding mobile node address to
indicate that the interface should only be considered for the
indicated mobile node. For each such mobile node entry, there should
also be a corresponding selection metric.
The home agent should first register all of its interfaces available
to serve as home agent interfaces with the Home Interface List. When
a registered interface is no longer available, it should be
deregistered from the List. Unavailability may be due possibly to
the link going down or congestion.
When choosing an interface to serve as the home agent for the mobile
node, the home agent may choose from its available local interfaces
or it may alternatively consult the Home Interface List.
Koh, et al. Expires November 30, 2004 [Page 4]
Internet-Draft DIHAP June 2004
+-----------------------------------------------------+
| |
| Internet HA4 |
| |
| HA2 |
| | +-------+
| /---|==HA==| Home |
| /-----/ | |Network|
| /------/ | +-------+
| /-----HA3-----/ Packet Path |
| MN-----HA1----/ |
| |
+-----------------------------------------------------+
During normal operation, the home agent (HA1, HA3) may detect or be
informed of the presence of mobile nodes (MN) registered with an
affiliated home agent (HA) roaming in their vicinity. Upon such
occasion, the home agent (HA1, HA3) may choose to inform the
destination affiliated home agent (HA)of its availability to serve as
a home agent for the mobile node (MN). The Home Interface List of
the destination affiliated home agent (HA) is updated accordingly.
The home agent (HA) may choose to actively inform a registered mobile
node (MN) to switch to another home agent interface. In this case, a
Home Agent Change message may be sent to the mobile node (MN) with
the address of the new home agent interface address (HA1). The
mobile node (MN) should then proceed to register itself with the
given home agent interface (HA1).
The Home Interface List may be shared amongst several home agents.
In this scenario, the list may be hosted on one of the home agents or
at another remote location.
4. Message Formats
4.1 Home Agent Change Message
The Home Agent Change message is used by a home agent to request a
mobile node to perform a home registration with a specific home
agent.
The Home Agent Change message uses the MH Type value 8. When this
value is indicated in the MH Type field, the format of the Message
Data field in the Mobility Header is as follows:
Koh, et al. Expires November 30, 2004 [Page 5]
Internet-Draft DIHAP June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Alternate Home Agent Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
16-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Alternate Home Agent Address
The address of the new home agent with which the mobile node
should initiate a home registration.
4.2 Affiliated Home Agent Update Message
The Affiliated Home Agent Update message is used by an affiliated
home agent to inform a home agent of its availability and suitability
to act as a home agent for the detected mobile node in question.
The Affiliated Home Agent Update message uses the MH Type value 9.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Hop Limit Count| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Detected Mobile Node Care-of-Address +
| |
+ +
Koh, et al. Expires November 30, 2004 [Page 6]
Internet-Draft DIHAP June 2004
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Limit Count
8-bit field specify the initial Hop Count of the IPv6 header.
By subtracting Hop Limit Count from the Hop Count, it is
possible to estimate the distance (in hops) of the affiliated
home agent from the registered home agent. This value may then
be used as the metric value in the Home Interface List Update
message.
Lifetime
8-bit unsigned integer. The number of time units remaining
before the information contained within this update MUST be
considered expired. One time unit is 4 seconds.
Detected Mobile Node Care-of-Address
The current Care-of-Address of the mobile node that was
detected by the affiliated home agent.
4.3 Home Interface List Update Message
The Home Interface List Update message is used by a home agent to
update the Home Interface List when the home agent is operating in
centralised mode. This means that the Home Interface List is
actually hosted on an entity at a remote location and the home agent
itself.
The Home Interface List Update message uses the MH Type value 10.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
Koh, et al. Expires November 30, 2004 [Page 7]
Internet-Draft DIHAP June 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Agent Interface Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobile Node Home Address .
. .
| |
Metric
8-bit unsigned integer. The number reflections the
desirability of using the interface specified in the message as
a home agent. Metric values for entries of local interfaces
should not used to compare with the metric values for entries
created for affiliated home agents as their derivation may
differ.
Lifetime
8-bit unsigned integer. The number of time units remaining
before the information contained within this update MUST be
considered expired. One time unit is 4 seconds.
Home Agent Interface Address
The address of the interface that is available to serve as a
home agent. If the Mobile Node Home Address field exists, the
interface will only serve as home agent for that mobile node.
Mobile Node Home Address
Only found for messages corresponding to Affiliated Home Agent
Update messages. This field may be left out if not applicable.
The existence of this field may be deduced from the Header Len
field of the Mobility Header.
Koh, et al. Expires November 30, 2004 [Page 8]
Internet-Draft DIHAP June 2004
5. Home Interface List
The Home Interface List maintains a record of available interfaces
for which may serve as home agents for mobile nodes. A Home
Interface List may either be maintained by each home agent node or
else at a known location. The Home Interface List may be implemented
in any manner consistent with the external behavior described in this
document, for example by being combined with the node's Binding Cache
as maintained by Mobile IP. When responding to a home registration
request or performing load balancing for congested interfaces, the
home agent may choose to utilise local interfaces or else the Home
Interface List should be searched.
Each Home Interface List entry conceptually contains the following
fields:
o The address of the interface to serve as a home agent
o The address of the specific mobile node for which the interface is
willing to serve as a home agent. This value may be left blank.
Entries with a value in this field should be given higher priority
when a request is made for the mobile node in question.
o A metric value. This may be a preference value for using this
interface. When there is a valid value in the mobile node address
field however, this metric may be used to signify the proximity of
the interface to the mobile node in question.
o A lifetime value, indicating the remaining lifetime for this Home
Interface List entry. This may be mandatory for all entries in a
remotely located Home Interface List, else required only for
entries with a valid mobile node address field value.
The Home Interface List should be updated when interfaces come out or
are taken off due to congestion or otherwise.
6. Mobile Node Operation
The mobile node MUST be able to interpret the new Home Agent Change
message in order for the Dynamic Inter Home Agent Protocol to
function. Upon the receipt of the option, the mobile node should
perform the following actions:
o Check that there is a corresponding home registration entry for
the source address given in the packet containing the option. If a
corresponding entry is not found, the packet MUST be silently
discarded.
Koh, et al. Expires November 30, 2004 [Page 9]
Internet-Draft DIHAP June 2004
o If a corresponding home registration entry was found, the
Alternate Home Agent Address should be retrieved from the option
and the Home Registration process started with the new Home Agent.
o The mobile node MAY choose to expire the home registration with
its old home agent, it may otherwise allow it to expire normally.
6.1 Home Agent Notification
The mobile MAY choose to take no specific action to notify any nearby
home agents. However, this may be the least effective method of
implementing the solution. Better alternatives involving the use of
anycasting are given below.
6.1.1 Separate Anycast
For a mobile node that implements the Separate Anycast, whenever the
mobile node sends a Binding Update to its registered home agent, a
separate packet with the destination address set to the value of
Mobile IPv6 Home-Agents anycast address [4] is sent. The source
address of the packet should be set to the mobile node's current
Care-of-Address. The packet should contain the address of the mobile
node's current home agent.
6.1.2 Piggy-backed Anycast
For a mobile node that implements the Piggy-backed Anycast, the
mobile node should encapsulate the Binding Update to its registered
home agent. The new IPv6 header should have the source address set to
the mobile node's current Care-of-address and the destination address
as the Mobile IPv6 Home-Agents anycast address.
7. Home Agent Operation
7.1 Original Home Agent
The original home agent is the home agent with which the mobile node
currently has a home registration. When the Home Interface List is
located on the home agent itself, it is described as performing in
solo mode. Locating the Home Interface List on a remote interface or
on another home agent is called the centralised operation mode.
7.1.1 Solo Operation
The home agent operates as per Mobile IP [6] and NEMO [1], however,
it should also register the interfaces on which it is serving as a
home agent with the Home Interface List. Home registration requests
Koh, et al. Expires November 30, 2004 [Page 10]
Internet-Draft DIHAP June 2004
are handled normally. However, if and when it decides to do load
balancing either due to traffic congestion or impending link going
down, it MAY arbitrarily choose a local interface or else query the
Home Interface List. It MAY then send a message with the Home Agent
Change message to the affected mobile node(s) requesting that the
mobile node register itself with the new home agent.
When the home agent receives an Affiliated Home Agent Update message
addressed to itself, it should perform the following actions:
o Check that the source address of the packet contains the address
belonging to an affiliated home agent or group of home agents. The
packet should be silently discarded otherwise.
o Check that the Detected Mobile Node Care-of-Address field has a
corresponding Care-of-Address entry in the Binding Cache and that
it is a Home Registration.
o Update the Home Interface List with the address of the affiliated
home agent interface, the specified mobile node's home address,
the lifetime for which the entry is valid and the metric. The
metric described here is calculated by deducting the Hop Limit
Count field in the Affiliated Home Agent Update message from the
current Hop Limit value in the IPv6 header field. This should
yield the approximate distance (in hops) to the affiliated home
agent.
7.1.2 Centralised Operation
The home agent in centralised operation is essentially similar to
solo operation. The key difference being that all updates to the
Home Interface List should be forwarded to the entity hosting the
list. Additionally, the home agent should update its local interfaces
that are serving as home agents with the remote Home Interface List
together with a lifetime entry and should periodically do so before
the lifetime expires.
When the home agent receives an Affiliated Home Agent Update message
from a intermediate home agent, it should as per Solo operation check
that the source home agent of the the message is valid. The Detected
Mobile Node Care-of-Address field is then checked with the Binding
Cache for a match. Assuming a match is found, the Home Interface List
Update message is created and sent to be updated at the remote Home
Interface List.
The remote Home Interface List may be queried for a home agent
address by the home agent by sending a Query message with a payload
Koh, et al. Expires November 30, 2004 [Page 11]
Internet-Draft DIHAP June 2004
consisting of a magic number and the home address of the mobile node.
The Reply message from the Home Interface List should have a payload
consisting of the same magic number contained in the Query message as
well as the selected home agent interface address.
It is assumed that the home agents and the entity hosting the Home
Interface List are known to each other.
7.2 Affiliated Home Agent
Affiliated home agents MAY actively scan forwarded packets for the
existence of a mobility header and an affiliated home agent address
in the destination address field. They then send a Alternate Home
Agent Update to the destination address of the intercepted packet.
This assumes that the home agent is also a operating as a router.
The more efficient and effective method would be for the mobile node
to use anycasting. In any case, the affiliated home agent would take
the following actions:
o Detect presence of Binding Updates to a home agent.
o Check that destination home agent belongs to list of affiliated
home agents (e.g. by checking the network prefix). Perform
relevant packet processing. Forwarding the packet if it was
intercepted, Decapsulating and forwarding a piggy-backed anycast
or discarding a separate anycast notification packet.
o Check Home Interface List to look for available interface to serve
as the home agent for the mobile node.
o Create and send the Affiliated Home Agent Update message and send
it to the home agent specified in the destination address.
8. IANA Considerations
This document defines three new Mobility Header messages
o Home Agent Change Message
o Affiliated Home Agent Update Message
o Home Interface List Update Message
9. Security Considerations
A home agent MUST know whether the other home agent is an affiliated
Koh, et al. Expires November 30, 2004 [Page 12]
Internet-Draft DIHAP June 2004
home agent. Affiliated home agents SHOULD establish secure
associations with each other before sending Affiliated Home Agent
Updates. All signaling messages between the home agents SHOULD be
authenticated and encrypted (e.g. by using IPsec ESP)
Please refer to the Mobile IPv6 specification [6] and the NEMO Basic
Support protocol specification [1] for security considerations.
10 References
[1] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-00 (work in progress), May 2003.
[3] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents
Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in
progress), February 2004.
[4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", IETF RFC 2526, March 1999.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
Authors' Addresses
Benjamin Koh
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
EMail: benjamin@psl.com.sg
Koh, et al. Expires November 30, 2004 [Page 13]
Internet-Draft DIHAP June 2004
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
EMail: cwng@psl.com.sg
Jun Hirano
Matsushita Electric Industrial Co., Ltd. (Panasonic)
5-3 Hikarino-oka
Yokosuka, Kanagawa 239-0847
JP
Phone: +81 46 840 5123
EMail: hirano.jun@jp.panasonic.com
Koh, et al. Expires November 30, 2004 [Page 14]
Internet-Draft DIHAP June 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Koh, et al. Expires November 30, 2004 [Page 15]