NEMO Working Group C. Ng
Internet-Draft Panasonic Singapore Labs
Expires: April 25, 2005 P. Thubert
Cisco Systems
H. Ohnishi
NTT
E. Paik
KT
October 25, 2004
Taxonomy of Route Optimization models in the NEMO Context
draft-thubert-nemo-ro-taxonomy-03
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 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
With current Network Mobility (NEMO) Basic Support, all
communications to and from mobile network nodes must go through the
Ng, et al. Expires April 25, 2005 [Page 1]
Internet-Draft RO-Taxonomy October 2004
MR-HA tunnel when the mobile network is away. This results in
increased length of packet route and increased packet delay. To
overcome these limitations, one might have to turn to route
optimization (RO) for NEMO. This memo documents various types of
route optimization in NEMO, and explores the benefits and tradeoffs
in different aspects of NEMO route optimization.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement of NEMO Route Optimization . . . . . . . . . 4
2.1 Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2 Nesting of Mobile Networks . . . . . . . . . . . . . . . . 5
2.3 MIPv6 Host in Mobile Networks . . . . . . . . . . . . . . 7
2.4 Communications within a Mobile Networks . . . . . . . . . 7
3. Solution Space of NEMO Route Optimization . . . . . . . . . . 8
3.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . . . 9
3.2 Infrastructure Optimization . . . . . . . . . . . . . . . 10
3.3 Nested Tunnels Optimization . . . . . . . . . . . . . . . 11
3.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 12
3.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 13
4. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 14
4.1 General Considerations of RO Solution . . . . . . . . . . 14
4.1.1 Additional Signaling Overhead . . . . . . . . . . . . 14
4.1.2 Increased Protocol Complexity . . . . . . . . . . . . 15
4.1.3 Mobility Awareness . . . . . . . . . . . . . . . . . . 15
4.1.4 New Functionalities . . . . . . . . . . . . . . . . . 15
4.1.5 Other Considerations . . . . . . . . . . . . . . . . . 17
4.2 Specific Types of RO Solution . . . . . . . . . . . . . . 17
4.2.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . 17
4.2.2 Infrastructure Optimization . . . . . . . . . . . . . 19
4.2.3 Nested Tunnels Optimization . . . . . . . . . . . . . 20
4.2.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . 21
4.2.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . 23
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
A. Proposed Route Optimizations . . . . . . . . . . . . . . . . . 29
A.1 MR-to-CN Optimizations . . . . . . . . . . . . . . . . . . 29
A.2 Infrastructure Optimizations . . . . . . . . . . . . . . . 29
A.3 Nested Tunnel Optimizations . . . . . . . . . . . . . . . 30
A.4 MIPv6-over-NEMO Optimizations . . . . . . . . . . . . . . 32
A.5 Intra-NEMO Optimizations . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . 34
Ng, et al. Expires April 25, 2005 [Page 2]
Internet-Draft RO-Taxonomy October 2004
1. Introduction
With current Network Mobility (NEMO) Basic Support [1], all
communications to and from nodes in a mobile network must go through
the bi-directional tunnel established between the mobile router (MR)
and its home agent (HA) when the mobile network is away. Although
such an arrangement allows mobile network nodes (MNNs) to reach and
be reached by any node on the Internet, there are associated
limitations which might be unacceptable for certain applications. To
substantially ameliorate these limitations, one might have to turn to
route optimization (RO) for NEMO. Here, we use the term "route
optimization" to loosely refer to any approach that optimize the
route taken by packets sent between a mobile network node and
correspondent node (CN).
This document aims to explore limitations inherent in NEMO Basic
Support, and analyze the possible approaches to route optimization
with NEMO. It is expected for readers to be familiar with general
terminologies related to mobility in [2] and [3], and NEMO related
terms defined in [4]. In addition, it is beneficial to keep in mind
the design requirements of NEMO [5]. A point to note is that since
this document discusses aspects of route optimization, the readers
may assume that a mobile network or a mobile host is away when they
are mentioned throughout this document, unless it is explicitly
specified that they are at home.
It is the objective of this document to address the need for a route
optimization analysis in the NEMO Working Group. To quote the
charter of the NEMO Working group:
"... The WG will work on: ... ... [an] informational document
which specifies a detailed problem statement for route
optimization and looks at various approaches to solving this
problem. This document will look into the issues and tradeoffs
involved in making the network's movement visible to some nodes,
by optionally making them "NEMO aware". The interaction between
route optimization and IP routing will also be described in this
document. Furthermore, security considerations for the various
approaches will also be considered. ..."
To such end, this document first describes the problem of route
optimization in NEMO in Section 2. Next, we explore into various
possible approaches to solving the problem of route optimization in
Section 3. Following this, Section 4 discusses various issues that a
route optimization solution might face. Finally, Section 5 concludes
this memo. In addition, we attempt to list various proposed
solutions for route optimization in Appendix A, and classify them
according to the solution space described in Section 3.
Ng, et al. Expires April 25, 2005 [Page 3]
Internet-Draft RO-Taxonomy October 2004
2. Problem Statement of NEMO Route Optimization
In essence, the problem of route optimization in NEMO is to eliminate
limitations, or sub-optimality, introduced by the bi-directional
tunnel between a mobile router and its home agent (also known as the
MR-HA tunnel). In the following sub-sections, we will describe the
effects of sub-optimal routing with NEMO-Basic Support, and how they
get amplified with nesting of mobile networks. We will also look
into the nesting of a Mobile IPv6 (MIPv6) host in a mobile network.
In addition, we will explore the impact of MR-HA tunnel on
communications between two mobile network nodes (MNNs) on different
links of the same mobile network.
Readers might be interested to note the availability of [6] which
also discusses the problem statement of NEMO route optimization.
2.1 Sub-Optimality with NEMO Basic Support
With NEMO Basic Support, all packets sent between a mobile network
node and its correspondent node are forwarded through the MR-HA
tunnel. This results in a sub-optimal routing, also known as
"dog-leg routing", with NEMO Basic Support. This sub-optimality has
the following undesirable effects:
o Longer route leading to increased delay
Because a packet must transit from a mobile network to the home
agent then to the correspondent node, the transit time of the
packet is always higher than if the packet were to go straight
from the mobile network to the correspondent node. In the best
case, where the correspondent node resides near the home agent,
the increase in packet delay is minimal. In the worst case, where
both the mobile network and the correspondent node are located at
a point furthest away from the home agent on the Internet, the
increase in delay is tremendous. Applications such as real-time
multimedia streaming may not be able to tolerate such increase in
packet delay.
o Increased packets overhead
The encapsulation of packets in the MR-HA tunnel results in
increased packet size due to addition of an outer packet. This
reduces the bandwidth efficiency, as IPv6 header can be quite
substantial (at least 40 bytes).
o Increased processing delay
The encapsulation of packets in the MR-HA tunnel also results in
Ng, et al. Expires April 25, 2005 [Page 4]
Internet-Draft RO-Taxonomy October 2004
increased processing delay at the points of encapsulation and
decapsulation.
o Increased chances of packet fragmentation
The increased in packet size due to packet encapsulation may
increase the chances of the packet being fragmented along the
MR-HA tunnel. This can occur if there is no prior path MTU
discovery conducted, or if the MTU discovery mechanism did not
take into account the encapsulation of packets. Packets
fragmentation will result in a further increase in packet delays,
and further reduction of bandwidth efficiency.
2.2 Nesting of Mobile Networks
With nesting of mobile networks, the use of NEMO Basic Support
further amplifies the sub-optimality of routing. We call this the
amplification effect of nesting, where the (undesirable) effects of
sub-optimal routing with NEMO Basic Support is amplified with each
level of nesting of mobile networks. This is best illustrated by an
example shown in Figure 1.
HAofMR1
+-----------|---------+
HAofMR2 --| Internet |---CN
+---------------|-----+
/ Access Router
HAofMR3 |
====?========
MR1
|
====?===========?===========?===
MR5 MR2 MR6
| | |
==|======= ===?====== ======|==
LFN2 MR3 LFN3
|
==|=========?==
LFN1 MR4
|
=========
Figure 1: An example of nested Mobile Network
Using NEMO Basic Support, the flow of packets between a Local Fixed
Node LFN1 and a correspondent node CN would need to go through three
separate tunnels, illustrated in Figure 2 below.
Ng, et al. Expires April 25, 2005 [Page 5]
Internet-Draft RO-Taxonomy October 2004
----------.
--------/ /----------.
-------/ | | /-------
CN ------( - - | - - - | - - - | - - - | - - (------- LFN
HAofMR3-------\ | | \-------MR3
HAofMR2--------\ \----------MR2
HAofMR1---------MR1
Figure 2: Nesting of Bi-Directional Tunnels
This leads to the following problems:
o 'Pinball' routing
Both inbound and outbound packets will flow via the HAs of all the
MRs on their path within the NEMO, with increased latency, less
resilience and more bandwidth usage. To illustrate this effect,
Figure 3 below shows the route taken by a packet sent from LFN1 to
CN:
+--> HAofMR3 ---------------------+
| |
+----------------- HAofMR2 <--+ |
| |
+---------------+ |
| V
HAofMR1 <------+ CN
|
|
LFN1 --> MR3 --> MR2 --> MR1
Figure 3: 'Pinball' Routing
For more illustration of the pinball routing, see [7].
o Increased Packet Size
An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [8] cannot be
applied because both the source and destination (the intermediate
MR and its HA), are different hop to hop.
Ng, et al. Expires April 25, 2005 [Page 6]
Internet-Draft RO-Taxonomy October 2004
2.3 MIPv6 Host in Mobile Networks
When a MIPv6 mobile node joins a mobile network, it becomes a
visiting mobile node (VMN) of the mobile network. Packets sent to
and from the visiting mobile node will have to be routed not only to
the home agent of the visiting mobile node, but also to the home
agent of the mobile router in the mobile network. This suffers the
same amplification effect of nested mobile router mentioned in
Section 2.2.
In addition, although Mobile IPv6 [2] allows a mobile host to perform
route optimization with its correspondent node to avoid tunneling
with its home agent, the "optimized" route is no longer optimized
when the mobile host is attached to a mobile network. This is
because the route between the mobile host and its correspondent node
is subjected to the sub-optimality introduced by the MR-HA tunnel.
Interested readers may refer to [7] for examples of how the routes
will appear with nesting of MIPv6 hosts in mobile networks.
2.4 Communications within a Mobile Networks
The reliance on the MR-HA tunnel has its implications on MNNs in a
nested mobile network communicating with each other. Let us consider
the previous example illustrated in Figure 1. Suppose LFN1 and LFN2
are communicating with each other. With NEMO Basic Support, a packet
sent from LFN1 to LFN2 will follow the path of: LFN1 -> MR3 -> MR2 ->
MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 ->
MR5 -> LFN2. A round-about trip indeed where the direct path would
be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2.
The consequences of increase packet delay and packet size have been
discussed in previous sub-sections. Here, there is an additional
effect that is undesirable: should MR1 loses its connection to the
global Internet, LFN1 and LFN2 can no longer communicates with each
other, even though the direct path from LFN1 to LFN2 is unaffected!
Ng, et al. Expires April 25, 2005 [Page 7]
Internet-Draft RO-Taxonomy October 2004
3. Solution Space of NEMO Route Optimization
To address the problems discussed in Section 2, one can incorporate
route optimization into NEMO. This is also known as the NEMO
Extended Support. Although a standardized NEMO Extended Support has
yet materialize, one can expect it to show some of the following
benefits:
o Shorter Delay
Route optimization involves the selection and utilization of a
shorter (or faster) route to be taken for traffic between a mobile
network node and correspondent node. Hence a major benefit of
route optimization should be shorter delay experiences by the data
traffic between the two end nodes. This may possibly in turn
leads to better overall Quality of Services characteristics, such
as reduced jitter and packet loss.
o Reduced Consumption of Overall Network Resources
Through the selection of a shorter route, the total link
utilization for all links used by traffic between the two end
nodes should be much lower than that used if route optimization is
not carried out. This would result in a lighter network load with
reduced congestion.
o Less Susceptibility to Link Failure
An optimized route would conceivably utilize a lesser number of
links between the two end nodes. Hence, the probability of
connectivity loss due to a single point of failure at a link
should be lower as compared to the longer non-optimized route.
o Greater Data Efficiency
Depending on the actual solution for NEMO Extended Support, the
data packets exchanged between the two end nodes may not require
as many levels of encapsulation as required by NEMO Basic Support.
This would mean less packet overheads, and higher data efficiency.
There are multiple proposals for providing various forms of route
optimizations for NEMO (see Appendix A). In the following
sub-sections, we describe the solution space of route optimization by
listing different types of approach to route optimization. Readers
might be interested to take note of a route optimization model
described in [9] which describes route optimization model based on
the variations of tunnel end-points.
Ng, et al. Expires April 25, 2005 [Page 8]
Internet-Draft RO-Taxonomy October 2004
3.1 MR-to-CN Optimization
o Binding Update with Network Prefix
A straight-forward approach to route optimization is in NEMO is
for the mobile router to attempt route optimization with
correspondent node. This can be viewed as a logical extension to
NEMO Basic Support, where the mobile router would send binding
updates to the correspondent node containing one or more Mobile
Network Prefix option. The correspondent node having received the
binding update, can then set up a bi-directional tunnel with the
mobile router at the current care-of address of the mobile router,
and inject a route to its routing table so that packets destined
for addresses in the mobile network prefix will be routed through
the bi-directional tunnel.
This approach is particularly useful when a lot of MNNs in a
mobile network is communicating with a few corresponding nodes.
In such cases, a single binding update can optimize the routes of
many flows between the correspondent node and the MNNs.
o MR as a Proxy
A somewhat similar approach is for the mobile router to act as a
"proxy" for the MNNs in its mobile network. In this case, The MR
uses standard MIPv6 route optimization procedure to bind the
address of a MNN to its care-of address. This has the advantage
of keeping the implementations of MNNs and correspondent nodes
unchanged, and can be done by having the mobile router to perform
the following steps:
* determining when to perform RO (eg. by the flow packet count)
* sending CoTI and HoTI on behalf of the MNN
* receiving CoT (trivial, since it is addressed to the MR)
* intercepting the HoT (which requires inspection of the packets
addressed to the MNN)
* sending the BU and receiving the BA on behalf of MNN
* inserting the Home Address Option in packets sent by the MNN
* removing the type 2 routing header in packets sent to the MNN
* adjusting various ICMP packets to account for the modification
it performs
Ng, et al. Expires April 25, 2005 [Page 9]
Internet-Draft RO-Taxonomy October 2004
3.2 Infrastructure Optimization
There are two known approaches to achieve infrastructure
optimization. The first approach involves the introduction of an
entity known as a correspondent-side router (C-side Router), or
sometimes known simply as a correspondent router (CR) within the
routing infrastructure. As long as the correspondent router is
located "closer" to the correspondent node than the home agent of the
mobile router, the route between MNN and the correspondent node can
be said to have optimized. This is illustrated in Figure 4.
************************** HAofMR
* #*#
* #*# +---------------------+
CN #*# | LEGEND |
o #*# +---------------------+
o ############### #*# | #: Tunnel |
CR ooooooooooooooo MR | *: NEMO Basic route |
############### | | o: Optimized route |
MNN +---------------------+
Figure 4: Infrastructure Optimization
This form of optimization can take place independently for the 2
directions of the traffic:
o From MNN to CN
The mobile router locates the correspondent router, establishes a
tunnel with that correspondent router and sets a route to the
correspondent node via the correspondent router over the tunnel.
After this, traffic to the correspondent node does not flow
through the home agent anymore.
o From CN to MNN
The correspondent router is on the path of the traffic from the
correspondent node to the home agent. In addition, it has an
established tunnel with the current care-of address of the mobile
router and is aware of the mobile network prefix(es) managed by
the mobile router. The correspondent router can thus intercept
packets going to the mobile network, and forward them to the
mobile router over the established tunnel.
The advantage of this approach is that no additional functionality is
required for the correspondent node and mobile network nodes.
The second approach is to have optimizations carried out fully in
Ng, et al. Expires April 25, 2005 [Page 10]
Internet-Draft RO-Taxonomy October 2004
infrastructure. One example is to make use of mobile anchor points
(MAP) in HMIPv6 [10] to optimize routes between themselves. Another
example is to make use of the global HAHA protocol [11]. In this
case, proxy home agents are distributed in the infrastructure and
mobile routers bind to the closest proxy. The proxy performs, in
turn, a primary binding with a real home agent for that mobile
router. Then, the proxy might establish secondary bindings with
other home agents or proxies in the infrastructure, in order to
improve the end-to-end path. In this case, the proxies discover each
other, establish a tunnel and exchange the relevant mobile network
prefix information in the form of explicit prefix routes. There is
no need for return routability test or its like since the security is
built in the infrastructure, one way or an other, and the proxies
belong to the infrastructure.
3.3 Nested Tunnels Optimization
Nested tunnels optimization is targeted at nested mobile networks,
where there will be multiple levels of MR-HA tunnels with NEMO Basic
Support. Such a solution will seek to minimize the number of
tunnels, possibly by collapsing the amount of tunnels required
through dome form of signaling between the mobile routers and home
agents. This ameliorate the amplification effect of tunnel nesting,
and at best, the performance of a nested mobile network will be the
same as though there were no nesting of mobile networks.
There have been various proposals on nested tunnels optimization, and
we can model them according to:
o Sending Information of Upstream Mobile Routers
This involves sending information on upstream mobile router(s) to
the home agent of a nested mobile router, thereby enabling the
home agent to forward tunneled packets directly to the nested
mobile router via the upstream mobile router(s), skipping the home
agents of upstream mobile router(s). This usually involves the
use of a routing header to route packets through the upstream
mobile router(s).
The information of upstream mobile router (for simplicity, we
refer to it as "upstream information") may contain information on
the entire chain of upstream mobile routers, or it may only
contain information on the immediate parent mobile router. For
the former, the home agent can build a multihop routing header
from a single transmission of the information. For the latter,
each upstream mobile router may have to send binding update to the
home agent of the nested mobile router, thereby enabling the home
agent of the nested mobile router to build a multihop routing
Ng, et al. Expires April 25, 2005 [Page 11]
Internet-Draft RO-Taxonomy October 2004
header recursively.
o Prefix Delegation
An alternative approach to nested tunnels optimization is to use
prefix delegation. Here, each mobile router in a nested mobile
network is delegated a mobile network prefix from the access
router using DHCP Prefix Delegation [12]. Each mobile router also
autoconfigures its care-of address from this delegated prefix. In
this way, the care-of addresses of each mobile router are all from
an aggregatable address space starting from the access router.
This may be used to eliminate any nesting of tunnels. It may also
be used to achieve MIPv6-over-NEMO optimization (see Section 3.4)
if MIPv6 hosts autoconfigure their care-of addresses from the
prefix as well.
o Mobile Aggregation
This model applies to a category of problems where the mobile
networks share a same administration and consistently move
together (e.g. a fleet at sea). In this model, there is a
cascade of home agents. The main home agent is fixed in the
infrastructure, and advertises an aggregated view of all the
mobile networks. This aggregation is actually divided over a
number of mobile routers, the root-MRs. The root-MRs subdivide
some of their address space to the other mobile routers forming
their fleet, for which they are home agent. As home agents, the
root-MRs terminate tunnels from the inside of the mobile network.
As mobile router, they also terminate their home tunnels. As
routers, they forward packets between the 2 tunnels.
3.4 MIPv6-over-NEMO Optimization
MIPv6-over-NEMO optimization involves providing optimization for a
visiting mobile node within a mobile network. There are two aspects
to MIPv6-over-NEMO optimization:
o Nested Tunnels
This aims to reduce the amplification effect of nested tunnels due
to the nesting of the tunnel between the visiting mobile node and
its home agent within the tunnel between the mobile router of the
mobile network and the home agent of the mobile router.
This is very similar to "Nested Tunnels Optimization" described in
Section 3.3. Thus, a possible approach is to extend the solution
for nested tunnels optimization to visiting mobile node as well.
Ng, et al. Expires April 25, 2005 [Page 12]
Internet-Draft RO-Taxonomy October 2004
o MIPv6 Route Optimization
This aims to remove the sub-optimality of a MR-HA tunnel from the
MIPv6 route optimization established between a visiting mobile
node and correspondent node. One approach is to simply extend the
solution for nested tunnels optimization to correspondent node.
Another (arguably "evil") approach is for the mobile router to
"play some trick" to the MIPv6 route optimization, such as
altering messages exchanged during the return routability
procedure between the visiting mobile node and correspondent node,
so that packets sent from correspondent node to the visiting
mobile node will be routed to the care-of address of the mobile
router once route optimization is established (see Section 3.1:
"MR as a Proxy"). Alternatively, the mobile router can perform
return routability procedure on behalf of the visiting mobile
node. This would most likely require some signaling protocol
between the visiting mobile node and the mobile router, but may be
able to keep the functionality of the correspondent node
unchanged.
3.5 Intra-NEMO Optimization
A route optimization solution may seek to improve the communications
between two mobile network nodes within a nested mobile network. An
example will be the optimization of packets route taken between LFN1
and LFN2 of Figure 1.
One may be able to extend a well-designed solution for MR-to-CN
optimization to provide Intra-NEMO optimization, where, for example
in Figure 1, LFN1 is treated as a correspondent node in the view of
MR5, and LFN2 is treated as a correspondent node in the view of MR3.
Another possibility is for the infrastructure optimization technique
to be applied here. Using the same example of communication between
LFN1 and LFN2, MR3 may treat MR5 as a correspondent router for LFN2,
and MR5 treats MR3 as a correspondent router for LFN1.
Ng, et al. Expires April 25, 2005 [Page 13]
Internet-Draft RO-Taxonomy October 2004
4. Analysis of Solution Space
In this section, we present an analysis of the solution space.
First, we discuss the general issues that will be faced by a NEMO
Extended Support solution in Section 4.1. Then, we explore deeper
into specific types of route optimization solutions in Section 4.2.
4.1 General Considerations of RO Solution
Although route optimization, or NEMO Extended Support, can bring
benefits as described in previous section, it does so with some
tradeoffs. The actual type and degree of tradeoffs depend greatly on
the solution; however, in general, one would expect the costs
described in the following sub-sections to be incurred.
4.1.1 Additional Signaling Overhead
The nodes involved in performing route optimization would be expected
to exchange additional signaling information in order to establish
route optimization. The cost of such signaling may be high,
depending on the actual solution. Such a cost may scale to
unacceptable height when the number of mobile network nodes and/or
correspondent nodes is increased.
This signaling overhead is often in the form of binding update sent
to home agents or correspondent nodes. One issue that may impact
route optimization solution is known as the phenomenon of "Binding
Update Storm". This occurs when a change in point of attachment of
the mobile networks is accompanied with a sudden burst of binding
update messages being generated, resulting in temporary congestion,
packet delays or even packet lost.
There has been argument that binding update storm may not be as
significant as it seems. For instance, consider a mobile network
where mobile network nodes is receiving x video stream at 25 packets
per seconds. On the average, the mobile network is handling a total
traffic of 25*x packets per second. Assuming one binding update has
to be sent for each video stream server, a change in point of
attachment would result in at most 6*x signaling messages (if we
include the return routability procedure messages and a binding
acknowledgment). Thus the signaling overhead is small compared to
the normal data traffic that the mobile network is handling, and
hence the effect of binding update storm is small. On the other
hand, if the normal data rate is small, the effect of binding update
storm may have a greater impact. From this discussion, it appears
that the significance of binding update storm may depend on the
application type (eg. high or low data rate, tolerance on packets
delay, etc).
Ng, et al. Expires April 25, 2005 [Page 14]
Internet-Draft RO-Taxonomy October 2004
It is also possible to further moderate the effect of Binding Update
Storm by having some sort of "exponential back-off" mechanism in
place for the sending of binding updates. Such a scheme aims to
spread the burst of binding update transmissions over a longer period
of time, thereby reducing possibility of congestion and packet drops.
4.1.2 Increased Protocol Complexity
Some nodes will be required to have additional functionalities in
order to incorporate NEMO Extended Support. This increases the node
complexity. It may not be feasible to implement new functionalities
on legacy nodes. If such nodes are mobile, this may prove to be a
significant cost due to the limited memory resources such devices
usually have.
Coupled with the increased in protocol complexity, nodes that are
involved in the establishment and maintenance of route optimization
will have to bear increased processing load. If such nodes are
mobile, this may prove to be a significant cost due to the limited
power and processing resources such devices usually have.
4.1.3 Mobility Awareness
One advantage of NEMO Basic Support is that the correspondent nodes
and mobile network nodes need not be aware of the actual location and
mobility of the mobile network. With route optimization, it might be
necessary to reveal the current care-of address and any change of
point of attachment of the mobile router to other nodes, such as the
mobile network nodes or correspondent node. This may mean a tradeoff
between location privacy and route optimization. In MIPv6, the
mobile node can decide whether or not to perform route optimization
with a given correspondent node. Thus, the mobile node is in control
of whether to trade location privacy for an optimized route. It will
be desirable that such control is also available in a route optimized
solution of NEMO should the solution contain the same tradeoff.
However, for solutions where route optimization decision is made by
mobile router, it will be difficult for mobile network nodes to
control the decision of having this tradeoff.
4.1.4 New Functionalities
All route optimization approaches require some sort of new
functionalities be implemented on some nodes. In general, it is
desirable to keep the number of nodes that require new
functionalities to be kept as small as possible. This allows for
easier adoption of the solution, and also creates less impact on the
existing infrastructure.
Ng, et al. Expires April 25, 2005 [Page 15]
Internet-Draft RO-Taxonomy October 2004
In addition, if route optimization solution requires new
functionalities on the part of some other nodes other than nodes
within the mobile network, a mechanism for other nodes (such as
mobile router) to detect if support for the new functionalities are
available should also be provided. Furthermore, it is desirable for
there to be a graceful fall back procedure the required
functionalities are unavailable.
Possible nodes that are required to be changed includes:
o Local Fixed Nodes
It is generally undesirable to affect local fixed nodes. However,
some approaches require mobile network nodes to implement new
functionalities to enjoy benefits of route optimizations.
o Visiting Mobile Nodes
Visiting mobile nodes in general should already have implemented
MIPv6 functionalities, and since MIPv6 is a relatively new
standard, there is still a considerable window to allow mobile
devices to implement new functionalities.
o Mobile Routers
It is expected for mobile routers to implement new functionalities
in order to enable route optimizations.
o Access Routers
Some approaches require access routers, or nodes in the access
network to implement some new functionalities. A clear example
will be prefix delegation approach.
o Home Agents
Although it is likely that vendors and operators would not mind
having new functionalities in home agents, few route optimizations
approaches would impact the home agents.
o Correspondent Nodes
It is generally undesirable for correspondent nodes to be required
to implement new functionalities.
o Correspondent Routers
Correspondent routers are new entity to be deployed in the
Ng, et al. Expires April 25, 2005 [Page 16]
Internet-Draft RO-Taxonomy October 2004
infrastructure. Such addition would generally cause the least
disruption to the existing routing infrastructure.
4.1.5 Other Considerations
There are other considerations when analyzing the route optimization
solution space. These may not be a 'tradeoff" so to speak, but are
beneficial to keep in mind when considering a route optimization
solutions.
o Compatibility with NEMO Basic Support
It will be beneficial to vendors if a route optimized solution for
NEMO is compatible with NEMO Basic Support. This reduces the
complexity and achieves greater reuse of existing functionalities.
o In-Plane Signaling versus Off-Plane Signaling
There is also considerations of whether route optimization
signaling should be done in-plane and off-plane. In-plane
signaling involves embedding signaling information into headers of
data packets (a good example would be the Reverse Routing Header
[13]). Off-plane signaling involves separating the signaling
packets from the data packets. Most proposals involving sending
of binding updates fall within this category.
4.2 Specific Types of RO Solution
Many of the tradeoffs discussed previously in Section 4.2 are
dependent on the actual route optimization approach. In the
following sub-sections, we will explore deeper into the issues
involved in each specific type of route optimization approach.
4.2.1 MR-to-CN Optimization
One approach of MR-to-CN optimization involves the mobile router
sending binding update messages with mobile network prefix
information to the correspondent node. This raised several issues:
o Security Considerations
With mobile router sending binding update containing network
prefix information to correspondent node, there is a question on
the additional risk imposed on the correspondent node. Although
return routability procedure allows the correspondent node to
Ng, et al. Expires April 25, 2005 [Page 17]
Internet-Draft RO-Taxonomy October 2004
verify that the care-of and home addresses of the mobile router
are indeed collocated, it does not allow the correspondent node to
verify the validity of the network prefix. If the correspondent
node accepts the binding without verification, it will be exposed
to a class of attacks where the attacker tricks the correspondent
node into forwarding packets destined for a mobile network to the
attacker.
Hence, MR-to-CN optimization would most likely require an extended
return routability procedure to be developed for correspondent
node to authenticate the validity of the mobile network prefix.
This require additional functionality on the correspondent node,
and a mechanism must be provided for the mobile router to check if
the correspondent node has such functionality implemented.
o Mobility Awareness
By sending binding update with mobile network prefix to the
correspondent node, the mobile router is effectively revealing the
location and mobility of the mobile network to the correspondent
node. Hence this is a case of trading location privacy for route
optimization. However, since route optimization in this case is
initiated by the mobile router, the mobile network nodes may not
have an influence to the decision of whether the tradeoff should
be made.
o Binding Update Storm
If the mobile network nodes in a mobile network are communicating
with a lot of correspondent nodes, whenever the mobile router
changes its point of attachment, it needs to send out a large
number of binding updates to correspondent nodes. This is further
worsen by the fact that the mobile router has to perform the
return routability procedure prior to sending binding updates.
Another approach involves the mobile router acting as a proxy for
MNNs behind it. This has the following issues:
o Security Considerations
Having the mobile router alters packets (such as inserting home
address destination option and removing type 2 routing header)
raise considerable security concerns. Such a scheme may break
existing IPSec protocols, and cause packets to be dropped.
o Complexity
This also greatly increases the complexity of a mobile router, as
Ng, et al. Expires April 25, 2005 [Page 18]
Internet-Draft RO-Taxonomy October 2004
it needs to look beyond the standard IPv6 headers for
ingress/egress packets, and performs hacks appropriately. The
mobile router is also required to maintain some form of state
information for each pair of MNN and CN, resulting in scaling
issues. This scheme also places all processing burden on the
mobile router, which may be undesirable for mobile device with
limited power and processing resources.
o Binding Update Storm
Whenever the mobile router changes its point of attachment, it
needs to perform binding updates with every correspondent node.
Some CN selection scheme may be required to moderate the effect of
binding update storm and processing burden on the mobile router.
o A Hack of Existing Protocol
There have been comments on the NEMO WG mailing list that such an
approach is essentially a hack of the existing return routability
procedure. The disadvantages of it being a hack is that firstly a
change/extension in the current return routability procedure would
render this hack broken, and secondly, it might be very difficult
to accommodate other protocols that are not aware of such hacks
(IPSec being an excellent example).
o Nesting of Mobile Routers
Should one mobile router be attached to another mobile router, it
is unclear how this solution will work if both mobile routers try
to perform route optimization on behalf of the same mobile network
node. Using Figure 1 as an example, if MR5 perform route
optimization on behalf of LFN2, and then MR1 again tries to act as
a proxy to MR5, the results might be messy without any
co-ordination between these mobile routers.
4.2.2 Infrastructure Optimization
An infrastructure optimization approach using correspondent routers
may face the following issues:
o Security Considerations
The first security-related issue is how do the mobile router
verify the validity of a correspondent router. In other words,
the mobile router needs some mechanism to ascertain that the
correspondent router is indeed a valid correspondent router
capable of forwarding packets to and from the correspondent node.
Ng, et al. Expires April 25, 2005 [Page 19]
A second security-related issue is how can the correspondent
router verify the validity of a mobile router. In other words,
the correspondent router needs some mechanism to ascertain that
the mobile router is indeed managing the mobile network prefix it
claims to be managing. This is related to the issues discussed in
Section 4.2.1.
o Mobility Awareness
Infrastructure optimization requires the correspondent router to
be informed of the location and mobility of the mobile network.
Correspondent nodes and mobile network nodes remain ignorant of
the mobile network's mobility.
o Discovery of Correspondent Routers
How should a mobile router discover a correspondent router given a
particular correspondent node? The discovery mechanism may have
impact on the security issue discussed earlier.
4.2.3 Nested Tunnels Optimization
Nested tunnels optimization usually involves the nested mobile router
sending information of upstream mobile router(s).
o Security Considerations
One issue for consideration is whether the home agent should trust
the upstream information supplied by the nested mobile router. If
the upstream information falsely points to a victim node, the home
agent may unconsciously flood the victim with packets intended for
the nested mobile network.
This risk can be minimized if the upstream information is
protected by security association between the nested mobile router
and its home agent (e.g. the upstream information may be
transmitted in a binding update that is protected from tampering).
However, this does not protect against a malicious mobile router
intentionally supplying false upstream information to its home
agent, with the intent of launching a flooding attack against a
victim node.
o Mobility Awareness
Usually, nested tunnels optimization involves the nested mobile
router sending upstream information to its home agent. This
implies that the upstream mobile router will have to reveal some
information to sub-mobile routers. Such information may reveal
the location and mobility of the upstream mobile router.
Ng, et al. Expires April 25, 2005 [Page 20]
Internet-Draft RO-Taxonomy October 2004
o Binding Update Storm
Depending on the specifics of a solution for nested tunnels
optimization, the upstream information may be the care-of address
of the upstream mobile router. This will leads to the a burst of
binding update messages whenever an upstream mobile router changes
its point of attachment, since all its sub-MRs must send binding
updates to their home agents to update the new upstream
information.
o Complexity
Sending of upstream information for nested tunnels optimization
requires the home agent to store the upstream information in order
to build a routing header. Complexity of the home agent is
further increased if the upstream information is sent individually
by all upstream mobile routers, requiring the home agent to
recursively build a routing header.
Alternatively, a prefix delegation approach may be used to achieve
nested tunnel optimization by eliminating the need for nesting. This
approach may face the following issues:
o Protocol Complexity
This approach requires the access router (or some other entity
within the access network) to possess prefix delegation
functionality, and also maintains information on what prefix is
delegated to which node.
o Binding Update Storm
A change in the point of attachment of the root mobile router will
require every nested mobile router (and possibly visiting mobile
nodes) to change their care-of addresses and delegated prefixes.
These will cause a burst of binding update and prefix delegation
activities where every mobile routers and visiting mobile nodes
start sending binding updates to their home agents and possibly
correspondent nodes.
4.2.4 MIPv6-over-NEMO Optimization
If MIPv6 route optimization is not used, the optimization for
MIPv6-over-NEMO is very similar to nested tunnels optimization, where
the MIPv6 mobile node acts like a visiting mobile router. The
analysis of such optimization is thus similar to those discussed in
Section 4.2.3, and hence will not be repeated here. In this section,
Ng, et al. Expires April 25, 2005 [Page 21]
Internet-Draft RO-Taxonomy October 2004
we explore the issues if MIPv6 route optimization is used.
As described in Section 3.4, MIPv6-over-NEMO optimization can be
achieved using various approaches. One approach involves including
upstream information (see nested tunnels optimization) in the binding
update sent from the visiting mobile node to the correspondent node.
This approach has the following considerations:
o Security Considerations
A security-related issue is how can the correspondent node verify
the validity of the supplied upstream information. See also
Section 4.2.3.
o Mobility Awareness
The visiting mobile node will need to acquire the upstream
information, most likely including the mobility and location
information of the upstream mobile routers.
On the other hand, the mobile router can perform some hacks on the
return routability messages exchanged between the visiting mobile
node and correspondent node to achieve MIPv6-over-NEMO optimization.
This, is generally undesirable due to:
o Security Considerations
Such a scheme may break existing security related protocols, as it
requires the mobile router to make changes to contents of a packet
that is not originated by the mobile router.
Alternatively, the mobile router can perform return routability
procedure on behalf of the visiting mobile node. Here the issues
are:
o Security Considerations
Such a scheme require the visiting mobile node to place
considerable trust on the mobile router, as the mobility
management key is now transfered to the mobile router.
o Mobility Awareness
This approach aims to keep the functionality of the correspondent
node to be identical as those required by MIPv6 route
optimization. The expense will be that a new form of signaling
between the visiting mobile node and mobile router would most
likely be required.
Ng, et al. Expires April 25, 2005 [Page 22]
Internet-Draft RO-Taxonomy October 2004
o Processing Burden
This approach also increases the processing burden of the mobile
router, as it needs to maintain information necessary for route
optimization to work for every correspondent node that is
communicating with each visiting mobile node. This may not scale
very well when one consider, for example, a train network, where
there are hundreds of visiting mobile nodes in one mobile network.
4.2.5 Intra-NEMO Optimization
As mentioned in Section 3.5, it is likely that any MR-to-CN
optimization may be able to fulfill the role of an intra-NEMO
optimization. Such solutions will face the same issues as described
in Section 4.2.1, as well as the following:
o Reliance on Outside Infrastructure
Most MR-to-CN optimization rely on the operations of home agent in
one way or another. For instance, the return routability
procedure requires a Home Test (HoT) or Home Test Init (HoTI)
messages be forwarded by the home agent. This means that should
the path to the Internet be broken, such optimization techniques
can no longer be used (and thus LFN1 can no longer communicates
with LFN2 in the example of Figure 1).
Ng, et al. Expires April 25, 2005 [Page 23]
Internet-Draft RO-Taxonomy October 2004
5. Conclusion
The problem space of route optimization in the NEMO context is
multifold and can be split into several work areas. It will be
critical, though, that the solution to a given piece of the puzzle be
compatible and integrate smoothly with the others.
This memo explored into various problems of sub-optimality of NEMO
Basic Support, and discussed different aspects of a route optimized
solution in NEMO. The intent of this document is to trigger fruitful
discussions that in turn will enhance our common understanding of the
route optimization problem and solution space.
Ng, et al. Expires April 25, 2005 [Page 24]
Internet-Draft RO-Taxonomy October 2004
6. Acknowledgments
The authors wish to thank: Greg Daley, Thierry Ernst, Erik Nordmark,
T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa
and Patrick Wetterwald for their various contributions. In addition,
the authors would also like to extend their heart-felt gratitude to
Marco Molteni, who was a co-author for the earlier versions of this
document.
7 References
[1] Devarapalli, V., "Network Mobility (NEMO) Basic Support
Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
June 2004.
[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.
[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-01 (work in progress), February
2004.
[5] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-02 (work in progress), February
2004.
[6] Zhao, F., Wu, F. and S. Jung, "NEMO Route Optimization Problem
Statement, Requirements and Evaluation Considerations",
draft-zhao-nemo-ro-ps-00 (work in progress), October 2004.
[7] Watari, M. and T. Ernst, "Route Optimization with Nested
Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in
progress), October 2004.
[8] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6",
draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
November 2001.
[9] Na, J., "Generic Route Optimization Model for NEMO Extended
Support", draft-na-nemo-gen-ro-model-00 (work in progress),
July 2004.
[10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
Ng, et al. Expires April 25, 2005 [Page 25]
Internet-Draft RO-Taxonomy October 2004
draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004.
[11] Thubert, P., "Global HA to HA protocol",
draft-thubert-nemo-global-haha-00 (work in progress), October
2004.
[12] Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6",
draft-troan-dhcpv6-opt-prefix-delegation-01 (work in progress),
May 2002.
[13] 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.
[14] Ng, C. and J. Hirano, "Extending Return Routability Procedure
for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
progress), October 2004.
[15] Bernardos, C., Bagnulo, M. and M. Calderon, "MIRON: MIPv6 Route
Optimization for NEMO", ASWN 2004, Online:
http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf.
[16] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization
with Access Router Option",
draft-ng-nemo-access-router-option-01 (work in progress), July
2004.
[17] Na, J., "Route Optimization Scheme based on Path Control
Header", draft-na-nemo-path-control-header-00 (work in
progress), April 2004.
[18] Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
draft-wakikawa-nemo-orc-00 (work in progress), July 2004.
[19] Na, J., "Secure Nested Tunnels Optimization using Nested Path
Information", draft-na-nemo-nested-path-info-00 (work in
progress), September 2003.
[20] Kang, H., "Route Optimization for Mobile Network by Using
Bi-directional Between Home Agent and Top Level Mobile
Router", draft-hkang-nemo-ro-tlmr-00 (work in progress), June
2003.
[21] Ohnishi, H., "HMIP based Route optimization method in a mobile
network", draft-ohnishi-nemo-ro-hmip-00 (work in progress),
October 2003.
Ng, et al. Expires April 25, 2005 [Page 26]
Internet-Draft RO-Taxonomy October 2004
[22] Paakkonen, P. and J. Latvakoski, "Mobile Network Prefix
Delegation extension for Mobile IPv6",
draft-paakkonen-nemo-prefix-delegation-00 (work in progress),
March 2003.
[23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
draft-droms-nemo-dhcpv6-pd-01 (work in progress), February
2004.
[24] Lee, K., "Route Optimization for Mobile Nodes in Mobile Network
based on Prefix Delegation", draft-leekj-nemo-ro-pd-02 (work
in progress), February 2004.
[25] Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes
in Mobile Network", draft-jeong-nemo-ro-ndproxy-02 (work in
progress), February 2004.
[26] Perera, E., "Extended Network Mobility Support",
draft-perera-nemo-extended-00 (work in progress), July 2003.
Authors' Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate
Singapore 534415
SG
Phone: +65 65505420
EMail: cwng@psl.com.sg
Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.com
Ng, et al. Expires April 25, 2005 [Page 27]
Internet-Draft RO-Taxonomy October 2004
Hiroyuki Ohnishi
NTT network service systems laboratories, NTT cooperation
9-11, Midori-Cho 3-Chome
Musashino-shi
Tokyo 180-8585
JAPAN
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
Paik, Eun Kyoung
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
EMail: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Ng, et al. Expires April 25, 2005 [Page 28]
Internet-Draft RO-Taxonomy October 2004
Appendix A. Proposed Route Optimizations
Here, we attempt to list the numerous proposed solutions according to
the solution space defined in Section 3. Although we made effort in
listing all possible solutions, sincere apology is extended to
authors of solutions that we might have missed out.
A.1 MR-to-CN Optimizations
Most MR-to-CN optimizations proposals are implicitly achieved by
sending mobile network prefixes to correspondent nodes. The Return
Routability procedure with Network Prefix (RRNP) [14] proposed an
extension to return routability procedure for verifying the validity
of mobile network prefixes.
One approach that uses the mobile router as a proxy for establishing
route optimization on behalf of mobile network nodes can be found in
[15].
In addition, various nested tunnel optimizations proposals (see
Appendix A.3) can also be extended to correspondent node, thus
enabling the MR-to-CN optimizations. Example includes the Reverse
Routing Header (RRH) [13], Access Router Option (ARO) [16].
A.2 Infrastructure Optimizations
All known infrastructure optimization proposals defines the entity
known as correspondent router capable of terminating bi-directional
tunnels from mobile routers on behalf of correspondent nodes, thereby
achieving route optimization. The difference between these proposals
is mainly the way correspondent routers are discovered. Proposals
include:
o Path Control Header (PCH) [17]
The PCH approach requires the home agent to piggyback a Path
Control Header on the packet when forwarding packets arriving from
a bi-directional tunnel to a correspondent node. Because PCH is a
hop-by-hop option header, all intermediate routers lying between
the home agent and the correspondent node will inspect the PCH.
If a correspondent router exists among these intermediate router,
it can contact the mobile router (identified in the PCH) and
establish a optimized tunnel with the mobile router.
o Optimized Routing Cache (ORC) [18]
The ORC approach defines the functionality of a correspondent
router able to terminate bi-directional tunnels from mobile
Ng, et al. Expires April 25, 2005 [Page 29]
Internet-Draft RO-Taxonomy October 2004
routers. Mobile routers discover correspondent routers by sending
a query message to a multicast address corresponding to "all
correspondent router" address. The query message contains the
address of the correspondent node for which the mobile router
wishes to send packets to. The correspondent router managing the
network within which the correspondent node resides will responds
to this query. The proposal also suggest correspondent router to
inform mobile routers the prefix information of the network it is
capable of managing, so that any other traffic flows that
originate and end at the mobile network and the network the
correspondent router is managing can also enjoy route
optimization.
A.3 Nested Tunnel Optimizations
Many proposed solutions for NEMO Extended Support targets the nested
tunnel optimization. Most of these involves sending of upstream
information to the home agent of a nested mobile router, including
o Reverse Routing Header (RRH) [13]
The RRH approach avoids the multiple encapsulation of the traffic
but maintains the home tunnel of the first mobile router on the
egress path. The first mobile router on the way out (egress
direction) encapsulates the packet over its reverse tunnel, using
a form of Record Route header, the RRH.
The upstream mobile routers simply swap their care-of address and
the source of the packet, saving the original source in the RRH.
The home agent transforms the RRH in a Routing Header to perform
source routing across the nested mobile network, along the ingress
path to the target mobile router.
o Access Router Option (ARO) [16]
The ARO approach is somewhat similar to the RRH in that only the
home tunnel of the first nested mobile router in the egress path
is maintained. This is done by having the nested mobile router to
send an ARO in Binding Update to inform its home agent the address
of its access router (i.e. an upstream mobile router). Using
this information, the home agent can build a Routing Header to
source-route a packet to the nested mobile router within in a
nested mobile network. Upstream mobile routers can also send
binding update messages to the home agent of the nested mobile
router, thus allowing a complete routing header be built
recursively by the home agent.
Ng, et al. Expires April 25, 2005 [Page 30]
Internet-Draft RO-Taxonomy October 2004
o Nested Path Info (NPI) [19]
The NPI approach is somewhat similar to the ARO approach, except
that instead of sending only the home address of the upstream
mobile router to its home agent, a nested mobile router send a
nested information on the care-of addresses of all upstream mobile
routers. Using this information, the home agent can build a
Routing Header to source-route a packet to the nested mobile
router within in a nested mobile network.
o Top Level Mobile Router (TLMR) [20]
In TLMR, each visiting mobile router obtains the address of the
root-MR through router advertisement messages. This information
is passed to its home agent in a binding update message. The
visiting mobile router also registers with the root-MR. With
these registrations, the root-MR maintains a topology of the
mobile network. In addition, the root MR also establish tunnels
with the home agents of every visiting mobile router. This way,
packet to and from each nested mobile network will be relayed
through the root-MR, through an additional tunnel between the
root-MR and the home agent of the nested mobile network.
o Hierarchical Mobile IP (HMIP) [21]
This approach proposes an adaptation of HMIPv6 [10] for NEMO.
Here, information on the root-MR (acting as a Mobile Anchor Point,
MAP) is passed to nested mobile routers in the MAP option of a
router advertisement. Nested mobile routers then register their
regional and local care-of address with the root-MR. Packets are
then transfered to and from a nested mobile router through two
separate tunnels: one between the nested mobile router and the
root-MR, the other between the root-MR and the home agent of the
nested mobile router.
Other approaches that does not really require the sending of upstream
information to home agent includes:
o Prefix Delegation [22][23][24]
The prefix delegation approach is somewhat to HMIPv6 what NEMO is
to MIPv6. The Access Router of the nested structure is both a
NEMO home agent and a DHCP-PD server, for an aggregation that it
owns and advertises to the infrastructure. When visiting the
nested structure, each mobile router is delegated a mobile network
prefix from the access router using DHCP-Prefix Delegation. The
mobile router registers this delegated prefix to the access router
that is acting as a NEMO home agent. The mobile router also
Ng, et al. Expires April 25, 2005 [Page 31]
Internet-Draft RO-Taxonomy October 2004
autoconfigures an address from the delegated prefix and uses it as
a care-of address to register its own mobile network prefix(es) to
its own home agent using NEMO Basic Support. It is possible for a
mobile router to protect its own mobile network prefixes while
advertising in the clear the local prefix for other mobile routers
to roam into. This allows a strict privacy of visited and
visitors, and enables some specific policies in each mobile
router.
o Neighbor Discovery Proxy (ND-Proxy) [25]
The ND-Proxy approach achieves route optimization by having mobile
routers to act as neighbor discovery proxy. Mobile router will
configure a care-of address from the network prefix advertised by
its access router, and also relay this prefix to its subnets. As
ND-Proxy, mobile routers will also handle neighbor discovery on
behalf of visiting mobile nodes in its subnets. As such, the
entire mobile network and its access network forms a logical
multilink subnet, thus eliminating any nesting. This solution
also lends itself well to achieve MIPv6-over-NEMO optimization.
A.4 MIPv6-over-NEMO Optimizations
Some solutions proposed for nested tunnels optimization can be
extended for MIPv6-over-NEMO optimization, including Access Router
Option (ARO) [16], Top Level Mobile Router (TLMR) [20], Prefix
Delegation approaches [22][23][24], and Neighbor Discovery Proxy
(ND-Proxy) [25]. One solution that caters specifically for
MIPv6-over-NEMO optimization is:
o Extended Network Mobility Support [26]
This approach is somewhat similar to the Prefix Delegation in
which the mobile router would obtain a prefix from its access
network, and allows visiting mobile network nodes to autoconfigure
their care-of addresses from this prefix. By doing so, packets
destined to any MIPv6 node within the mobile network will not go
through the home agent of the mobile router, thereby achieving
MIPv6-over-NEMO optimization. This solution also allows the
mobile router to act as home agent for local fixed nodes and local
mobile nodes within the mobile network in an attempt to allow
these nodes to achieve route optimization (using standard MIPv6
techniques).
Ng, et al. Expires April 25, 2005 [Page 32]
Internet-Draft RO-Taxonomy October 2004
A.5 Intra-NEMO Optimizations
Currently, there are no proposals that specifically target intra-NEMO
optimization, though as explained previously, most solutions that
achieves MN-to-CN optimizations can also achieve intra-NEMO
optimization.
Ng, et al. Expires April 25, 2005 [Page 33]
Internet-Draft RO-Taxonomy 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.
Ng, et al. Expires April 25, 2005 [Page 34]