draft-ietf-nemo-ro-problem-statement-03.txt   rfc4888.txt 
NEMO Working Group C. Ng Network Working Group C. Ng
Internet-Draft Panasonic Singapore Labs Request for Comments: 4888 Panasonic Singapore Labs
Intended status: Informational P. Thubert Category: Informational P. Thubert
Expires: March 19, 2007 Cisco Systems Cisco Systems
M. Watari M. Watari
KDDI R&D Labs KDDI R&D Labs
F. Zhao F. Zhao
UC Davis UC Davis
September 15, 2006
Network Mobility Route Optimization Problem Statement Network Mobility Route Optimization Problem Statement
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
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 March 19, 2007. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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
from the Mobile Network Nodes. Additionally, with nesting of Mobile from the Mobile Network Nodes. Additionally, with nesting of Mobile
Networks, these inefficiencies get compounded, and stalemate Networks, these inefficiencies get compounded, and stalemate
conditions may occur in specific dispositions. This document conditions may occur in specific dispositions. This document
investigates such problems, and provides for the motivation behind investigates such problems and provides the motivation behind Route
Route Optimization (RO) for NEMO. Optimization (RO) for NEMO.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. NEMO Route Optimization Problem Statement . . . . . . . . . . 5 2. NEMO Route Optimization Problem Statement . . . . . . . . . . 3
2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 5 2.1. Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2. Bottleneck in Home Network . . . . . . . . . . . . . . . . 7 2.2. Bottleneck in the Home Network . . . . . . . . . . . . . . 6
2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 7 2.3. Amplified Sub-Optimality in Nested Mobile Networks . . . . 6
2.4. Sub-Optimality with Combined Mobile IPv6 Route 2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . 9 Optimization . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. Security Policy Prohibiting Traffic From Visiting Nodes . 10 2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile 2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 10 Network . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 11 2.7. Stalemate with a Home Agent Nested in a Mobile Network . . 10
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative Reference . . . . . . . . . . . . . . . . . . . 12
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 6.2. Informative Reference . . . . . . . . . . . . . . . . . . 12
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 Appendix A. Various Configurations Involving Nested Mobile
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 Networks . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Various configurations involving Nested Mobile A.1. CN Located in the Fixed Infrastructure . . . . . . . . . . 13
Networks . . . . . . . . . . . . . . . . . . . . . . 16 A.1.1. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . 14
B.1. CN located in the fixed infrastructure . . . . . . . . . . 16 A.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 14
B.1.1. Case A: LFN and standard IPv6 CN . . . . . . . . . . . 17 A.1.3. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . 14
B.1.2. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . 17 A.2. CN Located in Distinct Nested NEMOs . . . . . . . . . . . 15
B.1.3. Case C: VMN and standard IPv6 CN . . . . . . . . . . . 17 A.2.1. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . 16
B.2. CN located in distinct nested NEMOs . . . . . . . . . . . 18 A.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 16
B.2.1. Case D: LFN and standard IPv6 CN . . . . . . . . . . . 19 A.2.3. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . 16
B.2.2. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . 19 A.3. MNN and CN Located in the Same Nested NEMO . . . . . . . . 17
B.2.3. Case F: VMN and standard IPv6 CN . . . . . . . . . . . 19 A.3.1. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . 18
B.3. CN and MNN located in the same nested NEMO . . . . . . . . 20 A.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 18
B.3.1. Case G: LFN and standard IPv6 CN . . . . . . . . . . . 21 A.3.3. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . 19
B.3.2. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . 21 A.4. CN Located Behind the Same Nested MR . . . . . . . . . . . 19
B.3.3. Case I: VMN and standard IPv6 CN . . . . . . . . . . . 22 A.4.1. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . 20
B.4. CN located behind the same nested MR . . . . . . . . . . . 22 A.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 20
B.4.1. Case J: LFN and standard IPv6 CN . . . . . . . . . . . 23 A.4.3. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . 21
B.4.2. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . 23 Appendix B. Example of How a Stalemate Situation Can Occur . . . 22
B.4.3. Case L: VMN and standard IPv6 CN . . . . . . . . . . . 24
Appendix C. Example of How a Stalemate Situation can Occur . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
With current Network Mobility (NEMO) Basic Support [1], all With current Network Mobility (NEMO) Basic Support [1], all
communications to and from nodes in a mobile network must go through communications to and from nodes in a mobile network must go through
the bi-directional tunnel established between the Mobile Router and the bi-directional tunnel established between the Mobile Router and
its Home Agent (also known as the MRHA tunnel) when the mobile its Home Agent (also known as the MRHA tunnel) when the mobile
network is away. Although such an arrangement allows Mobile Network network is away. Although such an arrangement allows Mobile Network
Nodes to reach and be reached by any node on the Internet, Nodes to reach and be reached by any node on the Internet,
limitations associated to the base protocol degrade overall limitations associated to the base protocol degrade overall
performance of the network, and, ultimately, can prevent all performance of the network and, ultimately, can prevent all
communications to and from the Mobile Network Nodes. communications to and from the Mobile Network Nodes.
Some of these concerns already exist with Mobile IPv6 [4] and were Some of these concerns already exist with Mobile IPv6 [4] and were
addressed by the mechanism known as Route Optimization, which is part addressed by the mechanism known as Route Optimization, which is part
of the base protocol. With Mobile IPv6, Route Optimization mostly of the base protocol. With Mobile IPv6, Route Optimization mostly
improves the end to end path between Mobile Node and Correspondent improves the end-to-end path between the Mobile Node and
Node, with an additional benefit of reducing the load of the Home Correspondent Node, with an additional benefit of reducing the load
Network, thus its name. of the Home Network, thus its name.
NEMO Basic Support presents a number of additional issues, making the NEMO Basic Support presents a number of additional issues, making the
problem more complex, so it was decided to address Route Optimization problem more complex, so it was decided to address Route Optimization
separately. In that case, the expected benefits are more dramatic, separately. In that case, the expected benefits are more dramatic,
and a Route Optimization mechanism could enable connectivity that and a Route Optimization mechanism could enable connectivity that
would be broken otherwise. In that sense, Route Optimization is even would be broken otherwise. In that sense, Route Optimization is even
more important to NEMO Basic Support than it is to Mobile IPv6. more important to NEMO Basic Support than it is to Mobile IPv6.
This document explores limitations inherent in NEMO Basic Support, This document explores limitations inherent in NEMO Basic Support,
and their effects on communications between a Mobile Network Node and and their effects on communications between a Mobile Network Node and
its corresponding peer. This is detailed in Section 2. It is its corresponding peer. This is detailed in Section 2. It is
expected for readers to be familiar with general terminologies expected that readers are familiar with general terminologies related
related to mobility in [4][2], NEMO related terms defined in [3], and to mobility in [4][2], NEMO-related terms defined in [3], and NEMO
NEMO goals and requirements [5]. goals and requirements [5].
2. NEMO Route Optimization Problem Statement 2. NEMO Route Optimization Problem Statement
Given the NEMO Basic Support protocol, all data packets to and from Given the NEMO Basic Support protocol, all data packets to and from
Mobile Network Nodes must go through the Home Agent, even though a Mobile Network Nodes must go through the Home Agent, even though a
shorter path may exist between the Mobile Network Node and its shorter path may exist between the Mobile Network Node and its
Correspondent Node. In addition, with the nesting of Mobile Routers, Correspondent Node. In addition, with the nesting of Mobile Routers,
these data packets must go through multiple Home Agents and several these data packets must go through multiple Home Agents and several
levels of encapsulation, which may be avoided. This results in levels of encapsulation, which may be avoided. This results in
various inefficiencies and problems with packet delivery which can various inefficiencies and problems with packet delivery, which can
ultimately disrupt all communications to and from the Mobile Network ultimately disrupt all communications to and from the Mobile Network
Nodes. Nodes.
In the following sub-sections, we will describe the effects of a In the following sub-sections, we will describe the effects of a
pinball route with NEMO Basic Support, how it may cause a bottleneck pinball route with NEMO Basic Support, how it may cause a bottleneck
to be formed in the home network, and how these get amplified with to be formed in the Home Network, and how these get amplified with
nesting of mobile networks. Closely related to nesting, we will also nesting of mobile networks. Closely related to nesting, we will also
look into the sub-optimality even when Mobile IPv6 Route Optimization look into the sub-optimality even when Mobile IPv6 Route Optimization
is used over NEMO Basic Support. This is followed by a description is used over NEMO Basic Support. This is followed by a description
of security policy in home network that may forbid transit traffic of security policy in the Home Network that may forbid transit
from Visiting Mobile Nodes in mobile networks. In addition, we will traffic from Visiting Mobile Nodes in mobile networks. In addition,
explore the impact of MRHA tunnel on communications between two we will explore the impact of the MRHA tunnel on communications
Mobile Network Nodes on different links of the same mobile network. between two Mobile Network Nodes on different links of the same
We will also provide additional motivations for Route Optimization by mobile network. We will also provide additional motivations for
considering the potential stalemate situation when a Home Agent is Route Optimization by considering the potential stalemate situation
part of a mobile network. when a Home Agent is part of a mobile network.
2.1. Sub-Optimality with NEMO Basic Support 2.1. Sub-Optimality with NEMO Basic Support
With NEMO Basic Support, all packets sent between a Mobile Network With NEMO Basic Support, all packets sent between a Mobile Network
Node and its Correspondent Node are forwarded through the MRHA Node and its Correspondent Node are forwarded through the MRHA
tunnel, resulting in a pinball route between the two nodes. This has tunnel, resulting in a pinball route between the two nodes. This has
the following sub-optimal effects: the following sub-optimal effects:
o Longer route leading to increased delay and additional o Longer Route Leading to Increased Delay and Additional
infrastructure load Infrastructure Load
Because a packet must transit from a mobile network to the Home Because a packet must transit from a mobile network to the Home
Agent then to the Correspondent Node, the transit time of the Agent then to the Correspondent Node, the transit time of the
packet is usually longer than if the packet were to go straight packet is usually longer than if the packet were to go straight
from the mobile network to the Correspondent Node. When the from the mobile network to the Correspondent Node. When the
Correspondent Node (or the mobile network) resides near the Home Correspondent Node (or the mobile network) resides near the Home
Agent, the increase in packet delay can be very small. However Agent, the increase in packet delay can be very small. However,
when the mobile network and the Correspondent Node are relatively when the mobile network and the Correspondent Node are relatively
near to one another but far away from the Home Agent on the near to one another but far away from the Home Agent on the
Internet, the increase in delay is very large. Applications such Internet, the increase in delay is very large. Applications such
as real-time multimedia streaming may not be able to tolerate such as real-time multimedia streaming may not be able to tolerate such
increase in packet delay. In general, the increase in delay may increase in packet delay. In general, the increase in delay may
also impact the performance of transport protocols such as TCP, also impact the performance of transport protocols such as TCP,
since the sending rate of TCP is partly determined by the round- since the sending rate of TCP is partly determined by the round-
trip-time (RTT) perceived by the communication peers. trip time (RTT) perceived by the communication peers.
Moreover, by using a longer route, the total resource utilization Moreover, by using a longer route, the total resource utilization
for the traffic would be much higher than if the packets were to for the traffic would be much higher than if the packets were to
follow a direct path between the Mobile Network Node and follow a direct path between the Mobile Network Node and
Correspondent Node. This would result in additional load in the Correspondent Node. This would result in additional load in the
infrastructure. infrastructure.
o Increased packet overhead o Increased Packet Overhead
The encapsulation of packets in the MRHA tunnel results in The encapsulation of packets in the MRHA tunnel results in
increased packet size due to addition of an outer header. This increased packet size due to the addition of an outer header.
reduces the bandwidth efficiency, as IPv6 header can be quite This reduces the bandwidth efficiency, as an IPv6 header can be
substantial relative to the payload for applications such as voice quite substantial relative to the payload for applications such as
samples. For instance, given a voice application using a 8kbps voice samples. For instance, given a voice application using an 8
algorithm (e.g. G.729) and taking a voice sample every 20ms (as kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
in RFC 1889), the packet transmission rate will be 50 packets per (as in RFC 1889 [6]), the packet transmission rate will be 50
second. Each additional IPv6 header is an extra 320 bits per packets per second. Each additional IPv6 header is an extra 320
packet (i.e. 16kbps), which is twice the actual payload! bits per packet (i.e., 16 kbps), which is twice the actual
payload!
o Increased processing delay o Increased Processing Delay
The encapsulation of packets in the MRHA tunnel also results in The encapsulation of packets in the MRHA tunnel also results in
increased processing delay at the points of encapsulation and increased processing delay at the points of encapsulation and
decapsulation. Such increased processing may include encryption/ decapsulation. Such increased processing may include encryption/
decryption, topological correctness verifications, MTU decryption, topological correctness verifications, MTU
computation, fragmentation and reassembly. computation, fragmentation, and reassembly.
o Increased chances of packet fragmentation o Increased Chances of Packet Fragmentation
The augmentation in packet size due to packet encapsulation may The augmentation in packet size due to packet encapsulation may
increase the chances of the packet being fragmented along the MRHA increase the chances of the packet being fragmented along the MRHA
tunnel. This can occur if there is no prior path MTU discovery tunnel. This can occur if there is no prior path MTU discovery
conducted, or if the MTU discovery mechanism did not take into conducted, or if the MTU discovery mechanism did not take into
account the encapsulation of packets. Packets fragmentation will account the encapsulation of packets. Packet fragmentation will
result in a further increase in packet delays, and further result in a further increase in packet delays and further
reduction of bandwidth efficiency. reduction of bandwidth efficiency.
o Increased susceptibility to link failure o Increased Susceptibility to Link Failure
Under the assumption that each link has the same probability of Under the assumption that each link has the same probability of
link failure, a longer routing path would be more susceptibility link failure, a longer routing path would be more susceptible to
to link failure. Thus, packets routed through the MRHA tunnel may link failure. Thus, packets routed through the MRHA tunnel may be
be subjected to a higher probability of being lost or delayed due subjected to a higher probability of being lost or delayed due to
to link failure, compared to packets that traverse directly link failure, compared to packets that traverse directly between
between the Mobile Network Node and its Correspondent Node. the Mobile Network Node and its Correspondent Node.
2.2. Bottleneck in Home Network 2.2. Bottleneck in the Home Network
Apart from the increase in packet delay and infrastructure load, Apart from the increase in packet delay and infrastructure load,
forwarding packets through the Home Agent may also lead to either the forwarding packets through the Home Agent may also lead to either the
Home Agent or the Home Link becoming a bottleneck for the aggregated Home Agent or the Home Link becoming a bottleneck for the aggregated
traffic from/to all the Mobile Network Nodes. A congestion at home traffic from/to all the Mobile Network Nodes. A congestion at home
would lead to additional packet delay, or even packet loss. In would lead to additional packet delay, or even packet loss. In
addition, Home Agent operations such as security check, packet addition, Home Agent operations such as security check, packet
interception and tunneling might not be as optimized in the Home interception, and tunneling might not be as optimized in the Home
Agent software as plain packet forwarding. This could further limit Agent software as plain packet forwarding. This could further limit
the Home Agent capacity for data traffic. Furthermore, with all the Home Agent capacity for data traffic. Furthermore, with all
traffic having to pass through the Home Link, the Home Link becomes a traffic having to pass through the Home Link, the Home Link becomes a
single point of failure for the mobile network. single point of failure for the mobile network.
Data packets that are delayed or discarded due to congestion at the Data packets that are delayed or discarded due to congestion at the
home network would cause additional performance degradation to Home Network would cause additional performance degradation to
applications. Signaling packets, such as Binding Update messages, applications. Signaling packets, such as Binding Update messages,
that are delayed or discarded due to congestion at the home network, that are delayed or discarded due to congestion at the Home Network
may affect the establishment or update of bi-directional tunnels, may affect the establishment or update of bi-directional tunnels,
causing disruption of all traffic flow through these tunnels. causing disruption of all traffic flow through these tunnels.
A NEMO Route Optimization mechanism that allows the Mobile Network A NEMO Route Optimization mechanism that allows the Mobile Network
Nodes to communicate with their Correspondent Nodes via a path that Nodes to communicate with their Correspondent Nodes via a path that
is different from the MRHA tunneling and thereby avoiding the Home is different from the MRHA tunneling and thereby avoiding the Home
Agent, may alleviate or even prevent the congestion at the Home Agent Agent may alleviate or even prevent the congestion at the Home Agent
or Home Link. or Home Link.
2.3. Amplified Sub-Optimality in Nested Mobile Networks 2.3. Amplified Sub-Optimality in Nested Mobile Networks
By allowing other mobile nodes to join a mobile network, and in By allowing other mobile nodes to join a mobile network, and in
particular mobile routers, it is possible to form arbitrary levels of particular mobile routers, it is possible to form arbitrary levels of
nesting of mobile networks. With such nesting, the use of NEMO Basic nesting of mobile networks. With such nesting, the use of NEMO Basic
Support further amplifies the sub-optimality of routing. We call Support further amplifies the sub-optimality of routing. We call
this the amplification effect of nesting, where the undesirable this the amplification effect of nesting, where the undesirable
effects of a pinball route with NEMO Basic Support are amplified with effects of a pinball route with NEMO Basic Support are amplified with
skipping to change at page 8, line 28 skipping to change at page 7, 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 a 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 A illustrates in detail the packets' routes under
different nesting configurations of the Mobile Network Nodes. different nesting configurations of the Mobile Network Nodes.
o Increased Packet Size o Increased Packet Size
An extra IPv6 header is added per level of nesting to all the An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [6] cannot be packets. The header compression suggested in [7] cannot be
applied because both the source and destination (the intermediate applied because both the source and destination (the intermediate
Mobile Router and its Home Agent), are different hop to hop. Mobile Router and its Home Agent) are different hop to hop.
Nesting also amplifies the probability of congestion at the home Nesting also amplifies the probability of congestion at the Home
networks of the upstream Mobile Routers. In addition, the Home Link Networks of the upstream Mobile Routers. In addition, the Home Link
of each upstream Mobile Router will also be a single point of failure of each upstream Mobile Router will also be a single point of failure
for the nested Mobile Router. for the nested Mobile Router.
2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization 2.4. Sub-Optimality with Combined Mobile IPv6 Route Optimization
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting When a Mobile IPv6 host joins a mobile network, it becomes a Visiting
Mobile Node of the mobile network. Packets sent to and from the Mobile Node of the mobile network. Packets sent to and from the
Visiting Mobile Node will have to be routed not only via the Home Visiting Mobile Node will have to be routed not only via the Home
Agent of the Visiting Mobile Node, but also via the Home Agent of the Agent of the Visiting Mobile Node, but also via the Home Agent of the
Mobile Router in the mobile network. This suffers the same Mobile Router in the mobile network. This suffers the same
amplification effect of nested mobile network mentioned in amplification effect of nested mobile network mentioned in
Section 2.3. Section 2.3.
In addition, although Mobile IPv6 [4] allows a mobile host to perform In addition, although Mobile IPv6 [4] allows a mobile host to perform
Route Optimization with its Correspondent Node in order to avoid Route Optimization with its Correspondent Node in order to avoid
tunneling with its Home Agent, the "optimized" route is no longer tunneling with its Home Agent, the "optimized" route is no longer
optimized when the mobile host is attached to a mobile network. This optimized when the mobile host is attached to a mobile network. This
is because the route between the mobile host and its Correspondent is because the route between the mobile host and its Correspondent
Node is subjected to the sub-optimality introduced by the MRHA Node is subjected to the sub-optimality introduced by the MRHA
tunnel. Interested readers may refer to Appendix B for examples of tunnel. Interested readers may refer to Appendix A for examples of
how the routes will appear with nesting of Mobile IPv6 hosts in how the routes will appear with nesting of Mobile IPv6 hosts in
mobile networks. mobile networks.
The readers should also note that the same sub-optimality would apply The readers should also note that the same sub-optimality would apply
when the mobile host is outside the mobile network and its when the mobile host is outside the mobile network and its
Correspondent Node is in the mobile network. Correspondent Node is in the mobile network.
2.5. Security Policy Prohibiting Traffic From Visiting Nodes 2.5. Security Policy Prohibiting Traffic from Visiting Nodes
NEMO Basic Support requires all traffic from visitors to be tunneled NEMO Basic Support requires all traffic from visitors to be tunneled
to the Mobile Router's Home Agent. This might represent a breach in to the Mobile Router's Home Agent. This might represent a breach in
the security of the home network (some specific attacks against the the security of the Home Network (some specific attacks against the
Mobile Router's binding by rogue visitors have been documented in Mobile Router's binding by rogue visitors have been documented in
[7][8]). Administrators might thus fear that malicious packets will [8][9]). Administrators might thus fear that malicious packets will
be routed into the Home Network via the bi-directional tunnel. As a be routed into the Home Network via the bi-directional tunnel. As a
consequence, it can be expected that in many deployment scenarios, consequence, it can be expected that in many deployment scenarios,
policies will be put in place to prevent unauthorized Visiting Mobile policies will be put in place to prevent unauthorized Visiting Mobile
Nodes from attaching to the Mobile Router. Nodes from attaching to the Mobile Router.
However, there are deployment scenarios where allowing unauthorized However, there are deployment scenarios where allowing unauthorized
Visiting Mobile Nodes is actually desirable. For instance, when Visiting Mobile Nodes is actually desirable. For instance, when
Mobile Routers attach to other Mobile Routers and form a nested NEMO, Mobile Routers attach to other Mobile Routers and form a nested NEMO,
they depend on each other to reach the Internet. When Mobile Routers they depend on each other to reach the Internet. When Mobile Routers
have no prior knowledge of one another (no security association, AAA, have no prior knowledge of one another (no security association,
PKI etc...), it could still be acceptable to forward packets, Authentication, Authorization, and Accounting (AAA), Public-Key
provided that the packets are not tunneled back to the Home Networks. Infrastructure (PKI), etc.), it could still be acceptable to forward
packets, provided that the packets are not tunneled back to the Home
Networks.
A Route Optimization mechanism that allows traffic from Mobile A Route Optimization mechanism that allows traffic from Mobile
Network Nodes to by-pass the bi-directional tunnel between a Mobile Network Nodes to bypass the bi-directional tunnel between a Mobile
Router and its Home Agent would be a necessary first step towards a Router and its Home Agent would be a necessary first step towards a
Tit for Tat model, where MRs would benefit from a reciprocal Tit for Tat model, where MRs would benefit from a reciprocal
altruism, based on anonymity and innocuousness, to extend the altruism, based on anonymity and innocuousness, to extend the
Internet infrastructure dynamically. Internet infrastructure dynamically.
2.6. Instability of Communications within a Nested Mobile Network 2.6. Instability of Communications within a Nested Mobile Network
Within a nested mobile network, two Mobile Network Nodes may Within a nested mobile network, two Mobile Network Nodes may
communicate with each other. Let us consider the previous example communicate with each other. Let us consider the previous example
illustrated in Figure 1 where MNN and CN2 are sharing a communication illustrated in Figure 1 where MNN and CN2 are sharing a communication
session. With NEMO Basic Support, a packet sent from MNN to CN2 will session. With NEMO Basic Support, a packet sent from MNN to CN2 will
need to be forwarded to the Home Agent of each Mobile Router before need to be forwarded to the Home Agent of each Mobile Router before
reaching CN2. Whereas, a packet following the direct path between reaching CN2, whereas, a packet following the direct path between
them need not even leave the mobile network. Readers are referred to them need not even leave the mobile network. Readers are referred to
Appendix B.3 for detailed illustration of the resulting routing Appendix A.3 for detailed illustration of the resulting routing
paths. paths.
Apart from the consequences of increased packet delay and packet size Apart from the consequences of increased packet delay and packet
which are discussed in previous sub-sections, there are two size, which are discussed in previous sub-sections, there are two
additional effects that are undesirable: additional effects that are undesirable:
o when the nested mobile network is disconnected from the Internet o when the nested mobile network is disconnected from the Internet
(e.g. MR1 loses its egress connectivity), MNN and CN2 can no (e.g., MR1 loses its egress connectivity), MNN and CN2 can no
longer communicate with each other, even though the direct path longer communicate with each other, even though the direct path
from MNN to CN2 is unaffected; from MNN to CN2 is unaffected;
o the egress link(s) of the root Mobile Router (i.e. MR1) becomes a
o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a
bottleneck for all the traffic that is coming in and out of the bottleneck for all the traffic that is coming in and out of the
nested mobile network. nested mobile network.
A Route Optimization mechanism could allow traffic between two Mobile A Route Optimization mechanism could allow traffic between two Mobile
Network Nodes nested within the same mobile network to follow a Network Nodes nested within the same mobile network to follow a
direct path between them, without being routed out of the mobile direct path between them, without being routed out of the mobile
network. This may also off-load the processing burden of the network. This may also off-load the processing burden of the
upstream Mobile Routers when the direct path between the two Mobile upstream Mobile Routers when the direct path between the two Mobile
Network Nodes does not traverse these Mobile Routers. Network Nodes does not traverse these Mobile Routers.
2.7. Stalemate with a Home Agent Nested in a Mobile Network 2.7. Stalemate with a Home Agent Nested in a Mobile Network
Several configurations for the Home Network are described in [9]. In Several configurations for the Home Network are described in [10].
particular, there is a mobile home scenario where a (parent) Mobile In particular, there is a mobile home scenario where a (parent)
Router is also a Home Agent for its mobile network. In other words, Mobile Router is also a Home Agent for its mobile network. In other
the mobile network is itself an aggregation of Mobile Network words, the mobile network is itself an aggregation of Mobile Network
Prefixes assigned to (children) Mobile Routers. Prefixes assigned to (children) Mobile Routers.
A stalemate situation exists in the case where the parent Mobile A stalemate situation exists in the case where the parent Mobile
Router visits one of its children. The child Mobile Router cannot Router visits one of its children. The child Mobile Router cannot
find its Home Agent in the Internet and thus cannot establish its find its Home Agent in the Internet and thus cannot establish its
MRHA tunnel and forward the visitors traffic. The traffic from the MRHA tunnel and forward the visitor's traffic. The traffic from the
parent is thus blocked from reaching the Internet and it will never parent is thus blocked from reaching the Internet, and it will never
bind to its own (grand parent) Home Agent. Appendix C gives a bind to its own (grandparent) Home Agent. Appendix B gives a
detailed illustration of how such a situation can occur. detailed illustration of how such a situation can occur.
Then again, a Route Optimization mechanism that bypasses the nested Then again, a Route Optimization mechanism that bypasses the nested
tunnel might enable the parent traffic to reach the Internet and let tunnel might enable the parent traffic to reach the Internet and let
it bind. At that point, the child Mobile Router would be able to it bind. At that point, the child Mobile Router would be able to
reach its parent and bind in turn. Additional nested Route reach its parent and bind in turn. Additional nested Route
Optimization solutions might also enable the child to locate its Home Optimization solutions might also enable the child to locate its Home
Agent in the nested structure and bind regardless of whether the Agent in the nested structure and bind regardless of whether or not
Internet is reachable or not. the Internet is reachable.
3. Conclusion 3. Conclusion
With current NEMO Basic Support, all communications to and from With current NEMO Basic Support, all communications to and from
Mobile Network Nodes must go through the MRHA tunnel when the mobile Mobile Network Nodes must go through the MRHA tunnel when the mobile
network is away. This results in various inefficiencies associated network is away. This results in various inefficiencies associated
with packet delivery. This document investigates such with packet delivery. This document investigates such inefficiencies
inefficiencies, and provides for the motivation behind Route and provides the motivation behind Route Optimization for NEMO.
Optimization for NEMO.
We have described the sub-optimal effects of pinball routes with NEMO We have described the sub-optimal effects of pinball routes with NEMO
Basic Support, how they may cause a bottleneck to be formed in the Basic Support, how they may cause a bottleneck to be formed in the
home network, and how they get amplified with nesting of mobile Home Network, and how they get amplified with nesting of mobile
networks. These effects will also be seen even when Mobile IPv6 networks. These effects will also be seen even when Mobile IPv6
Route Optimization is used over NEMO Basic Support. In addition, Route Optimization is used over NEMO Basic Support. In addition,
other issues concerning the nesting of mobile networks that might other issues concerning the nesting of mobile networks that might
provide additional motivation for a NEMO Route Optimization mechanism provide additional motivation for a NEMO Route Optimization mechanism
were also explored, such as the prohibition of forwarding traffic were also explored, such as the prohibition of forwarding traffic
from a Visiting Mobile Node through a MRHA tunnel due to security from a Visiting Mobile Node through an MRHA tunnel due to security
concerns, the impact of MRHA tunnel on communications between two concerns, the impact of the MRHA tunnel on communications between two
Mobile Network Nodes on different links of the same mobile network, Mobile Network Nodes on different links of the same mobile network,
and the possibility of a stalemate situation when Home Agents are and the possibility of a stalemate situation when Home Agents are
nested within a mobile network. nested within a mobile network.
4. IANA Considerations 4. Security Considerations
This is an informational document and does not require any IANA
action.
5. Security Considerations
This document highlights some limitations of the NEMO Basic Support. This document highlights some limitations of NEMO Basic Support. In
In particular, some security concerns could prevent interesting particular, some security concerns could prevent interesting
applications of the protocol, as detailed in Section 2.5. applications of the protocol, as detailed in Section 2.5.
Route Optimization for RFC 3963 [1] might introduce new threats, just Route Optimization for RFC 3963 [1] might introduce new threats, just
as it might alleviate existing ones. This aspect will certainly be a as it might alleviate existing ones. This aspect will certainly be a
key criterion in the evaluation of the proposed solutions. key criterion in the evaluation of the proposed solutions.
6. Acknowledgments 5. Acknowledgments
The authors wish to thank the co-authors of previous drafts from The authors wish to thank the co-authors of previous versions from
which this draft is derived: Marco Molteni, Paik Eun-Kyoung, Hiroyuki which this document is derived: Marco Molteni, Paik Eun-Kyoung,
Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early work by Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early
Masafumi Watari on the extracted appendix was written while still at work by Masafumi Watari on the extracted appendix was written while
Keio University. In addition, sincere appreciation is also extended still at Keio University. In addition, sincere appreciation is also
to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton, Henrik extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton,
Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman, Ryuji Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman,
Wakikawa and Patrick Wetterwald for their various contributions. Ryuji Wakikawa, and Patrick Wetterwald for their various
contributions.
7. References 6. References
7.1. Normative Reference 6.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-05 (work in progress), March 2006. RFC 4885, July 2007.
7.2. Informative Reference 6.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), RFC 4886, July 2007.
October 2005.
[6] Deering, S. and B. Zill, "Redundant Address Deletion when [6] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
Encapsulating IPv6 in IPv6", "RTP: A Transport Protocol for Real-Time Applications",
draft-deering-ipv6-encap-addr-deletion-00 (work in progress), RFC 1889, January 1996.
November 2001.
[7] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach, [7] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
[8] 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), Work in Progress, January 2004.
January 2004.
[8] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat [9] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
Analysis on NEMO Basic Operations", Analysis on NEMO Basic Operations", Work in Progress,
draft-jung-nemo-threat-analysis-02 (work in progress),
July 2004. July 2004.
[9] Thubert, P., Wakikawa, R., and V. Devarapalli, "NEMO Home [10] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
Network models", draft-ietf-nemo-home-network-models-06 (work Mobility Home Network Models", RFC RFC4887, July 2007.
in progress), February 2006.
[10] Draves, R., "Default Address Selection for Internet Protocol [11] 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. Various Configurations Involving Nested Mobile Networks
o draft-ietf-nemo-ro-problem-statement-03:
* Keepalive release
o draft-ietf-nemo-ro-problem-statement-02:
* Added Appendix C to illustrate the formation of stalemate
situation in Section 2.7
* Editorial changes to the Abstract to better reflect the
document contents
* Minor editorial changes throughout Section 2
o draft-ietf-nemo-ro-problem-statement-01:
* Added text on effect on TCP contributed by Carlos in Sect 2.1 -
"Sub-Optimality with NEMO Basic Support"
* Added text on VMN using CoA as source address in Appendix B.4.3
* Re-written Section 2.5 - "Security Policy Prohibiting Traffic
From Visiting Nodes"
* Replaced "deadlock" with "stalemate" in Section 2.7.
* Minor typographical corrections
o draft-ietf-nemo-ro-problem-statement-00:
* Initial version adapted from Section 1 & 2 of
'draft-thubert-nemo-ro-taxonomy-04.txt'
* Added Section 2.2: Bottleneck in the Home Network
* Added Section 2.5: Security Policy Prohibiting Traffic From
Visiting Nodes
* Added Section 2.7: Deadlock with a Home Agent Nested in a
Mobile Network
* Appendix B extracted from 'draft-watari-nemo-nested-cn-01.txt'
Appendix B. Various configurations involving Nested Mobile Networks
In the following sections, we try to describe different communication In the following sections, we try to describe different communication
models which involve a nested mobile network, and to clarify the models that involve a nested mobile network and to clarify the issues
issues for each case. We illustrate the path followed by packets if for each case. We illustrate the path followed by packets if we
we assume nodes only use Mobile IPv6 and NEMO Basic Support assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms.
mechanisms. Different cases are considered where a Correspondent Different cases are considered where a Correspondent Node is located
Node is located in the fixed infrastructure, in a distinct nested in the fixed infrastructure, in a distinct nested mobile network as
mobile network as the Mobile Network Node, or in the same nested the Mobile Network Node, or in the same nested mobile network as the
mobile network as the Mobile Network Node. Additionally, cases where Mobile Network Node. Additionally, cases where Correspondent Nodes
Correspondent Nodes and Mobile Network Nodes are either standard IPv6 and Mobile Network Nodes are either standard IPv6 nodes or Mobile
nodes or Mobile IPv6 nodes are considered. As defined in [3], IPv6 nodes are considered. As defined in [3], standard IPv6 nodes
standard IPv6 nodes are nodes with no mobility functions whatsoever, are nodes with no mobility functions whatsoever, i.e., they are not
i.e. they are not Mobile IPv6 nor NEMO enabled. This mean that not Mobile IPv6 or NEMO enabled. This means that they cannot move around
only can they not move around keeping open connections, but also they keeping open connections and that they cannot process Binding Updates
cannot process Binding Updates sent by peers. sent by peers.
B.1. CN located in the fixed infrastructure A.1. CN Located in the Fixed Infrastructure
The most typical configuration is the case where a Mobile Network The most typical configuration is the case where a Mobile Network
Node communicates with a Correspondent Node attached in the fixed Node communicates with a Correspondent Node attached in the fixed
infrastructure. Figure 3 below shows an example of such topology. infrastructure. Figure 3 below shows an example of such topology.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA | | MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+ +---+----+ +---+----+ +---+----+
| | | | | |
+-------------------------+ +-------------------------+
skipping to change at page 16, line 51 skipping to change at page 13, 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 A.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 (HA). As shown in Figure 4, in
case, the path between the two nodes would go through: such a 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 A.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 or the Home
Home Agent of the Correspondent Node (not shown in the figure). Agent of the Correspondent Node (not shown in the figure). However,
However, packets will still be tunneled between each Mobile Router packets will still be tunneled between each Mobile Router and its
and its respective Home Agent, in both directions. As shown in respective Home Agent, in both directions. As shown in Figure 5, the
Figure 5, the path between MNN and CN would go through: 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 A.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 in 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 an 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 A.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".
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
\ | | / \ | | /
skipping to change at page 18, line 48 skipping to change at page 15, 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 A.2.1. Case D: LFN and Standard IPv6 CN
Similar with Case A, we start off with the case where both end nodes Similar to Case A, we start off with the case where both end nodes do
do not have any mobility functions. Packets are encapsulated at not have any mobility functions. Packets are encapsulated at every
every mobile router on the way out the nested mobile network, Mobile Router on the way out of 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 their
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 A.2.2. Case E: VMN and MIPv6 CN
Similar with Case B, when both end nodes are Mobile IPv6 nodes, the Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two
two nodes may initiate Mobile IPv6 route optimization. Again, nodes may initiate Mobile IPv6 Route Optimization. Again, packets
packets will not go through the Home Agent of the MNN nor the Home will not go through the Home Agent of the MNN or the Home Agent of
Agent of the Mobile IPv6 Correspondent Node (not shown in the the Mobile IPv6 Correspondent Node (not shown in the figure).
figure). However, packets will still be tunneled for each Mobile However, packets will still be tunneled for each Mobile Router to its
Router to its Home Agent and vise versa. Therefore, the path between Home Agent and vice versa. Therefore, the path between MNN and CN
MNN and CN would go through: 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 A.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 cannot 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 in Figure 10:
2 3 4 5 4 3 2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN | VMN |
| 2 | 2
1 2 3 2 1 | 1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node IPv6 Node
Figure 10: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
B.3. CN and MNN located in the same nested NEMO A.3. MNN and CN Located in the Same Nested NEMO
Figure 11 below shows the case where the two communicating nodes are Figure 11 below shows the case where the two communicating nodes are
connected behind different Mobile Routers that are connected in the connected behind different Mobile Routers that are connected in the
same nested mobile network, and thus behind the same root Mobile same nested mobile network, and thus behind the same root Mobile
Router. Route optimization can avoid packets being tunneled outside Router. Route Optimization can avoid packets being tunneled outside
the nested mobile network. the nested mobile network.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
\ | | / \ | | /
+--------+ +-------------------------+ +--------+ +--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA | | MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+ +--------+ +-------------------------+ +--------+
| |
skipping to change at page 21, line 4 skipping to change at page 18, line 4
+-------+ +-------+ +-------+ +-------+
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: MNN and CN Located in the Same Nested NEMO
B.3.1. Case G: LFN and standard IPv6 CN A.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 of the nested mobile network via the root
Router, decapsulated and encapsulated by the Home Agents and then Mobile Router, decapsulated and encapsulated by the Home Agents, and
make their way back to the nested mobile network through the same then make their way back to the nested mobile network through the
root Mobile Router. Therefore, the path between MNN and CN would go same root Mobile Router. Therefore, the path between MNN and CN
through: 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
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 A.3.2. Case H: VMN and MIPv6 CN
Similar with Case B and E, when both end nodes are Mobile IPv6 nodes, Similar to Case B and Case E, when both end nodes are Mobile IPv6
the two nodes may initiate Mobile IPv6 route optimization which will nodes, the two nodes may initiate Mobile IPv6 Route Optimization,
avoid the packets to go through the Home Agent of MNN nor the Home which will avoid the packets going through the Home Agent of MNN or
Agent of the Mobile IPv6 CN (not shown in the figure). However, the Home Agent of the Mobile IPv6 CN (not shown in the figure).
packets will still be tunneled between each Mobile Router and its However, packets will still be tunneled between each Mobile Router
respective Home Agent in both directions. Therefore, the path would and its respective Home Agent in both directions. Therefore, the
be the same with Case G and go through: path would be the same as 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 A.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 cannot be performed. Therefore,
Therefore, MNN will establish a bi-directional tunnel with its Home MNN will establish a bi-directional tunnel with its Home Agent.
Agent. Packets between MNN and CN would thus go through MNN's own Packets between MNN and CN would thus go through MNN's own Home
Home Agent. The path would therefore be as shown on Figure 14: Agent. The path would therefore be as shown in Figure 14:
2 3 4 5 4 3 2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN | VMN |
| 2 | 2
| |
VMN_HA VMN_HA
| |
| 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 14: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
B.4. CN located behind the same nested MR A.4. CN Located Behind the Same Nested MR
Figure 15 below shows the case where the two communicating nodes are Figure 15 below shows the case where the two communicating nodes are
connected behind the same nested Mobile Router. The optimization is connected behind the same nested Mobile Router. The optimization is
required when the communication involves MIPv6-enabled nodes. required when the communication involves MIPv6-enabled nodes.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA | | MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+ +------+-+ +---+----+ +---+----+ +-+------+
\ | | / \ | | /
+--------+ +-------------------------+ +--------+ +--------+ +-------------------------+ +--------+
skipping to change at page 23, line 28 skipping to change at page 20, 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 A.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 A.4.2. Case K: VMN and MIPv6 CN
Similar with Case H, when both end nodes are Mobile IPv6 nodes, the Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two
two nodes may initiate Mobile IPv6 route optimization. Although few 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 A.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
two nodes are on the same link, MNN will establish a bi-directional two nodes are on the same link, MNN will establish a bi-directional
tunnel with it's Home Agent, which causes the flow to go out the tunnel with its Home Agent, which causes the flow to go out the
nested mobile network. Path between MNN and CN would require another nested mobile network. The path between MNN and CN would require
Home Agent (VMN_HA) to go through for this Mobile IPv6 node: another Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
2 3 4 5 4 3 2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN | VMN |
| 2 | 2
| |
VMN_HA VMN_HA
| |
| 1 | 1
1 2 3 4 3 2 | 1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node IPv6 Node
Figure 18: MNN is a MIPv6 mobile node and CN is a standard IPv6 node Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
However, MNN may also decide to use its care-of address as the source However, MNN may also decide to use its Care-of Address (CoA) as the
address of the packets, thus avoiding the tunneling with the MNN's source address of the packets, thus avoiding the tunneling with the
Home Agent. This is particularly useful for a short-term MNN's Home Agent. This is particularly useful for a short-term
communications that may easily be retried if it fails. Default communications that may easily be retried if it fails. Default
Address Selection [10] provides some mechanisms for controlling the Address Selection [11] provides some mechanisms for controlling the
choice of the source address. choice of the source address.
Appendix C. Example of How a Stalemate Situation can Occur Appendix B. Example of How a Stalemate Situation Can Occur
Section 2.7 describes the occurence of a stalemate situation where a Section 2.7 describes the occurrence of a stalemate situation where a
Home Agent of a Mobile Router is nested behind the Mobile Router. Home Agent of a Mobile Router is nested behind the Mobile Router.
Here, we illustrate a simple example where such a situation can Here, we illustrate a simple example where such a situation can
occur. occur.
Consider a mobility configuration depicted in Figure 19 below. MR1 Consider a mobility configuration depicted in Figure 19 below. MR1
is served by HA1/BR and MR2 is served by HA2. The 'BR' designation is served by HA1/BR and MR2 is served by HA2. The 'BR' designation
indicates that HA1 is a border router. Both MR1 and MR2 are at home indicates that HA1 is a border router. Both MR1 and MR2 are at home
in the initial step. HA2 is placed inside the first mobile network, in the initial step. HA2 is placed inside the first mobile network,
thus representing a "mobile" Home Agent. thus representing a "mobile" Home Agent.
skipping to change at page 25, line 38 skipping to change at page 22, line 38
-+--------+-- 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 follow a direct
direct path as long as both MR1 and MR2 are positioned at home. No 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
+----------+ +----------+
home link 1 +--------+ | | home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet | --+-----------| HA1/BR |---| Internet |
skipping to change at page 26, line 25 skipping to change at page 23, line 25
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 a Binding Update to
HA2 and HA2 replies Binding Acknowledgement to MR2. The bi- HA2 and HA2 replies with a 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.
Non-encapsulated packets are marked "->" while encapsulated packets Non-encapsulated packets are marked "->" while encapsulated packets
are marked "=>". are marked "=>".
Consider next the attachment of the first mobile network under the Consider next the attachment of the first mobile network under the
second mobile network, like in Figure 21 below. second mobile network, like in Figure 21 below.
After this movement, MR1 acquires a Care-of Address valid in the After this movement, MR1 acquires a Care-of Address valid in the
second mobile network. Subsequently, it sends a Binding Update second mobile network. Subsequently, it sends a Binding Update (BU)
message addressed to HA1. This Binding Update is encapsulated by MR2 message addressed to HA1. This Binding Update is encapsulated by MR2
and sent towards HA2, which is expected to be placed in mobile net 1 and sent towards HA2, which is expected to be placed in mobile net 1
and expected to be at home. Once HA1/BR receives this encapsulated and expected to be at home. Once HA1/BR receives this encapsulated
BU, it tries to deliver to MR1. Since MR1 is not at home, and a BU, it tries to deliver to MR1. Since MR1 is not at home, and a
tunnel has not yet been set up between MR1 and HA1, HA1 is not able tunnel has not yet been set up between MR1 and HA1, HA1 is not able
to route this packet and drops it. Thus, the tunnel establishment to route this packet and drops it. Thus, the tunnel establishment
procedure between MR1 and HA1 is not possible, due to the fact that procedure between MR1 and HA1 is not possible, because the tunnel
the tunnel between MR2 and HA2 has been previously torn down (when between MR2 and HA2 had been previously torn down (when the mobile
the mobile net 1 has moved from home). The communications between CN net 1 moved from home). The communications between CN and LFN stops,
and LFN stops, even though both mobile networks are connected to the even though both mobile networks are connected to the Internet.
Internet.
/-----CN /-----CN
+----------+ +----------+
+--------+ | | +--------+ | |
| HA1/BR |---| Internet | | HA1/BR |---| Internet |
+--------+ | | +--------+ | |
+----------+ +----------+
\ \
+-----+ +-----+
| AR | | AR |
skipping to change at page 27, line 30 skipping to change at page 24, line 30
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
simply encapsulating each other. simply encapsulating each other.
Authors' Addresses Authors' Addresses
Chan-Wah Ng Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530 Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate Tai Seng Industrial Estate, Singapore 534415
Singapore 534415
SG SG
Phone: +65 65505420 Phone: +65 65505420
Email: chanwah.ng@sg.panasonic.com EMail: chanwah.ng@sg.panasonic.com
Pascal Thubert Pascal Thubert
Cisco Systems Technology Center Cisco Systems
Village d'Entreprises Green Side Village d'Entreprises Green Side
400, Avenue Roumanille 400, Avenue de Roumanille
Biot - Sophia Antipolis 06410 Batiment T3, Biot - Sophia Antipolis 06410
FRANCE FRANCE
Email: pthubert@cisco.com EMail: pthubert@cisco.com
Masafumi Watari Masafumi Watari
KDDI R&D Laboratories Inc. KDDI R&D Laboratories Inc.
2-1-15 Ohara 2-1-15 Ohara
Fujimino, Saitama 356-8502 Fujimino, Saitama 356-8502
JAPAN JAPAN
Email: watari@kddilabs.jp EMail: watari@kddilabs.jp
Fan Zhao Fan Zhao
University of California Davis UC 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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 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
skipping to change at page 29, line 45 skipping to change at page 26, 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.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 138 change blocks. 
361 lines changed or deleted 285 lines changed or added

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