One document matched: draft-zhao-nemo-ro-ps-00.txt
NEMO Working Group F. Zhao
Internet-Draft S F. Wu
Expires: April 18, 2005 UC Davis
S. Jung
Soongsil University
October 18, 2004
NEMO Route Optimization Problem Statement, Requirements and
Evaluation Considerations
draft-zhao-nemo-ro-ps-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes and analyzes the routing optimization problem
in NEMO, defines the requirements that must be met by NEMO route
optimization solutions and then describes the metrics to evaluate the
performance of NEMO route optimization solutions.
Zhao, et al. Expires April 18, 2005 [Page 1]
Internet-Draft NEMO RO Problem October 2004
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 formalization of the nested NEMO network . . . . . . . . . 11
7. The related tradeoff . . . . . . . . . . . . . . . . . . . . . 13
7.1 Data plane method vs. signaling plane method . . . . . . . 13
7.2 Optimization vs. the scalability issue in MR, CA and HA . 13
7.3 Optimization vs. the scope of change . . . . . . . . . . . 13
7.4 Location privacy vs. optimal route . . . . . . . . . . . . 13
7.5 Security vs. optimal route . . . . . . . . . . . . . . . . 13
7.6 Scalability vs. reliability . . . . . . . . . . . . . . . 14
8. The scope of NEMO RO problem . . . . . . . . . . . . . . . . . 15
8.1 What NEMO RO considers . . . . . . . . . . . . . . . . . . 15
8.2 What NEMO RO does not consider . . . . . . . . . . . . . . 15
9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Evaluation Considerations . . . . . . . . . . . . . . . . . 18
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
Zhao, et al. Expires April 18, 2005 [Page 2]
Internet-Draft NEMO RO Problem October 2004
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 and analyze the routing optimization
problem in NEMO, defines the requirements that must be met by NEMO
route optimization solutions and then describes the metrics to
evaluate the performance of NEMO route optimization solutions.
Zhao, et al. Expires April 18, 2005 [Page 3]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 4]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 5]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 6]
Internet-Draft NEMO RO Problem October 2004
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. [10] describes the
Zhao, et al. Expires April 18, 2005 [Page 7]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 8]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 9]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 10]
Internet-Draft NEMO RO Problem October 2004
6. 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.
|-------| |-------|
| MR1 | | MR2 |
|-------| |-------|
| | |
MNP1 | | MNP2 MNP2 |
--?------+ +-------?------?----------+
| | |
| | |
|eth0|-------|eth1| |eth0|-------|
|----| MR3 |----| |----| MR4 |
|-------| |-------|
In this figure, 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.
Figure 2: An example of nested NEMO network
The inbound graph is shown in Figure 3.
Zhao, et al. Expires April 18, 2005 [Page 11]
Internet-Draft NEMO RO Problem October 2004
|-------| |-------|
| 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 April 18, 2005 [Page 12]
Internet-Draft NEMO RO Problem October 2004
7. The related tradeoff
We discuss the tradeoffs when designing the solution for NEMO RO
problem.
7.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.
7.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.
7.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.
7.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.
7.5 Security vs. optimal route
In NEMO Basic Support protocol, it is very possible that there pre-
Zhao, et al. Expires April 18, 2005 [Page 13]
Internet-Draft NEMO RO Problem October 2004
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.
7.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 April 18, 2005 [Page 14]
Internet-Draft NEMO RO Problem October 2004
8. The scope of NEMO RO problem
8.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 [10].
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
8.2 What NEMO RO does not consider
TBD.
Zhao, et al. Expires April 18, 2005 [Page 15]
Internet-Draft NEMO RO Problem October 2004
9. 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 April 18, 2005 [Page 16]
Internet-Draft NEMO RO Problem October 2004
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 April 18, 2005 [Page 17]
Internet-Draft NEMO RO Problem October 2004
10. 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 April 18, 2005 [Page 18]
Internet-Draft NEMO RO Problem October 2004
11. Acknowledgement
We sincerely thank Alexandru Petrescu, Thierry Ernst, Pascal Thubert,
Carlos Jess Bernardos Cano and Masafumi Watari for their comments and
valuable suggestions.
12 References
[1] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-02 (work in progress), February
2004.
[2] Ernst, T. and H-Y. Lach, "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-01 (work in
progress), February 2004.
[3] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubertet,
"Network Mobility (NEMO) Basic Support Protocol", IETF proposed
standard, draft-ietf-nemo-basic-support-03, June 2004.
[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-00 (work in progress), July
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] Thubert, P., Molteni, M., Ng, C., Ohnishi, H. and E. Paik,
"Taxonomy of Route Optimization models in the Nemo Context",
draft-thubert-nemo-ro-taxonomy-02 (work in progress), February
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] Watari, M. and T. Ernst, "Route Optimization with Nested
Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in
progress), October 2004.
Zhao, et al. Expires April 18, 2005 [Page 19]
Internet-Draft NEMO RO Problem October 2004
Authors' Addresses
Fan Zhao
University of California, Davis
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
University of California, Davis
One Shield Avenue
Davis, CA 95616
US
Phone: +1 530 754 7070
EMail: sfwu@ucdavis.edu
Souhwan Jung
Soongsil University
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 April 18, 2005 [Page 20]
Internet-Draft NEMO RO Problem October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhao, et al. Expires April 18, 2005 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-22 05:26:37 |