NEMO Working Group F. Zhao
Internet-Draft S F. Wu
Expires: August 25, 2005 UC Davis
S. Jung
Soongsil University
February 21, 2005
NEMO Route Optimization Problem Statement and Analysis
draft-zhao-nemo-ro-ps-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes the routing optimization problem in NEMO and
analyzes the related approaches to solve this problem.
Zhao, et al. Expires August 25, 2005 [Page 1]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The definition of "optimal" and "non-optimal" route . . . . . 6
4.1 Optimal route . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1 CN is not under the same nested NEMO as its peer,
MNN . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2 CN is under the same nested NEMO as its peer, MNN . . 6
4.2 Non-optimal route . . . . . . . . . . . . . . . . . . . . 7
4.3 Approximately optimal route . . . . . . . . . . . . . . . 8
5. Limitation of NEMO Basic Support protocol . . . . . . . . . . 9
5.1 Reverse tunneling . . . . . . . . . . . . . . . . . . . . 9
5.2 HA as the only anchor point . . . . . . . . . . . . . . . 9
5.3 Inside the nested NEMO . . . . . . . . . . . . . . . . . . 9
5.4 Data plane based method . . . . . . . . . . . . . . . . . 9
5.5 Data packet and processing overhead . . . . . . . . . . . 10
5.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. The related tradeoff . . . . . . . . . . . . . . . . . . . . . 11
6.1 Data plane method vs. signaling plane method . . . . . . . 11
6.2 Optimization vs. the scalability issue in MR, CA and HA . 11
6.3 Optimization vs. the scope of change . . . . . . . . . . . 11
6.4 Location privacy vs. optimal route . . . . . . . . . . . . 11
6.5 Security vs. optimal route . . . . . . . . . . . . . . . . 11
6.6 Scalability vs. reliability . . . . . . . . . . . . . . . 12
7. The scope of NEMO RO problem . . . . . . . . . . . . . . . . . 13
7.1 What NEMO RO considers . . . . . . . . . . . . . . . . . . 13
7.2 What NEMO RO does not consider . . . . . . . . . . . . . . 13
8. The analysis of related approaches . . . . . . . . . . . . . . 14
8.1 Question 1 . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1.1 The point of attachment to AR . . . . . . . . . . . . 14
8.1.2 The point of attachment to MR . . . . . . . . . . . . 16
8.1.3 Some common issues . . . . . . . . . . . . . . . . . . 16
8.2 Question 2 . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3 Question 3 . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21
B. Evaluation Considerations . . . . . . . . . . . . . . . . . . 23
C. The formalization of the nested NEMO network . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . . 26
Zhao, et al. Expires August 25, 2005 [Page 2]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
1. Introduction
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
interpreted as described in RFC2119 [7].
NEMO Basic Support protocol maintains the connectivity when MR
changes its point of attachment to the Internet by establishing a bi-
directional tunnel between MR and HA. Like MIP6, the protocol
specification introduces one level of indirection in the routing
system in favor of protocol simplicity and minimal changes on fixed
nodes. However, it results in a non-optimal (We will define
"optimal" and "non-optimal" later.) route between MNN and CN with a
non-zero and even very large probability, which causes the
significant communication delay. Moreover, by using IPv6 header
encapsulation together with other options, NEMO Basic Support
protocol also causes big overheads in packet payload and bandwidth.
NEMO RO problem introduces more challenges and more difficulties than
MIP6 RO problem because of the nested NEMO network where multiple
levels of mobility are formed. Without NEMO RO solution, the
performance becomes much worse especially in the nested NEMO.
In this draft, we describe the routing optimization problem in NEMO
and analyze the related approaches to solve this problem. In the
appendixes, we also define the requirements that must be met by NEMO
route optimization solutions and describe the metrics to evaluate the
performance of NEMO route optimization solutions as well as the
formalization of the nested NEMO network.
Zhao, et al. Expires August 25, 2005 [Page 3]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
2. Terminology
The terms used in this draft are defined in [2], besides the
following ones:
Correspondent Agent (CA): An entity (router or host) performs the
RO function with MR on behalf of CN. In NEMO when MR acts as a
gateway and performs RO function for an entire mobile network
associated with itself, its peer is CA rather than CN that is
instead the peer of MNN from an end-to-end perspective. CA may be
just CN itself or a router near CN or even CN's default router.
One MR could have multiple CAs at the same time because MNNs
behind this MR may communicate with CNs in the different networks.
And in NEMO Basic Support protocol, HA acts as CA for any node in
the Internet to communicate with MNN behind its MR.
Anchor point: the entity that knows the binding information
between host and location and thus is capable of forwarding the
data packets destined for a host to the location directly. In the
fixed network, each router is such kind of anchor point because IP
address represents both location and host, and the destination IP
address together with the routing table provides the sufficient
knowledge on how to reach the destination. However in the NEMO
mobile network that is compliant with NEMO Basic Support protocol,
HA is the only anchor point for CN and MNN. In order to achieve
the optimal route in NEMO, MR and CA should become anchor point
too. In most cases, the closer to MNN/CN the anchor point is, the
shorter the routing path is.
Inbound direction: The direction from the Internet infrastructure
to the inside of NEMO network.
Outbound direction: The direction from the inside of NEMO network
to the Internet infrastructure.
Inbound route : The route taken by the packets forwarded in the
inbound direction. Inbound route is used exchangeably with
inbound path.
Outbound route : The route taken by the packets forwarded in the
outbound direction. Outbound route is used exchangeably with
outbound path.
Zhao, et al. Expires August 25, 2005 [Page 4]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
3. Assumptions
In this draft we do not consider the case of mobile HA. Instead we
assume that all HAs are fixed nodes and are located in the Internet
infrastructure. Firstly it is not clear yet about the need of mobile
HA in the real life at this moment. Secondly and more importantly,
since a mobile HA needs the help of another fixed HA in order to
forward the traffic for MRs, the mobile HA case can be deduced into
the similar case with only fixed HA. Our description has no
difficulty to be extended into the mobile HA case. Thus we believe
that this assumption is reasonable and does not prevent the thorough
analysis on NEMO RO problem.
Zhao, et al. Expires August 25, 2005 [Page 5]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
4. The definition of "optimal" and "non-optimal" route
NEMO route optimization solution aims to provide the optimal route
between MNN and CN as well as between MR and CA. As it has been
understood for a long time that the routing path in the Internet is
asymmetric, in the following text we consider just either of two
directions without explicit statement and the same analyses also
apply to the other direction.
4.1 Optimal route
In the NEMO Route Optimization problem, "optimal route" is not the
topologically shortest path or the best route in terms of any other
metric from source to destination. Based on the location of CN,
"optimal route" is discussed in the following cases:
4.1.1 CN is not under the same nested NEMO as its peer, MNN
CN may be located in either fixed or mobile network. As the route
between MNN/MR and CN/CA consists of two portions, the route in the
Internet and the route inside the (nested) NEMO network, we define
them separately. The "optimal route" in the Internet is the route
between the location of MNN/MR and the location of CN/CA based on the
forwarding tables of Internet routers, which is usually built by
inter-domain or intra-domain routing protocol. Precisely, location
is the point of attachment to the Internet. While in MIP6 MN's
Care-of-Address represents its location of attachment to the
Internet, in the nested NEMO MNN/MR's Care-of-Address is not
sufficient any more to represent its location of attachment to the
Internet except the case of root-MR; Instead it represents the point
of attachment to the parent MR or the location inside the parent
NEMO. A sequence of Care-of-Addresses of MRs or other ways may be
used to represent the location of MR in the NEMO RO solution.
The "optimal route" inside the NEMO network is formed by the decision
of each MR along the outbound and inbound path. In the outbound
direction, MR just forwards the packets to its default router that is
determined when MR associates to NEMO network while in the inbound
direction, MR forwards the packets to the next hop depending on the
solution. The inbound path inside the NEMO network may be different
from the outbound path. Note that the route inside the NEMO network
does not contain HA.
4.1.2 CN is under the same nested NEMO as its peer, MNN
CN may be under the same MR or different MR from its peer. We assume
that node1 wants to communicate with node2 under the same nested
NEMO. Path p1 = <MR_(1,1), MR_(1,2), ..., MR_(1,m)> is the sequence
Zhao, et al. Expires August 25, 2005 [Page 6]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
of routers inside the nested NEMO for node1 to reach node2 and path
p2 = <MR_(2,1), MR_(2,2), ..., MR_(2,n)> is the sequence of routers
inside the nested NEMO for node2 to reach node1.
Case 1: If the intersection of p1 and p2 is not empty, denoted by
<MR_(1,i1), MR_(1,i2), ..., MR_(1,ik)> = <MR_(2,j1), MR_(2,j2), ...,
MR_(2,jk)> where i1 < i2 < ... < ik and j1 < j2 < ... < jk, then
ideally the optimal path between node1 and node2 is <MR_(1,1),
MR_(1,2), ..., MR_(1,i1), MR_(2,j1-1), ..., MR_2,2, MR_2,1>. Note
that MR_(1,i1) is equal to MR_(2,j1).
|-----| |-----|
|---| MR2 |---| MR3 |--LFN3
| |-----| |-----|
|-------| |-----|
|Root-MR|---| MR1 |
|-------| |-----|
| |-----| |-----|
|---| MR4 |---| MR5 |--LFN5
|-----| |-----|
Figure 1: The optimal route inside the nested NEMO
For example, in the nested NEMO shown by Figure 1, the optimal route
between LFN3 and LFN5 is MR3<->MR2<->MR1<->MR4<->MR5.
The optimal route in this case is the route turning around at the
first MR that is aware of how to forward the data packets from source
to destination without going out of the nested NEMO. However, in
NEMO Basic Support protocol, the data packet takes a route that goes
out of the nested NEMO and comes back to the same nested NEMO again.
Case 2: If the intersection of p1 and p2 is empty (It may be due to
multiple different root-MRs and no inter-communication between them),
the "optimal route" inside the nested NEMO consists of both p1 and
p2, and the "optimal route" inside the Internet follows the
definition in Section 4.1.1.
4.2 Non-optimal route
In NEMO Basic Support protocol, the packets are forwarded to an
intermediate box, HA, in both directions rather than the location of
destination directly, which results in a longer route than the
"optimal route" with a high probability. We refer this kind of route
as "non-optimal" route. Worse than MIP6, in the nested NEMO network
the packets are forwarded to multiple HAs in both directions before
arriving at the location of destination. [14] describes the
Zhao, et al. Expires August 25, 2005 [Page 7]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
non-optimal route that packets would take using existing Mobile IPv6
and NEMO Basic Support mechanisms
4.3 Approximately optimal route
The solution to achieve an "optimal route" has to consider a lot of
other factors, for example, scalability, efficiency, and security, to
name a few. Although the solution may result in an approximately
optimal route, it must be the best overall when all the related
issues are taken into consideration.
Zhao, et al. Expires August 25, 2005 [Page 8]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
5. Limitation of NEMO Basic Support protocol
In this section, we analyze the limitation of NEMO Basic Support
protocol and the reasons to cause the non-optimal route.
5.1 Reverse tunneling
In NEMO Basic Support protocol, all the packets forwarded by MR in
the outbound direction have to go through HA firstly. If the reverse
tunnel would be removed in NEMO RO solution, it is equivalent to the
case where MR is the anchor point for the outbound packet.
Instead in the normal fixed network, the data packets are sent to the
destination directly.
5.2 HA as the only anchor point
Since MR is refrained from announcing its MNP to the infrastructure
due to the conflicts and routing instability issues, HA is the only
anchor point for MNN as well as CN and thus the packets destined to
MNNs can be served only by HA. Even worse in the nested NEMO, the
packets inevitably have to go through multiple HAs in order to be
forwarded to MNN correctly.
The non-optimal route is formed because the binding information is
available in HA only and the HA's location is limited in home network
only. Image that there are as many HAs as routers scattering around
the Internet, every data packet from CN is forwarded by a nearby HA
and takes at least a nearly optimal route. Deploying multiple HAs in
the different domains or spreading binding information needs to
consider a lot of issues, such as fundamental changes, conflict and
scalability etc.
Compared with the fixed network, there is no limitation on the
location of anchor point because each router is such an anchor point.
5.3 Inside the nested NEMO
If MR inside the nested NEMO is refrained from announcing its MNP to
other MRs, MR does not know how to forward in the inbound direction
just based on the destination IP address and its own limited
knowledge of topology. Thus MR has to depend on the explicit
IP-in-IP header to forward to the next hop, which in return requires
that each data packet should go through HA.
5.4 Data plane based method
We categorize NEMO as a data plane method because 1) there is no
Zhao, et al. Expires August 25, 2005 [Page 9]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
signaling message introduced for CN to discover or update the binding
information; 2) many changes are made in order for the routing
decision to be explicitly carried in the data packet in an "in-band"
fashion. The limitation of this data plane method is that every data
packet has to experience the non-optimal route even though the
optimal route may be existing and fairly stable within a certain time
window. Considering the potential large number of data packets, the
inefficiency as well as the benefits if the problem is solved are
very big.
On the other hand this method avoids the large change on the
infrastructure. Given the fact that a big change on the
infrastructure may take a longer time to deploy, a RO solution in
data plane may qualify as a necessary step before a revolutionary
change happens.
5.5 Data packet and processing overhead
Encapsulation and other options in IPv6 header cause the overhead in
data packet and bandwidth, packet fragmentation, and the processing
overhead in MR and HA especially in the nested NEMO where every level
of mobility introduces one encapsulation together with applicable
option fields into the data packet.
In the fixed network, encapsulation and other options are not needed
since all the routing decision is purely based on the forwarding
table and the destination IP address.
5.6 Summary
One significant difference between MIP6 and NEMO is the management
granularity that is a single host in MIPv6 and a mobile network in
NEMO. Another significant difference is the multiple levels of
mobility in the nested NEMO, which not only causes much longer
routing path and bigger overhead in the data payload but also more
challenges when attempting to solve NEMO RO problem, for example,
given that any other factor is constant, the number of messages (RR
test, BU etc) is in direct proportion to the number of MRs along the
path if no cooperation among them. In summary, NEMO RO problem is a
challenging problem and requires a well-designed NEMO RO solution.
Zhao, et al. Expires August 25, 2005 [Page 10]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
6. The related tradeoff
We discuss the tradeoffs when designing the solution for NEMO RO
problem.
6.1 Data plane method vs. signaling plane method
Data plane method needs fewer changes but introduces more overheads
while signaling plane method may require more changes on the
protocols. We need to consider how to utilize the advantages of both
methods and avoid the disadvantages.
6.2 Optimization vs. the scalability issue in MR, CA and HA
The closer to CN CA is, the more optimal route; but MR has to perform
RO functions with more CAs when the number of different CNs is large
and all CNs scatter around the Internet. MR may choose not to
perform RO function but NEMO Basic Support protocol due to the
management cost.
On the other hand, if there are many MRs belonging to the same home
network scattering around the Internet, because of the same reason,
CA may also choose to perform NEMO Basic Support protocol with HA
rather than to perform RO function with each MR.
If there are many HAs, each of which is close to each MR belonging to
the same home network, the route between MNN and CN is at least
nearly optimal. Thus there is a tradeoff between the optimal route
and the scalability issue in terms of the number of HAs.
6.3 Optimization vs. the scope of change
The scope of change is in terms of the number of nodes that need to
be changed in order to support NEMO RO solution. If all CNs are
changed to support the NEMO RO, the optimal route is formed; however,
if the scope of change is a limited number of nodes, the probability
that a sub-optimal route is formed could be very large.
6.4 Location privacy vs. optimal route
Bi-direction tunnel in NEMO Basic Support protocol can maintain some
level of location privacy. A potential RO solution may require some
location information to be revealed in order to facility route
optimization.
6.5 Security vs. optimal route
In NEMO Basic Support protocol, it is very possible that there pre-
Zhao, et al. Expires August 25, 2005 [Page 11]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
exists the security association between MR and HA, which helps resist
the various attacks. However in NMEO RO solution, as the MR-HA
tunnel may not exist and there is no pre-existing security
association between two entities from the different domains, it is
more challenging to maintain the same security strength as in NEMO
Basic Support protocol.
6.6 Scalability vs. reliability
This is a general tradeoff in NEMO. As MR manages a whole mobile
network, when MR fails due to attack or error, a bunch of MNNs behind
MR lose the connectivity even though any single MNN still functions
well. However, generally it provides more scalability than MIP6.
Zhao, et al. Expires August 25, 2005 [Page 12]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
7. The scope of NEMO RO problem
7.1 What NEMO RO considers
(Below is an incomplete list of issues related to NEMO RO problem
quoted from the NEMO mailing list. More discussions are still
needed.)
o NEMO The optimal route when two communicating nodes are located
either in the same or different (nested) NEMO network [14].
o VMN may choose not to perform MIP6 RO solution so that even though
MR performs NEMO RO function, the packets originated from and
destined to VMN still have to go through VMN's HA. We need to
consider all the related issues if we want to remove this kind of
sub-optimal route for VMN.
o Missing signaling messages when performing NEMO RO
o Obsolete state or signaling message when mobility causes the
topology changes
o RO problem when multi-homing is also involved
o Data packet overhead when header encapsulation, options and
routing header are used
o Security problem.
o Location privacy problem
o Looping problem
o Cross-over tunnel problem
o BU storm
7.2 What NEMO RO does not consider
TBD.
Zhao, et al. Expires August 25, 2005 [Page 13]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
8. The analysis of related approaches
In this section, we analyze the related approaches. Generally a NEMO
RO solution should make the anchor point close to either CN or MNN.
One exmaple of the latter is HA-HA protocol [10][11][12]. However
since the latter may only achieve the approximate optimal route in
some situations, we focus on a large range of approaches that aim at
making the binding information available to CN/CR directly in the
following discussion.
From NEMO RO problem described and analyzed before, we expect a NEMO
RO solution to answer the following questions:
o Q1: How to represent/achieve the full binding information between
Home_Address/Home_Network_Prefix and the point of attachment to a
specific router (AR when CN is not under the same nested NEMO
network or the first common MR when CN is under the same nested
NEMO network ideally.).
o Q2: How to transfer this information from HA/MR to CN/CR/other
routers (other MR/AR that is close to CN).
o Q3: How to route the data packet based on the available full
binding information.
The related approaches are categorized to answer Q1, Q2, and Q3
respectively and the related issues are analyzed in the following.
8.1 Question 1
Since the information of Home_address/Home_network_prefix is already
available to MR and HA, we focus on the information about the point
of attachment:
8.1.1 The point of attachment to AR
o A sequence of CoAs
The information about each upstream MR's CoA is collected thus
a sequence of CoAs is formed to represent the point of
attachment to AR. There are several different methods to do
that. For example, in RRH [9] each upstream MR's CoA is
attached to one payload in the data packet; it is also possible
for MR/MNN to send the specific formatted packet to collect the
information of upstream MRs.
Issues: This approach requires a dedicated payload in each data
packet to store the sequence of CoAs. Thus the overhead in the
Zhao, et al. Expires August 25, 2005 [Page 14]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
data packet may become very large when there are multiple
nested MRs in the NEMO network.
The issues related to the probing method are that a probing
procedure is needed and the collected information may become
invalid if some MR moves after the probing.
How to determine the length of the payload is the issue related
to the other method. If we allow this payload to contain
arbitrary number of CoAs, the data packet might be fragmented
during the transmission. On the other hand, if the information
of the nested levels in the NEMO network is not available when
MR starts the communication, the fixed length payload could
result in either the partial optimized route (The payload
cannot contain all the CoAs.) or the wasted payload/bandwidth
(Part of payload is not used.).
Security issue has to be considered if there is an eavesdropper
or malicious MR on the path.
o Prefix delegation
This approach removes the need of a sequence of CoAs by using
prefix delegation from the one owned by AR to enable each MR
inside the nested NEMO network to achieve a globally routable
CoA as a primary CoA and establish the routing table
accordingly.
Issues: The related protocol and message need to be extended.
One nice thing is that the prefixes delegated to each MR can be
aggregated.
o Routing protocol
This approach allows MR to establish routing table or other
kind of soft states about how to forward the data packets.
Issues: Updating routing table or soft state may require some
signaling message or specific payload in the data packet. And
the authenticity of such information needs to be guaranteed.
Once the states are established correctly, the data packet
could be transmitted in a normal IPv6 format.
o CN deduces from a sequence of BU packets or BC entries.
Each MR sends the BU message to CN and CN looks up its BC
(maybe for multiple times) to retrieve the full binding
information.
Zhao, et al. Expires August 25, 2005 [Page 15]
Issues: Besides the time used to look up the BC, there may be
some redundancy if each MR needs to send the BU message to CN
individually.
8.1.2 The point of attachment to MR
Similar with those described above.
8.1.3 Some common issues
Authorization issue: Each mechanism needs the authorization of
upstream MR to collect the information along the path in order to
achieve the complete optimal route.
Authentication issue: The authentication of information needs to be
protected against eavesdropper and malicious MR on the path. However
the strength of protection might vary under the different
assumptions.
8.2 Question 2
To answer this question, firstly we have to consider which one
initializes the NEMO RO signaling procedure, MR/HA or CN/CR.
o CN/CR as an initiator
If MNN is a mobile server, CN/CR might have the motivation to
initialize the route optimization procedure in order to improve
the communication performance. This case might be rare in
practice, but if it wants to, CN/CR needs a mechanism to detect
whether MR is away from the home network.
o MR/HA as an initiator
Usually MR initializes the procedure and the information flow
is from MR.
The security issues: MR/HA must register MNP and HoA with CN or CR in
a secure way when there is no pre-existing security association
between MR/HA and CN/CR. Similar with that in MIP6 RO mechanism, a
RR test on network prefix may be used to enhance the security
[15][16].
8.3 Question 3
o IP-in-IP
o Routing header and other options
Zhao, et al. Expires August 25, 2005 [Page 16]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
It is required that MR can process the new types of routing
header or options. Please note that the processing on routers
in the Internet should be avoided.
o Combination of these two.
Zhao, et al. Expires August 25, 2005 [Page 17]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
9. Acknowledgement
We sincerely thank Alexandru Petrescu, Thierry Ernst, Pascal Thubert,
Carlos Jess Bernardos Cano and Masafumi Watari for their comments and
valuable suggestions.
10. References
[1] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-03 (work in progress), October
2004.
[2] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-02 (work in
progress), October 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Ng, C., Paik, E. and T. Ernst, "Analysis of Multihoming in
Network Mobility Support",
draft-ietf-nemo-multihoming-issues-01 (work in progress),
October 2004.
[6] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling between Mobile Nodes and Home
Agents", RFC 3776, June 2004.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[8] Ng, C., Thubert, P., Ohnishi, H. and E. Paik, "Taxonomy of
Route Optimization models in the Nemo Context",
draft-thubert-nemo-ro-taxonomy-03 (work in progress), October
2004.
[9] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-05 (work in
progress), June 2004.
[10] Thubert, P., Wakikawa, R. and V. Devarapalli, "Global HA to HA
protocol", draft-thubert-nemo-global-haha-00 (work in
progress), October 2004.
Zhao, et al. Expires August 25, 2005 [Page 18]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
[11] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home
Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work
in progress), February 2004.
[12] Wakikawa, R., Thubert, P. and V. Devarapalli, "Inter Home
Agents Protocol Specification",
draft-wakikawa-mip6-nemo-haha-spec-00 (work in progress),
October 2004.
[13] Lee, K-J., Jeong, J-H., Park, J-S. and H-J. Kim, "Route
Optimization for Mobile Nodes in Mobile Network based on Prefix
Delegation", draft-leekj-nemo-ro-pd-02 (work in progress),
February 2004.
[14] Watari, M. and T. Ernst, "Route Optimization with Nested
Correspondent Nodes", draft-watari-nemo-nested-cn-01 (work in
progress), February 2005.
[15] Ng, C. and J. Hirano, "Extending Return Routability Procedure
for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
progress), October 2004.
[16] Zhao, F., Wu, S F. and S. Jung, "Extensions to Return
Routability Test in MIP6", draft-zhao-mip6-rr-ext-01 (work in
progress), February 2005.
Authors' Addresses
Fan Zhao
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
Email: fanzhao@ucdavis.edu
S. Felix Wu
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 754 7070
Email: sfwu@ucdavis.edu
Zhao, et al. Expires August 25, 2005 [Page 19]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
Souhwan Jung
Soongsil University
1-1, Sangdo-dong, Dongjak-ku
Seoul 156-743
KOREA
Phone: +82 2 820 0714
Email: souhwanj@ssu.ac.kr
Zhao, et al. Expires August 25, 2005 [Page 20]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
Appendix A. Requirements
The goal of NEMO RO solution is to provide an optimal route between
any two nodes regradless of the location, the configuration, and the
type etc. Besides those defined in [1], NEMO RO solution, hereafter
referred to as "the solution", must meet the following requirements
that are described in the descending order of importance as follows:
R1: When any MR in NEMO performs NEMO RO function, the route taken
by the traffic from this MR together with any MNN inside this MR's
sub-NEMO MUST be better than the one resulted in by performing
NEMO Basic Support protocol.
R2: Signaling messages MUST be secured to guarantee the integrity,
confidentiality, anti-replay and authorization. The insider
attack where the attacker is on the routing path SHOULD be at
least detected while the outsider attack where the attacker is not
on the routing path MUST be resisted. The security mechanism MUST
prevent the forged packet being forwarded in a loop inside NEMO
and MUST not generate the new vulnerability. Overall, the
security level and the location privacy MUST be kept as strong as
in NEMO Basic Support protocol.
R3: This solution SHOULD introduce limited signaling overhead,
limited packet payload overhead, limited memory cost needed for
processing, limited complexity in term of data structure and
protocol state machine transition.
R4: The solution MUST be able to support a potentially large
number of MNNs, CNs, CAs as well as HAs (if applicable) and
arbitrary levels of MRs unless because of other constraints.
R5: The solution SHOULD avoid too many changes on MNN/MR/CN/CA/HA
unless the significant performance improvement can be achieved.
It is desired to keep the mobility transparency for MNN behind MR.
R6: The solution SHOULD be able to handle the topology changes in
any kind of mobility pattern very well and minimize the impact of
handover over applications, in term of packet loss or delay.
R7: The solution SHOULD function for multi-homing NEMO networks
(multiple MNPs, multiple MRs and multiple network interfaces,
etc.). The solution SHOULD not conflict with multi-homing
mechanism, such as loading balance, fault tolerance etc.
R8: Each MR can either independently decide whether to perform RO
function or NEMO Basic Support protocol or collaborate with other
MR based on its policy. The decision made by one MR MUST not
Zhao, et al. Expires August 25, 2005 [Page 21]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
prevent other MR performing either NEMO RO or NEMO Basic Support
protocol properly.
R9: The solution SHOULD ensure backward compatibility with other
standards defined by the IETF. Especially the solution MUST not
prevent the proper operation of Mobile IPv6 (i.e. the solution
MUST allow MIP6-enabled MNNs to operate either of the CN, HA, or
MN operations defined in MIP6.) and NEMO Basic Support protocol.
More?
Zhao, et al. Expires August 25, 2005 [Page 22]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
Appendix B. Evaluation Considerations
The following metrics are defined to evaluate how good a NEMO RO
solution is besides meeting the requirements described above. Each
metric may be assigned a weight in order to find a overall best RO
solution.
o Level of compatibility with NEMO Basic Support protocol
o Complexity: How many changes to MNN/MR/CA/HA are introduced? Does
the solution maintain the mobility transparency for MNN?
o Performence:
* The delay to discover and set up the optimal path
* The packet overhead and/or signaling overhead to discover and
set up the optimal path
* The delay to re-discover and re-build the optimal path when the
mobility causes the topology change
* The packet overhead and/or signaling overhead to re-discover
and re-build the optimal path when the mobility causes the
topology change
o Management cost:
* The number of states established or maintained in MR/CA/HA
* The number of MNNs supported by MR/CA/HA
o More?
Zhao, et al. Expires August 25, 2005 [Page 23]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
Appendix C. The formalization of the nested NEMO network
The topology of the nested NEMO can be formalized into graph. When
care is taken to avoid the loop to be formed, this graph is a
Directed Acyclic Graph that may be also considered as a set of
multiple overlapping trees.
The inbound graph is a direct graph <V, E> where each node in V
denotes a MR and if one of egress interfaces in MRj gets its
care-of-address from one MNP owned by MRi, the link from MRi to MRj,
<MRi, MRj> belongs to the edge set E.
The outbound graph is a direct graph <V, E> where each node in V
denotes a MR and if MRj chooses MRi as its default router, the link
from MRj to MRi, <MRj, MRi> belongs to the edge set E.
This method can also formalize a multi-homing nested NEMO where there
could be more than one egress interface associated with one MR and
more than one MR owning one or more MNPs. Figure 2 below shows an
exmaple of nested NEMO network where MR1 announces MNP1 and MNP2
while MR2 announces MNP2; MR3 has two interfaces that associate with
MR1 and MR2 respectively while MR4 associates with MR2 only.
|-------| |-------|
| MR1 | | MR2 |
|-------| |-------|
| | |
MNP1 | | MNP2 MNP2 |
--?------+ +-------?------?----------+
| | |
| | |
|eth0|-------|eth1| |eth0|-------|
|----| MR3 |----| |----| MR4 |
|-------| |-------|
Figure 2: An example of nested NEMO network
The inbound graph is shown in Figure 3.
Zhao, et al. Expires August 25, 2005 [Page 24]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
|-------| |-------|
| MR1 |--- ---| MR2 |
|-------| \ / |-------|
| | \ / |
V V X V
|-------| / \ |-------|
| MR3 |<--/ \-->| MR4 |
|-------| |-------|
Figure 3: The inbound graph of a nested NEMO network
We can simplify the inbound graph shown in Figure 3 into the
following one.
|-------| |-------|
| MR1 |--- ---| MR2 |
|-------| \ / |-------|
| \ / |
V X V
|-------| / \ |-------|
| MR3 |<--/ \-->| MR4 |
|-------| |-------|
Figure 4: The simplified inbound graph of a nested NEMO network
Assume that MR3 chooses MR2 as the default router through eth1 and
MR4 chooses MR1 as the default router through eth0. The outbound
graph of this nested NEMO is shown in Figure 5.
|-------| |-------|
| MR1 |<-- -->| MR2 |
|-------| \ / |-------|
\ /
X
|-------| / \ |-------|
| MR3 |---/ \---| MR4 |
|-------| |-------|
Figure 5: The outbound graph of a nested NEMO network
The formalization may help us understand the problem better and
develop the RO solution. For example, if an explicit next hop
address is presented in the packet, MR has to check whether this next
hop address belongs to one of its MNPs in order to prevent an
attacker forcing the packet to be forwarded in a loop.
Zhao, et al. Expires August 25, 2005 [Page 25]
Internet-Draft NEMO RO Problem Statement and Analysis February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhao, et al. Expires August 25, 2005 [Page 26]