Internet DRAFT - draft-jin-mip4-ha-switch
draft-jin-mip4-ha-switch
Mobile IPv4 M. Jin
Internet-Draft M. Wang
Expires: January 12, 2006 China Unicom
H. Deng
Hitachi
B. Haley
Hewlett-Packard Company
July 11, 2005
Mobile IPv4 Home Agent Switch Message
draft-jin-mip4-ha-switch-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
RFC 3344 [2] contains no provision to allow a home agent to inform a
mobile node that it needs to stop acting as the home agent for the
mobile node. Dynamical Home Agent assignment [3] is designed for
assigning a optimal home agent for mobile node, not for proactively
Jin, et al. Expires January 12, 2006 [Page 1]
Internet-Draft HA Switch Message for MIPv4 July 2005
notifying a mobile node to change it's home agent. This document
specifies a new MIP4 control message that can be used between a home
agent and mobile node to signal a mobile node that it should acquire
a new home agent.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Home Agent Switch Message . . . . . . . . . . . . . . . . . . 3
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Home Agent Operation . . . . . . . . . . . . . . . . . . . 4
3.2 Foreign Agent Operation . . . . . . . . . . . . . . . . . 5
3.3 Mobile Node Operation . . . . . . . . . . . . . . . . . . 5
4. Operational Considerations . . . . . . . . . . . . . . . . . . 5
5. Procotol Constants . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1 Normative References . . . . . . . . . . . . . . . . . . . 6
8.2 Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Jin, et al. Expires January 12, 2006 [Page 2]
Internet-Draft HA Switch Message for MIPv4 July 2005
1. Introduction
IP Mobility support for IPv4 RFC 3344 [2] contains no provision to
allow a home agent to inform a mobile node that it needs to stop
acting as the home agent for the mobile node.
Dynamical Home Agent assignment [3] defined a messaging mechanism
where mobile node can request and receive a dynamic HA address in
Mobile IPv4 messages. But if a home agent goes offline or is
overloaded, the process to change to a new home agent based on this
mechanism could be slow since this event it transparent to the mobile
node.
This document specifies a new MIP4 control message that can be used
between a home agent and mobile node to signal a mobile node that it
should acquire a new home agent.
There are many cases where this message can be used, for example, a
home agent may wish to handoff some of its mobile nodes to another
home agent because it has become overloaded or it is going offline.
some of these has been mentioned already in [4].
2. Home Agent Switch Message
Mobile IP has already defined a set of new control messages, sent
with UDP using well-known port number 434. Registration Request and
Registration Reply type have been defined as 1 and 3.
Here we define a new type 5 for Home Agent Switch Message
IP fields:
Source Address Home agent's address.
Destination Address Mobile node's address.
UDP fields:
Source Port <variable>
Destination Port 434.
The UDP header is followed by the Mobile IP fields shown below:
Jin, et al. Expires January 12, 2006 [Page 3]
Internet-Draft HA Switch Message for MIPv4 July 2005
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 | # of addrs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent Addresses |
+ +
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Type
5 (Home Agent Switch)
# of Addresses
A 8-bits unsigned integer indicating the number of IPv6 home agent
addresses in the message. If set to zero, the mobile node MUST
perform dynamical home agent assignment.
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.
Home Agent Addresses
A list of alternate home agent addresses on the home link for the
mobile node. The number of addresses present in the list is
indicated by the "# of Addresses" field in the Home Agent Switch
message.
3. Operations
3.1 Home Agent Operation
A home agent SHOULD send a Home Agent Switch message when a known
period of unavailability is pending so the mobile node has sufficient
time to find another suitable home agent.
If the home agent does not receive a response from the mobile node (a
Registration Request message to delete its mobility binding), then it
SHOULD retransmit the message, until a response is received. The
initial value for the retransmission timer is
INITIAL_HA_SWITCH_TIMEOUT. The retransmissions by the home agent
Jin, et al. Expires January 12, 2006 [Page 4]
Internet-Draft HA Switch Message for MIPv4 July 2005
MUST use an exponential back-off mechanism, in which the timeout
period is doubled upon each retransmission, until either the home
agent gets a response from the mobile node to delete its binding, or
the timeout period reaches the value MAX_HA_SWITCH_TIMEOUT.
Attempts by the mobile node to extend the mobility binding lifetime
with a registration request message SHOULD be rejected, and a
registration reply SHOULD be returned with status value 129
(Administratively prohibited) as specified in [2].
3.2 Foreign Agent Operation
A foreign agent SHOULD only forward this message directly to mobile
node without any modification.
3.3 Mobile Node Operation
Upon receiving a Home Agent Switch message, The packet MUST be
covered by the home agent to mobile node IPsec ESP authentication SA
for integrity protection.
Upon receipt of a Home Agent Switch message, the mobile node MUST
stop using its current home agent for services and MUST delete its
home registraiton in home agent's mobility binding list by sending a
Registration Request message. This acts as an acknowledgement of the
Home Agent Switch message.
If the Home Agent Switch message contains a list of alternate home
agent addresses, the mobile node SHOULD select a home agent at
random. If no alternate home agent addresses are included in the
list, the mobile node MUST first perform dynamical home agent
assignment.
If a mobile node is unreachable, for example in idle state, when home
agent send home agent switch message to mobile node, mobile node can
not response back. In this case, the home agent SHOULD NOT make any
conclusions about its status. After this mobile node recover from
idle state, it found that previous registered home agent is not
available, it can find a new home agent based on the mechanism of
dynamical home agent assignment [2].
4. Operational Considerations
This document does not specify how an operator might use the Home
Agent Switch message in its network. However, it might be the case
that a home agent provides service for many thousands of mobile
nodes. Care should be taken to reduce the signaling overhead
required for handing off many mobile nodes to an alternate home
Jin, et al. Expires January 12, 2006 [Page 5]
Internet-Draft HA Switch Message for MIPv4 July 2005
agent.
5. Procotol Constants
INITIAL_HA_SWITCH_TIMEOUT 5 seconds
MAX_HA_SWITCH_TIMEOUT 20 seconds
6. IANA Considerations
Mobile IP messages are defined to be those that are sent to a message
recipient at port 434 (UDP or TCP). The currently standardized
message types have the following numbers, and are specified in the
indicated sections.
Type Name
---- -------------------------
5 Home Agent switch message
7. Security Considerations
The Home Agent Switch message MUST use mobile-home authentication
extension which is defined in section 3.5.2 of [2], Exactly one
authorization-enabling extension MUST be present in all the Home
Agent switch message.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
8.2 Informative References
[3] Kulkarni, M., "Mobile IPv4 Dynamic Home Agent Assignment",
draft-ietf-mip4-dynamic-assignment-04 (work in progress),
May 2005.
[4] Haley, B., "Mobility Header Home Agent Switch Message",
draft-haley-mip6-ha-switch-00 (work in progress), April 2005.
Jin, et al. Expires January 12, 2006 [Page 6]
Internet-Draft HA Switch Message for MIPv4 July 2005
Authors' Addresses
Mingye Jin
China Unicom
Beijing 100032
China
Email: jinmy@chinaunicom.com.cn
Minghui Wang
China Unicom
Beijing 100032
China
Email: wangmh@chinaunicom.com.cn
Hui Deng
Hitachi
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Brian Haley
Hewlett-Packard Company
110 Spitbrook Road
Nashua NH 03062
USA
Email: brian.haley@hp.com
Jin, et al. Expires January 12, 2006 [Page 7]
Internet-Draft HA Switch Message for MIPv4 July 2005
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 procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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 (2005). 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.
Jin, et al. Expires January 12, 2006 [Page 8]
