Internet DRAFT - draft-yuchi-mip6-mntomn-improve
draft-yuchi-mip6-mntomn-improve
MIP6 WG Yuzhi Ma
Jian Zhang
Internet Draft Huawei Technologies CO.,LTD
Expires: October 12, 2006 April 12, 2006
Improve communication between Mobile Nodes
draft-yuchi-mip6-mntomn-improve-01.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 October 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
Any node communicating with a mobile node in Mobile IPv6 is referred
to as a "correspondent node" of the mobile node, and may itself be
Ma & Zhang Expires August 12, 2006 [Page 1]
Internet-Draft Improve communication between MN April 2006
either a stationary node or a mobile node. Communication between
mobile nodes has additional complexity. This document specifies a
solution to improve communication procedure between mobile nodes.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. Overview of the solution....................................3
3.1. Mobile Correspondent Node..............................3
3.2. Binding Refresh Request Message........................4
4. Protocol Operations.........................................5
4.1. Home Agent Operations..................................5
4.2. Mobile Correspondent Node Operations...................5
4.3. Mobile Node Operations.................................5
5. IANA Considerations.........................................5
6. Security Considerations.....................................6
7. Acknowledgments.............................................6
8. Normative References........................................7
Author's Addresses.............................................7
Intellectual Property Statement................................7
Disclaimer of Validity.........................................8
Copyright Statement............................................8
Acknowledgment.................................................8
1. Introduction
The Mobile IPv6 base protocol does not specially specify the
communication procedure between two mobile nodes. According to the
procedure defined for mobile node and correspondent node, the
communication between two mobile nodes MN1 and MN2 can be described
as follows:
o Mode1: Both MN1 and MN2 are at home. They communicate with each
other using conventional Internet routing mechanisms.
o Mode2: One is at home and one is away from home. Their
communication procedure is same as the procedure between a mobile
node and a stationary correspondent node.
Ma & Zhang Expires October 12, 2006 [Page 2]
Internet-Draft Improve communication between MN April 2006
o Mode3: Both MN1 and NM2 are away from home, and finish home
registration respectively. If they don't register their care-of
address with each other, then they communicate with each other
using bidirectional tunneling mode. Packets from MN1 are routed to
its home agent, then routed to the home agent of MN2, and finally
tunneled to the care-of address of MN2. Packets from MN2 to MN1
use the reverse procedure.
o Mode4: MN1 is away from home first and finishes home registration,
it then initiates a correspondent registration for MN2 which acts
as correspondent node now. MN2 moves to foreign link subsequently
and finishes home registration, then it may initiate a
correspondent registration for MN1. Finally, MN1 and MN2 can
communicate using route optimization.
A mobile node has dual nature when it communicates with another
mobile node. Sometimes its role is mobile node, and sometimes its
role is correspondent node. For this reason, the signaling messages,
exchanged between mobile nodes, have additional complexity when using
the third and fourth modes, as described above.
This document specifies a solution to improve signaling messages of
the fourth mode. How to improve the third mode is beyond the scope of
this specification.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
This document uses terminology specific to Mobile IPv6 as defined
in section "Terminology" of RFC 3775.
3. Overview of the solution
3.1. Mobile Correspondent Node
In order to differentiate between the two communicating mobile nodes,
a new concept called ''mobile correspondent node'' is introduced. The
initiator of a correspondent registration acts as a mobile node, and
the receiver acts as a mobile correspondent node. The receiver SHOULD
NOT initiate a correspondent registration for the initiator, and both
sides SHOULD maintain this relationship in future communication.
Ma & Zhang Expires October 12, 2006 [Page 3]
Internet-Draft Improve communication between MN April 2006
The figure below shows the typical relationship among three node in
mobile IPv6 network.
Node1 Node2
+---------------+ +-------------------------+
| |-----------|Mobile Correspondent Node|
| Mobile Node | | |
| | | Mobile Node |
+---------------+ +-------------------------|
|
|
|
+-------------------------+
| |
| Correspondent Node |
| |
+-------------------------+
Node3
If Node1 initiate a correspondent registration for Node2, then it act
as a mobile node for Node2. If Node2 initiate a correspondent
registration for Node3, then it act mobile node for Node2, and it act
as mobile correspondent node for Node1 at the same time. Node2 should
maintain Binding Cash and Binding Update List respectively.
A mobile correspondent node SHOULD inform the mobile node of its new
address, when its address is changed for some reason. The method for
doing this is specified below.
3.2. Binding Refresh Request Message
A Binding Refresh Request (BRR) is used by a correspondent node to
request a mobile node to re-establish its binding with the
correspondent node. This message is typically used when the cached
binding is in active use but the binding's lifetime is close to
expiration. In this solution, this message is used to inform the
mobile node of a mobile correspondent node's address when its address
has changed or will change.
The following options are valid in a BRR message:
Ma & Zhang Expires October 12, 2006 [Page 4]
Internet-Draft Improve communication between MN April 2006
The Home Address option is used to carry home address of the mobile correspondent
node and the Alternate Care-of address option is used to carry its Care-of address.
The encoding and format of these two option are described in [2].
4. Protocol Operations
4.1. Home Agent Operations
The home agent's operations are according to [2].
4.2. Mobile Correspondent Node Operations
Due to movement, reconfiguration, or other reason, a correspondent
node's address may change. As a result, the correspondent node SHOULD
send a BRR message to the mobile node. If a correspondent node sends
BRR message after its address has changed, the Alternate Care-of
address option contains its previous address; otherwise this option
contains its prospective address. Obtaining a prospective address is
according to [3].
4.3. Mobile Node Operations
For delay-insensitive applications, when a mobile node receives a BRR
message containing a Alternate Care-of address option and the mobile
node has a Binding Update List entry for the address carried by the
option, then the mobile node should start the return routability
procedure which is sent to the source of the BRR message. If the
mobile node has a Binding Update List entry for the source of the BRR,
then the mobile node should start the return routability procedure
which is sent to the address carried by the Alternate Care-of address
option. Other operations of the mobile node are according to [2].
For delay-sensitive applications, the return-routability procedure
can lead to a handoff delay unacceptable. Optimizations for reduced
signaling overhead between mobile nodes should be considered more
detail in future.
5. IANA Considerations
This document has no actions for IANA.
Ma & Zhang Expires October 12, 2006 [Page 5]
Internet-Draft Improve communication between MN April 2006
6. Security Considerations
Section 15 of [2] outlines the Mobile IPv6 security considerations.
Detailed security considerations will be listed in future.
7. Acknowledgments
Ma & Zhang Expires October 12, 2006 [Page 6]
Internet-Draft Improve communication between MN April 2006
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C. and J. Arkko, ''Mobility Support in
IPv6'', RFC3775, June 2004.
[3] Koodli, R., ''Fast Handover for Mobile IPv6'', RFC4068, July 2005.
Author's Addresses
Yuzhi Ma
Huawei Bld.,No.3 Xinxi Rd.,
Shang Di Information Industry Base,
Hai-Dian District Beijing P.R.China
Email: myz@huawei.com
Jian Li
Huawei Bld.,No.3 Xinxi Rd.,
Shang Di Information Industry Base,
Hai-Dian District Beijing P.R.China
Email: hwzhj@huawei.com
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
Ma & Zhang Expires October 12, 2006 [Page 7]
Internet-Draft Improve communication between MN April 2006
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 (2006).
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.
Ma & Zhang Expires October 12, 2006 [Page 8]
