NEMO Working Group M. Watari
Internet-Draft T. Ernst
Expires: April 14, 2005 WIDE at Keio University
October 14, 2004
Route Optimization with Nested Correspondent Nodes
draft-watari-nemo-nested-cn-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 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 April 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document aims at assisting the problem statement of route
optimization in nested mobile networks. We describe the paths
packets would take using existing Mobile IPv6 and NEMO Basic Support
mechanisms when one or both end nodes of a communication flow are
located in a nested NEMO. One of both of the end nodes may
themselves be either mobile nodes performing Mobile IPv6, or standard
IPv6 nodes performing no mobility function at all. The path can
Watari & Ernst Expires April 14, 2005 [Page 1]
Internet-Draft RO with Nested CN October 2004
become extremely suboptimal if no optimization is provided.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. CN located in the fixed infrastructure . . . . . . . . . . . . 4
2.1 Case A: LFN and standard IPv6 CN . . . . . . . . . . . . . 4
2.2 Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 5
2.3 Case C: VMN and standard IPv6 CN . . . . . . . . . . . . . 5
3. CN located in distinct nested NEMOs . . . . . . . . . . . . . 7
3.1 Case D: LFN and standard IPv6 CN . . . . . . . . . . . . . 7
3.2 Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 8
3.3 Case F: VMN and standard IPv6 CN . . . . . . . . . . . . . 8
4. CN and MNN located in the same nested NEMO . . . . . . . . . . 10
4.1 Case G: LFN and standard IPv6 CN . . . . . . . . . . . . . 10
4.2 Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 11
4.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 11
5. CN located behind the same nested MR . . . . . . . . . . . . . 13
5.1 Case H: LFN and standard IPv6 CN . . . . . . . . . . . . . 13
5.2 Case I: VMN and MIPv6 CN . . . . . . . . . . . . . . . . . 14
5.3 Case I: VMN and standard IPv6 CN . . . . . . . . . . . . . 14
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
Watari & Ernst Expires April 14, 2005 [Page 2]
Internet-Draft RO with Nested CN October 2004
1. Introduction
This document assumes the reader is familiar with the NEMO Basic
Support protocol defined in [1], and with Mobile IPv6 defined in [4].
The reader should also be familiar with the NEMO Terminology defined
in [2].
The NEMO Basic Support protocol uses a bi-directional tunnel
established between the mobile router and its home agents for all
communications. Such communication path brings many problems such as
delay, packet loss, less MTU and so on as described in [3]. The
values become even more crucial under a nested mobile network, and
brings the need for route optimization.
As the solutions to provide such route optimization are proposed, in
this document, we try to describe some different communication models
which involves a nested mobile network, and to clarify the issues for
each cases. We focus on the different cases involving nested
correspondent nodes, from the NEMO Basic Support perspective. A
nested correspondent node is a correspondent node which itself is
also a mobile network node.
In the following sections, we illustrate the path followed by packets
if we assume nodes only performing Mobile IPv6 and NEMO Basic Support
mechanisms. There are different cases to consider since a CN may
either be located in the fixed infrastructure, in a nested NEMO, or
in the same nested NEMO as the MNN. Also, we have to consider the
cases where CNs and MNNs are either standard IPv6 nodes or MIPv6
nodes. As defined in [2], standard IPv6 nodes are nodes with no
mobility functions whatsoever, i.e. they are not MIPv6-enabled nor
NEMO-enabled (this does not only mean they cannot move around keeping
open connections, but also that they can't process BUs sent by
MIPv6-enabled peers).
Watari & Ernst Expires April 14, 2005 [Page 3]
Internet-Draft RO with Nested CN October 2004
2. CN located in the fixed infrastructure
The most typical configuration is the case where a MNN communicates
with a Correspondent Node (CN) attached in the fixed infrastructure.
Figure 1 below shows an example of such topology. The 3 models
generally assumed for route optimization are CN as a MIPv6-enabled
node, CN attached behind a Correspondent Router, or a standard IPv6
node using a bi-directional tunnel between the root-MR and its HA.
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
Figure 1: CN located at the infrastructure
2.1 Case A: LFN and standard IPv6 CN
The simplest case is where both MNN and CN are fixed nodes with no
mobility functions. That is, MNN is a LFN, and CN is a standard IPv6
node. Packets are encapsulated between each MR and its respective
HA. As shown in Figure 2, in such case, the path between the two
nodes would go through:
Watari & Ernst Expires April 14, 2005 [Page 4]
Internet-Draft RO with Nested CN October 2004
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
The digits represent the number of IPv6 headers.
Figure 2: MNN and CN are standard IPv6 nodes
Route optimization would require collaboration among the MRs. To
avoid tunneling through any HA, Correspondent Routes (CRs) may be
placed near CNs to handle bindings. CRs are routers enhanced which
the ability to handle bindings for a mobile network, allowing a
direct tunnel to the MR providing a certain level of optimization.
2.2 Case B: VMN and MIPv6 CN
In this second case, both end nodes are MIPv6-enabled mobile nodes,
that is, MNN is a VMN. MIPv6 route optimization may thus be
initiated between the two and packets wouldn't go through the HA of
the VMN nor the HA of the CN (not shown in the figure). However,
packets will still be tunneled between each MR and its respective HA,
in both directions. As shown in Figure 3, the path between VMN and
CN would go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
Figure 3: MMN and CN are MIPv6 mobile nodes
2.3 Case C: VMN and standard IPv6 CN
When the communication involves a MIPv6 node either as a MNN or as a
CN, MIPv6 route optimization can not be performed because the
standard IPv6 CN cannot process MIPv6 signaling. Therefore, VMN
would establish a bi-directional tunnel with its HA, which causes the
flow to go out the nested NEMO. Packets between MNN and CN would
thus go through VMN's own HA (VMN_HA). The path would therefore be
as shown on Figure 4:
Watari & Ernst Expires April 14, 2005 [Page 5]
Internet-Draft RO with Nested CN October 2004
2 3 4 5 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
VMN |
| 1
|
CN
IPv6 Node
Figure 4: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
Providing route optimization involving a MIPv6 node may require
optimization among the MRs and the MIPv6 node.
Watari & Ernst Expires April 14, 2005 [Page 6]
Internet-Draft RO with Nested CN October 2004
3. CN located in distinct nested NEMOs
The CN may be located in another nested NEMO, different from the one
MNN is attached to, as shown on Figure 5. We define such
configuration as ``distinct nested NEMOs.''
The models generally assumed for route optimization are optimization
among all MRs in both NEMOs, and a bi-directional tunnel between the
two root-MRs.
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
Figure 5: MNN and CN located in distinct nested NEMOs
3.1 Case D: LFN and standard IPv6 CN
Similar with Case A, we start off with the case where both end nodes
do not have any mobility functions. Packets are encapsulated at
every mobile router on the way out the nested NEMO, decapsulated by
the HAs and then encapsulated again on its way down the nested NEMO.
Watari & Ernst Expires April 14, 2005 [Page 7]
Internet-Draft RO with Nested CN October 2004
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
LFN |
| 2
1 2 3 |
CN --- MR5 --- MR4 --- MR4_HA
IPv6 Node
Figure 6: MNN and CN are standard IPv6 nodes
3.2 Case E: VMN and MIPv6 CN
Similar with Case B, when both end nodes are MIPv6 nodes, the two
nodes may initiate MIPv6 route optimization. Again, packets will not
go through the HA of the VMN nor the HA of the MIPv6 CN (not shown in
the figure). However, packets will still be tunneled for each MR to
its HA and vise versa. Therefore, the path between MNN and CN would
go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
VMN |
| 2
1 2 3 |
CN --- MR5 --- MR4 --- MR4_HA
MIPv6
Figure 7: MNN and CN are MIPv6 mobile nodes
3.3 Case F: VMN and standard IPv6 CN
Similar to Case C, when the communication involves a MIPv6 node
either as a MNN or as a CN, MIPv6 route optimization can not be
performed because the standard IPv6 CN cannot process MIPv6
signaling. VMN would therefore establish a bi-directional tunnel
with its HA. Packets between MNN and CN would thus go through VMN's
own HA as shown on figure Figure 8:
Watari & Ernst Expires April 14, 2005 [Page 8]
Internet-Draft RO with Nested CN October 2004
2 3 4 5 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
Figure 8: MNN is a MIPv6 mobile node and CN a standard IPv6 node
Watari & Ernst Expires April 14, 2005 [Page 9]
Internet-Draft RO with Nested CN October 2004
4. CN and MNN located in the same nested NEMO
Figure 9 below shows the case where the two communicating nodes are
connected behind a different MR, but the MRs are connected in the
same nested NEMO, and thus behind the same root-MR. Route
optimization can avoid packets being tunneled outside the nested
NEMO.
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
Figure 9: CN and MNN located in the same nested NEMO
4.1 Case G: LFN and standard IPv6 CN
Again, we start off with the case where both end nodes do not have
any mobility functions. Packets are encapsulated at every mobile
router on the way out the nested NEMO via the root-MR, decapsulated
and encapsulated by the HAs and then make their way back to the
nested NEMO through the same root-MR. Therefore, the path between
MNN and CN would go through:
Watari & Ernst Expires April 14, 2005 [Page 10]
Internet-Draft RO with Nested CN October 2004
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
LFN |
| 2
1 2 3 4 3 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA
IPv6 Node
Figure 10: MNN and CN are standard IPv6 nodes
4.2 Case H: VMN and MIPv6 CN
Similar with Case B and E, when both end nodes are MIPv6 nodes, the
two nodes may initiate MIPv6 route optimization which will avoid the
packets to go through the HA of the VMN nor the HA of the MIPv6 CN
(not shown in the figure). However, packets will still be tunneled
between each MR and its respective HA in both directions. Therefore,
the path would be the same with Case G and go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- MR5_HA
VMN |
| 2
1 2 3 4 3 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA
MIPv6 Node
Figure 11: MNN and CN are MIPv6 mobile nodes
4.3 Case I: VMN and standard IPv6 CN
As for Case C and Case F, when the communication involves a MIPv6
node either as a MNN or as a CN, MIPv6 route optimization can not be
performed. Therefore, VMN will establish a bi-directional tunnel
with its HA. Packets between MNN and CN would thus go through VMN's
own HA. The path would therefore be as shown on Figure 12:
Watari & Ernst Expires April 14, 2005 [Page 11]
Internet-Draft RO with Nested CN October 2004
2 3 4 5 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
VMN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 12: MNN is a MIPv6 mobile node and CN a standard IPv6 node
Watari & Ernst Expires April 14, 2005 [Page 12]
Internet-Draft RO with Nested CN October 2004
5. CN located behind the same nested MR
Figure 13 below shows the case where the two communicating nodes are
connected behind the same nested MR. The optimization is required
when the communication involves MIPv6-enabled nodes.
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
Figure 13: MNN and CN located behind the same nested MR
5.1 Case H: LFN and standard IPv6 CN
If both end nodes are LFNs, no special function is necessary for
optimization of their communication. The path between the two nodes
would go through:
Watari & Ernst Expires April 14, 2005 [Page 13]
Internet-Draft RO with Nested CN October 2004
1
MNN --- CN
LFN IPv6 Node
Figure 14: MNN and CN are standard IPv6 nodes
5.2 Case I: VMN and MIPv6 CN
Similar with Case H, when both end nodes are MIPv6 nodes, the two
nodes may initiate MIPv6 route optimization. Although few packets
would go out the nested NEMO for the Return Routability
initialization, however, unlike Case B and Case E, packets will not
get tunneled outside the nested NEMO. Therefore, packets between MNN
and CN would eventually go through:
1
MNN --- CN
VMN MIPv6 Node
Figure 15: MNN and CN are MIPv6 mobile nodes
If the root-MR is disconnected while the nodes exchange keys for the
RR procedure, they may not communicate even though they are connected
on the same link.
5.3 Case I: VMN and standard IPv6 CN
When the communication involves a MIPv6 node either as a MNN or as a
CN, MIPv6 route optimization can not be performed. Therefore, even
though the two nodes are on the same link, VMN will establish a
bi-directional tunnel with it's HA, which causes the flow to go out
the nested NEMO. Path between MNN and CN would require another HA
(HA4) to go through for this MIPv6 node:
Watari & Ernst Expires April 14, 2005 [Page 14]
Internet-Draft RO with Nested CN October 2004
2 3 4 5 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- VMN_HA
VMN |
| 1
|
CN
IPv6 Node
Figure 16: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
Watari & Ernst Expires April 14, 2005 [Page 15]
Internet-Draft RO with Nested CN October 2004
6. Conclusion
This document described the paths packets would take using existing
Mobile IPv6 and NEMO Basic Support mechanisms when one or both end
nodes of a communication flow are located in a nested NEMO. One of
both of the end nodes may themselves be either mobile nodes
performing Mobile IPv6, or standard IPv6 nodes performing no mobility
function at all.
This draft aims at helping the definition of the problem statement
for route optimization when one or both end nodes are located in a
nested NEMO. As emphasized on our figures, the path can become
extremely un-optimal if no optimization is provided besides the sole
opetation of existing Mobile IPv6 by some end nodes and NEMO Basic
Support by the MR. The generic solution to come up should cover all
cases, providing certain level of optimization for each case.
7 References
[1] Devarapalli, V., Wakikawa, R., Pestrescu, A. and P. Thubert,
"Nemo Basic Support Protocol", Internet Draft:
draft-ietf-nemo-basic-support-03.txt, Work In Progress, June
2004.
[2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology",
Internet Draft: draft-ietf-nemo-terminology-01.txt, Work In
Progress, February 2004.
[3] Thubert, P., Molteni, M., Ng, C-W., Ohnishi, H. and E. Paik,
"Taxonomy of Route Optimization models in the Nemo Context",
Internet Draft: draft-thubert-nemo-ro-taxonomy-02.txt, Work In
Progress, February 2004.
[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC: 3775, June 2004.
[5] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6", RFC: 2461, December 1998.
Watari & Ernst Expires April 14, 2005 [Page 16]
Internet-Draft RO with Nested CN October 2004
Authors' Addresses
Watari Masafumi
WIDE at Keio University
Jun Murai Lab., Keio University.
Shonan Fujisawa Campus, 5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1394
Fax: +81-466-49-1395
EMail: watari@sfc.wide.ad.jp
Ernst Thierry
WIDE at Keio University
Jun Murai Lab., Keio University.
K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
Kawasaki, Kanagawa 212-0054
Japan
Phone: +81-44-580-1600
Fax: +81-44-580-1437
EMail: ernst@sfc.wide.ad.jp
URI: http://www.sfc.wide.ad.jp/~ernst/
Watari & Ernst Expires April 14, 2005 [Page 17]
Internet-Draft RO with Nested CN October 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 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 (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.
Watari & Ernst Expires April 14, 2005 [Page 18]