< draft-ietf-nemo-ro-problem-statement-02.txt   draft-ietf-nemo-ro-problem-statement-03.txt >
NEMO Working Group C. Ng NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Internet-Draft Panasonic Singapore Labs
Expires: July 1, 2006 P. Thubert Intended status: Informational P. Thubert
Cisco Systems Expires: March 19, 2007 Cisco Systems
M. Watari M. Watari
KDDI R&D Labs KDDI R&D Labs
F. Zhao F. Zhao
UC Davis UC Davis
December 28, 2005 September 15, 2006
Network Mobility Route Optimization Problem Statement Network Mobility Route Optimization Problem Statement
draft-ietf-nemo-ro-problem-statement-02 draft-ietf-nemo-ro-problem-statement-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 1, 2006. This Internet-Draft will expire on March 19, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
With current Network Mobility (NEMO) Basic Support, all With current Network Mobility (NEMO) Basic Support, all
communications to and from Mobile Network Nodes must go through the communications to and from Mobile Network Nodes must go through the
bi-directional tunnel established between the Mobile Router and Home bi-directional tunnel established between the Mobile Router and Home
Agent when the mobile network is away. This sub-optimal routing Agent when the mobile network is away. This sub-optimal routing
results in various inefficiencies associated with packet delivery, results in various inefficiencies associated with packet delivery,
such as increased delay and bottleneck links leading to traffic such as increased delay and bottleneck links leading to traffic
congestion, which can ultimately disrupt all communications to and congestion, which can ultimately disrupt all communications to and
skipping to change at page 8, line 28 skipping to change at page 8, line 28
sub-MR | MR2 | | MR4 | sub-MR | MR2 | | MR4 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
sub-MR | MR3 | | MR5 | sub-MR | MR3 | | MR5 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
----+---- ----+---- ----+---- ----+----
MNN CN2 MNN CN2
Figure 1: An example of nested Mobile Network Figure 1: An example of nested Mobile Network
Using NEMO Basic Support, the flow of packets between a Mobile Using NEMO Basic Support, the flow of packets between a Mobile
Network Node, MNN, and a Correspondent Node, CN1, would need to go Network Node, MNN, and a Correspondent Node, CN1, would need to go
through three separate tunnels, illustrated in Figure 2 below. through three separate tunnels, illustrated in Figure 2 below.
----------. ----------.
---------/ /----------. ---------/ /----------.
-------/ | | /------- -------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1 MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA MR2--------\ \----------MR2_HA
MR1---------MR1_HA MR1---------MR1_HA
Figure 2: Nesting of Bi-Directional Tunnels Figure 2: Nesting of Bi-Directional Tunnels
This leads to the following problems: This leads to the following problems:
o Pinball Route o Pinball Route
Both inbound and outbound packets will flow via the Home Agents of Both inbound and outbound packets will flow via the Home Agents of
all the Mobile Routers on their paths within the mobile network, all the Mobile Routers on their paths within the mobile network,
with increased latency, less resilience and more bandwidth usage. with increased latency, less resilience and more bandwidth usage.
Appendix B illustrates in detail the packets routes under Appendix B illustrates in detail the packets routes under
different nesting configurations of the Mobile Network Nodes. different nesting configurations of the Mobile Network Nodes.
skipping to change at page 14, line 17 skipping to change at page 14, line 17
7.1. Normative Reference 7.1. Normative Reference
[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005. January 2005.
[2] Manner, J. and M. Kojo, "Mobility Related Terminology", [2] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004. RFC 3753, June 2004.
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology", [3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-04 (work in progress), October 2005. draft-ietf-nemo-terminology-05 (work in progress), March 2006.
7.2. Informative Reference 7.2. Informative Reference
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
[5] Ernst, T., "Network Mobility Support Goals and Requirements", [5] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-05 (work in progress), draft-ietf-nemo-requirements-05 (work in progress),
October 2005. October 2005.
skipping to change at page 14, line 41 skipping to change at page 14, line 41
November 2001. November 2001.
[7] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, [7] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
"Threats for Basic Network Mobility Support (NEMO threats)", "Threats for Basic Network Mobility Support (NEMO threats)",
draft-petrescu-nemo-threats-01 (work in progress), draft-petrescu-nemo-threats-01 (work in progress),
January 2004. January 2004.
[8] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat [8] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
Analysis on NEMO Basic Operations", Analysis on NEMO Basic Operations",
draft-jung-nemo-threat-analysis-02 (work in progress), draft-jung-nemo-threat-analysis-02 (work in progress),
February 2004. July 2004.
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home [9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home
Network models", draft-ietf-nemo-home-network-models-05 (work Network models", draft-ietf-nemo-home-network-models-06 (work
in progress), October 2005. in progress), February 2006.
[10] Draves, R., "Default Address Selection for Internet Protocol [10] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
Appendix A. Change Log Appendix A. Change Log
o draft-ietf-nemo-ro-problem-statement-03:
* Keepalive release
o draft-ietf-nemo-ro-problem-statement-02: o draft-ietf-nemo-ro-problem-statement-02:
* Added Appendix C to illustrate the formation of stalemate * Added Appendix C to illustrate the formation of stalemate
situation in Section 2.7 situation in Section 2.7
* Editorial changes to the Abstract to better reflect the * Editorial changes to the Abstract to better reflect the
document contents document contents
* Minor editorial changes throughout Section 2 * Minor editorial changes throughout Section 2
skipping to change at page 16, line 51 skipping to change at page 16, line 51
sub-MR | MR2 | sub-MR | MR2 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | sub-MR | MR3 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN MNN
Figure 3: CN located at the infrastructure Figure 3: CN located at the infrastructure
B.1.1. Case A: LFN and standard IPv6 CN B.1.1. Case A: LFN and standard IPv6 CN
The simplest case is where both MNN and CN are fixed nodes with no The simplest case is where both MNN and CN are fixed nodes with no
mobility functions. That is, MNN is a Local Fixed Node, and CN is a mobility functions. That is, MNN is a Local Fixed Node, and CN is a
standard IPv6 node. Packets are encapsulated between each Mobile standard IPv6 node. Packets are encapsulated between each Mobile
Router and its respective Home Agent. As shown in Figure 4, in such Router and its respective Home Agent. As shown in Figure 4, in such
case, the path between the two nodes would go through: case, the path between the two nodes would go through:
1 2 3 4 3 2 1 1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node LFN IPv6 Node
The digits represent the number of IPv6 headers. The digits represent the number of IPv6 headers.
Figure 4: MNN and CN are standard IPv6 nodes Figure 4: MNN and CN are standard IPv6 nodes
B.1.2. Case B: VMN and MIPv6 CN B.1.2. Case B: VMN and MIPv6 CN
In this second case, both end nodes are Mobile IPv6 enabled mobile In this second case, both end nodes are Mobile IPv6 enabled mobile
nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 route
optimization may thus be initiated between the two and packets would optimization may thus be initiated between the two and packets would
not go through the Home Agent of the Visiting Mobile Node nor the not go through the Home Agent of the Visiting Mobile Node nor the
Home Agent of the Correspondent Node (not shown in the figure). Home Agent of the Correspondent Node (not shown in the figure).
However, packets will still be tunneled between each Mobile Router However, packets will still be tunneled between each Mobile Router
and its respective Home Agent, in both directions. As shown in and its respective Home Agent, in both directions. As shown in
Figure 5, the path between MNN and CN would go through: Figure 5, the path between MNN and CN would go through:
1 2 3 4 3 2 1 1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6 VMN MIPv6
Figure 5: MNN and CN are MIPv6 mobile nodes Figure 5: MNN and CN are MIPv6 mobile nodes
B.1.3. Case C: VMN and standard IPv6 CN B.1.3. Case C: VMN and standard IPv6 CN
When the communication involves a Mobile IPv6 node either as a When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 route
optimization cannot be performed because the standard IPv6 optimization cannot be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. Therefore, Correspondent Node cannot process Mobile IPv6 signaling. Therefore,
MNN would establish a bi-directional tunnel with its HA, which causes MNN 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 the flow to go out the nested NEMO. Packets between MNN and CN would
thus go through MNN's own Home Agent (VMN_HA). The path would thus go through MNN's own Home Agent (VMN_HA). The path would
therefore be as shown on Figure 6: therefore be as shown on Figure 6:
2 3 4 5 4 2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN | VMN |
| 3 | 3
1 2 | 1 2 |
CN --- VMN_HA --- MR3_HA CN --- VMN_HA --- MR3_HA
IPv6 Node IPv6 Node
Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 6: MNN is a MIPv6 mobile node and CN is a standard IPv6 node
Providing Route Optimization involving a Mobile IPv6 node may require Providing Route Optimization involving a Mobile IPv6 node may require
optimization among the Mobile Routers and the Mobile IPv6 node. optimization among the Mobile Routers and the Mobile IPv6 node.
B.2. CN located in distinct nested NEMOs B.2. CN located in distinct nested NEMOs
The Correspondent Node may be located in another nested mobile The Correspondent Node may be located in another nested mobile
network, different from the one MNN is attached to, as shown in network, different from the one MNN is attached to, as shown in
Figure 7. We define such configuration as "distinct nested mobile Figure 7. We define such configuration as "distinct nested mobile
networks". networks".
skipping to change at page 18, line 48 skipping to change at page 18, line 48
sub-MR | MR2 | | MR5 | sub-MR | MR2 | | MR5 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
+---+---+ ----+---- +---+---+ ----+----
sub-MR | MR3 | CN sub-MR | MR3 | CN
+---+---+ +---+---+
| |
----+---- ----+----
MNN MNN
Figure 7: MNN and CN located in distinct nested NEMOs Figure 7: MNN and CN located in distinct nested NEMOs
B.2.1. Case D: LFN and standard IPv6 CN B.2.1. Case D: LFN and standard IPv6 CN
Similar with Case A, we start off with the case where both end nodes Similar with Case A, we start off with the case where both end nodes
do not have any mobility functions. Packets are encapsulated at do not have any mobility functions. Packets are encapsulated at
every mobile router on the way out the nested mobile network, every mobile router on the way out the nested mobile network,
decapsulated by the Home Agents and then encapsulated again on its decapsulated by the Home Agents and then encapsulated again on its
way down the nested mobile network. way down the nested mobile network.
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN | LFN |
| 1 | 1
1 2 3 2 | 1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node IPv6 Node
Figure 8: MNN and CN are standard IPv6 nodes Figure 8: MNN and CN are standard IPv6 nodes
B.2.2. Case E: VMN and MIPv6 CN B.2.2. Case E: VMN and MIPv6 CN
Similar with Case B, when both end nodes are Mobile IPv6 nodes, the Similar with Case B, when both end nodes are Mobile IPv6 nodes, the
two nodes may initiate Mobile IPv6 route optimization. Again, two nodes may initiate Mobile IPv6 route optimization. Again,
packets will not go through the Home Agent of the MNN nor the Home packets will not go through the Home Agent of the MNN nor the Home
Agent of the Mobile IPv6 Correspondent Node (not shown in the Agent of the Mobile IPv6 Correspondent Node (not shown in the
figure). However, packets will still be tunneled for each Mobile figure). However, packets will still be tunneled for each Mobile
Router to its Home Agent and vise versa. Therefore, the path between Router to its Home Agent and vise versa. Therefore, the path between
MNN and CN would go through: MNN and CN would go through:
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN | VMN |
| 1 | 1
1 2 3 2 | 1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node MIPv6 Node
Figure 9: MNN and CN are MIPv6 mobile nodes Figure 9: MNN and CN are MIPv6 mobile nodes
B.2.3. Case F: VMN and standard IPv6 CN B.2.3. Case F: VMN and standard IPv6 CN
Similar to Case C, when the communication involves a Mobile IPv6 node Similar to Case C, when the communication involves a Mobile IPv6 node
either as a Visiting Mobile Node or as a Correspondent Node, MIPv6 either as a Visiting Mobile Node or as a Correspondent Node, MIPv6
route optimization can not be performed because the standard IPv6 route optimization can not be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. MNN would Correspondent Node cannot process Mobile IPv6 signaling. MNN would
therefore establish a bi-directional tunnel with its Home Agent. therefore establish a bi-directional tunnel with its Home Agent.
Packets between MNN and CN would thus go through MNN's own Home Agent Packets between MNN and CN would thus go through MNN's own Home Agent
as shown on figure Figure 10: as shown on figure Figure 10:
skipping to change at page 21, line 5 skipping to change at page 21, line 5
sub-MR | MR2 | | MR4 | sub-MR | MR2 | | MR4 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
+---+---+ +---+---+ +---+---+ +---+---+
sub-MR | MR3 | | MR5 | sub-MR | MR3 | | MR5 |
+---+---+ +---+---+ +---+---+ +---+---+
| | | |
----+---- ----+---- ----+---- ----+----
MNN CN MNN CN
Figure 11: CN and MNN located in the same nested NEMO Figure 11: CN and MNN located in the same nested NEMO
B.3.1. Case G: LFN and standard IPv6 CN B.3.1. Case G: LFN and standard IPv6 CN
Again, we start off with the case where both end nodes do not have Again, we start off with the case where both end nodes do not have
any mobility functions. Packets are encapsulated at every Mobile any mobility functions. Packets are encapsulated at every Mobile
Router on the way out the nested mobile network via the root Mobile Router on the way out the nested mobile network via the root Mobile
Router, decapsulated and encapsulated by the Home Agents and then Router, decapsulated and encapsulated by the Home Agents and then
make their way back to the nested mobile network through the same make their way back to the nested mobile network through the same
root Mobile Router. Therefore, the path between MNN and CN would go root Mobile Router. Therefore, the path between MNN and CN would go
through: through:
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN | LFN |
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node IPv6 Node
Figure 12: MNN and CN are standard IPv6 nodes Figure 12: MNN and CN are standard IPv6 nodes
B.3.2. Case H: VMN and MIPv6 CN B.3.2. Case H: VMN and MIPv6 CN
Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, Similar with Case B and E, when both end nodes are Mobile IPv6 nodes,
the two nodes may initiate Mobile IPv6 route optimization which will the two nodes may initiate Mobile IPv6 route optimization which will
avoid the packets to go through the Home Agent of MNN nor the Home avoid the packets to go through the Home Agent of MNN nor the Home
Agent of the Mobile IPv6 CN (not shown in the figure). However, Agent of the Mobile IPv6 CN (not shown in the figure). However,
packets will still be tunneled between each Mobile Router and its packets will still be tunneled between each Mobile Router and its
respective Home Agent in both directions. Therefore, the path would respective Home Agent in both directions. Therefore, the path would
be the same with Case G and go through: be the same with Case G and go through:
1 2 3 4 3 2 1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN | LFN |
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node MIPv6 Node
Figure 13: MNN and CN are MIPv6 mobile nodes Figure 13: MNN and CN are MIPv6 mobile nodes
B.3.3. Case I: VMN and standard IPv6 CN B.3.3. Case I: VMN and standard IPv6 CN
As for Case C and Case F, when the communication involves a Mobile As for Case C and Case F, when the communication involves a Mobile
IPv6 node either as a Visiting Mobile Node or as a Correspondent IPv6 node either as a Visiting Mobile Node or as a Correspondent
Node, Mobile IPv6 Route Optimization can not be performed. Node, Mobile IPv6 Route Optimization can not be performed.
Therefore, MNN will establish a bi-directional tunnel with its Home Therefore, MNN will establish a bi-directional tunnel with its Home
Agent. Packets between MNN and CN would thus go through MNN's own Agent. Packets between MNN and CN would thus go through MNN's own
Home Agent. The path would therefore be as shown on Figure 14: Home Agent. The path would therefore be as shown on Figure 14:
skipping to change at page 23, line 28 skipping to change at page 23, line 28
sub-MR | MR2 | sub-MR | MR2 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | sub-MR | MR3 |
+---+---+ +---+---+
| |
-+--+--+- -+--+--+-
MNN CN MNN CN
Figure 15: MNN and CN located behind the same nested MR Figure 15: MNN and CN located behind the same nested MR
B.4.1. Case J: LFN and standard IPv6 CN B.4.1. Case J: LFN and standard IPv6 CN
If both end nodes are Local Fixed Nodes, no special function is If both end nodes are Local Fixed Nodes, no special function is
necessary for optimization of their communications. The path between necessary for optimization of their communications. The path between
the two nodes would go through: the two nodes would go through:
1 1
MNN --- CN MNN --- CN
LFN IPv6 Node LFN IPv6 Node
Figure 16: MNN and CN are standard IPv6 nodes Figure 16: MNN and CN are standard IPv6 nodes
B.4.2. Case K: VMN and MIPv6 CN B.4.2. Case K: VMN and MIPv6 CN
Similar with Case H, when both end nodes are Mobile IPv6 nodes, the Similar with Case H, when both end nodes are Mobile IPv6 nodes, the
two nodes may initiate Mobile IPv6 route optimization. Although few two nodes may initiate Mobile IPv6 route optimization. Although few
packets would go out the nested mobile network for the Return packets would go out the nested mobile network for the Return
Routability initialization, however, unlike Case B and Case E, Routability initialization, however, unlike Case B and Case E,
packets will not get tunneled outside the nested mobile network. packets will not get tunneled outside the nested mobile network.
Therefore, packets between MNN and CN would eventually go through: Therefore, packets between MNN and CN would eventually go through:
1 1
MNN --- CN MNN --- CN
VMN MIPv6 Node VMN MIPv6 Node
Figure 17: MNN and CN are MIPv6 mobile nodes Figure 17: MNN and CN are MIPv6 mobile nodes
If the root Mobile Router is disconnected while the nodes exchange If the root Mobile Router is disconnected while the nodes exchange
keys for the Return Routability procedure, they may not communicate keys for the Return Routability procedure, they may not communicate
even though they are connected on the same link. even though they are connected on the same link.
B.4.3. Case L: VMN and standard IPv6 CN B.4.3. Case L: VMN and standard IPv6 CN
When the communication involves a Mobile IPv6 node either as a When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6 Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6
Route Optimization cannot be performed. Therefore, even though the Route Optimization cannot be performed. Therefore, even though the
skipping to change at page 25, line 36 skipping to change at page 25, line 36
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
-+--------+-- mobile net 1 / home link 2 -+--------+-- mobile net 1 / home link 2
| |
+--+--+ +--+--+ +--+--+ +--+--+
| MR2 | | LFN | | MR2 | | LFN |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
-+--------+- mobile net 2 -+--------+- mobile net 2
Figure 19: Initial Deployment Figure 19: Initial Deployment
In Figure 19 above, communications between CN and LFN follows a In Figure 19 above, communications between CN and LFN follows a
direct path as long as both MR1 and MR2 are positioned at home. No direct path as long as both MR1 and MR2 are positioned at home. No
encapsulation intervenes. encapsulation intervenes.
In the next step, consider that the MR2's mobile network leaves home In the next step, consider that the MR2's mobile network leaves home
and visits a foreign network, under Access Router (AR) like in and visits a foreign network, under Access Router (AR) like in
Figure 20 below. Figure 20 below.
/-----CN /-----CN
skipping to change at page 26, line 22 skipping to change at page 26, line 22
+--+--+ +--+--+ +-----+ +--+--+ +--+--+ +-----+
| | | AR | | | | AR |
-+--------+- mobile net 1 +--+--+ -+--------+- mobile net 1 +--+--+
home link 2 | home link 2 |
+--+--+ +-----+ +--+--+ +-----+
| MR2 | | LFN | | MR2 | | LFN |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
mobile net 2 -+--------+- mobile net 2 -+--------+-
Figure 20: Mobile Network 2 Leaves Home Figure 20: Mobile Network 2 Leaves Home
Once MR2 acquires a Care-of Address under AR, the tunnel setup Once MR2 acquires a Care-of Address under AR, the tunnel setup
procedure occurs between MR2 and HA2. MR2 sends Binding Update to procedure occurs between MR2 and HA2. MR2 sends Binding Update to
HA2 and HA2 replies Binding Acknowledgement to MR2. The bi- HA2 and HA2 replies Binding Acknowledgement to MR2. The bi-
directional tunnel has MR2 and HA2 as tunnel endpoints. After the directional tunnel has MR2 and HA2 as tunnel endpoints. After the
tunnel MR2HA2 has been set up, the path taken by a packet from CN tunnel MR2HA2 has been set up, the path taken by a packet from CN
towards LFN can be summarized as: towards LFN can be summarized as:
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN. CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
skipping to change at page 27, line 28 skipping to change at page 27, line 28
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
mobile net 2 -+--------+- mobile net 2 -+--------+-
| |
+--+--+ +-----+ +--+--+ +-----+
| MR1 | | HA2 | | MR1 | | HA2 |
+--+--+ +--+--+ +--+--+ +--+--+
| | | |
mobile net 1 -+--------+- mobile net 1 -+--------+-
Figure 21: Stalemate Situation Occurs Figure 21: Stalemate Situation Occurs
If both tunnels between MR1 and HA1, and between MR2 and HA2 were up If both tunnels between MR1 and HA1, and between MR2 and HA2 were up
simultaneously, they would have "crossed over" each other. If the simultaneously, they would have "crossed over" each other. If the
tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be
noticed that the path of the tunnel MR1-HA1 includes only one noticed that the path of the tunnel MR1-HA1 includes only one
endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels
are crossing over each other if the IP path between two endpoints of are crossing over each other if the IP path between two endpoints of
one tunnel includes one and only one endpoint of the other tunnel one tunnel includes one and only one endpoint of the other tunnel
(assuming that both tunnels are up). When both endpoints of one (assuming that both tunnels are up). When both endpoints of one
tunnel are included in the path of the other tunnel, then tunnels are tunnel are included in the path of the other tunnel, then tunnels are
skipping to change at page 29, line 5 skipping to change at page 29, line 5
Fan Zhao Fan Zhao
University of California Davis University of California Davis
One Shields Avenue One Shields Avenue
Davis, CA 95616 Davis, CA 95616
US US
Phone: +1 530 752 3128 Phone: +1 530 752 3128
Email: fanzhao@ucdavis.edu Email: fanzhao@ucdavis.edu
Intellectual Property Statement Full 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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 29, line 29 skipping to change at page 29, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 30 change blocks. 
45 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/