wdiff draft-thubert-nemo-ro-taxonomy-02.txt draft-thubert-nemo-ro-taxonomy-03.txt

Network
NEMO Working Group P. Thubert
Internet-Draft M. Molteni
Expires: August 15, 2004 Cisco Systems C. Ng
Internet-Draft Panasonic Singapore Labs
Expires: April 25, 2005 P. Thubert
Cisco Systems
H. Ohnishi
NTT
E. Paik
Seoul National Univ.
February 15,
KT
October 25, 2004

Taxonomy of Route Optimization models in the Nemo NEMO Context
draft-thubert-nemo-ro-taxonomy-02
draft-thubert-nemo-ro-taxonomy-03

Status of this Memo

This document is an Internet-Draft and is in full conformance with subject to all provisions
of Section 10 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 RFC2026.
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.
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 15, 2004. April 25, 2005.

Abstract

NEMO enables Mobile Networks by extending Mobile IP to support Mobile
Routers. This memo documents how the MIPv6 concept of Route
Optimization can to be adapted for NEMO

With current Network Mobility (NEMO) Basic Support, all
communications to optimize traffic routing
between nodes in a and from mobile network and their correspodnet nodes.
Different route optimizations schemes are discussed, including:

1. route optimization with corresponding nodes initiated bu mobile
routers on behalf of must go through the
MR-HA tunnel when the mobile network nodes;

2. a visiting mobile node performing MIPv6 RO over the NEMO base
protocol;

3. performing RO over the routing infrastructure involving
optimizing the is away. This results in
increased length of packet route between two routers situated near and increased packet delay. To
overcome these limitations, one might have to each
end point, instead turn to route
optimization (RO) for NEMO. This memo documents various types of end-to-end;
route optimization in NEMO, and

4. minimizing explores the number of tunnels required when there is multiple
levels benefits and tradeoffs
in different aspects of nesting. NEMO route optimization.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. MR-to-CN Problem Statement of NEMO Route Optimization . . . . . . . . . 4
2.1 Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
2.2 Nesting of Mobile Networks . . . . . . . . . . . . 3
3. MIPv6 Route Optimization over NEMO . . . . 5
2.3 MIPv6 Host in Mobile Networks . . . . . . . . . . . 4
4. Optimization within the infrastructure . . . 7
2.4 Communications within a Mobile Networks . . . . . . . . . 4
4.1 7
3. Solution Space of NEMO Route Optimization within a ISP network . . . . . . . . . . 8
3.1 MR-to-CN Optimization . 5
4.2 Correspondent Router . . . . . . . . . . . . . . . . . 9
3.2 Infrastructure Optimization . . . . 6
4.3 Distributed Anchor Routers . . . . . . . . . . . 10
3.3 Nested Tunnels Optimization . . . . . . . 7
5. Nested Mobile Network . . . . . . . . 11
3.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . 8
5.1 Nested Tunnels . . . 12
3.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 8
5.2 Route Optimization inside the Nested Mobile Network 13
4. Analysis of Solution Space . . . . . 12
6. . . . . . . . . . . . . . 14
4.1 General Considerations of RO Solution . . . . . . . . . . 14
4.1.1 Additional Signaling Overhead . . . . . . . . . . 12
6.1 Securing the protocol in nested tunnels optimization . . 14
4.1.2 Increased Protocol Complexity . . . 12
6.2 Recursive complexity in route optimization . . . . . . . . . 15
4.1.3 Mobility Awareness . 12
6.3 Mobile Access router selection . . . . . . . . . . . . . . . . 13
6.4 Mobility transparency and RO . 15
4.1.4 New Functionalities . . . . . . . . . . . . . . . . . 14
6.5 Multihoming 15
4.1.5 Other Considerations . . . . . . . . . . . . . . . . . 17
4.2 Specific Types of RO Solution . 15
7. . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements 24
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . 19 34

1. Introduction

This document assumes the reader is familiar with Mobile IPv6 defined
in

With current Network Mobility (NEMO) Basic Support [1], with the concept of Mobile Router (MR) all
communications to and with the Nemo
terminology defined from nodes in [2].

From the discussions on the mailing list, it appears that a mobile network must go through
the common
current understanding of bi-directional tunnel established between the problem space of Route Optimization
(RO), in mobile router (MR)
and its home agent (HA) when the Nemo context, mobile network is still limited.

This draft attempts away. Although
such an arrangement allows mobile network nodes (MNNs) to clarify the state of the discussion reach and
propose a taxonomy of the various aspects of
be reached by any node on the problem. We will
look at different possible types of route optimizations related Internet, there are associated
limitations which might be unacceptable for certain applications. To
substantially ameliorate these limitations, one might have to turn to
mobile network.

Firstly, the Mobile Router can initiate
route optimization with
corresponding nodes (CN) on behalf of the mobile network nodes (MNN).

Secondly, (RO) for NEMO. Here, we consider use the feasibility of having term "route
optimization" to loosely refer to any approach that optimize the
route taken by packets sent between a visiting mobile network node (VMN) performing MIPv6 RO over the NEMO base protocol.

Thirdly, we explore the prospect of performing RO over the routing
infrastructure. and
correspondent node (CN).

This involves optimizing document aims to explore limitations inherent in NEMO Basic
Support, and analyze the route between two
routers situated near possible approaches to each end point.

Lastly, route optimizations involving nested mobile networks are
explored. This involves minimizing 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 number design requirements of tunnels required
when there NEMO [5]. A point to note is multiple levels that since
this document discusses aspects of nesting.

2. MR-to-CN

This section covers the case where the Route Optimization is
performed between the MR and route optimization, the correspondent nodes which readers
may assume that a mobile network nodes (MNNs) are communicating with. This scenario is useful
when a lot of MNNs in or a mobile network host is communicating with a few
corresponding nodes. In such cases the MR only needs to send one
binding update (BU) to optimized the route between CN and a few MNNs.

A major issue with away when they
are mentioned throughout this form of optimization document, unless it is explicitly
specified that they are at home.

It is the end-to-end
principle objective of the MIPv6 Reverse Routability (RR) test is broken. The
RR test is meant this document to ensure the care-of address (CoA) and the home
address (HoA) are collocated. With need for a mobile network, when the MR
performs RO on behalf of the MNNs, the CoA route
optimization analysis in BU will be the MR's
CoA. Thus, a MNN is reachable via the CoA, but not at the CoA.

Some tricks may be performed on NEMO Working Group. To quote the fly by
charter of the MRs but it seems that
a clean MR-to-CN optimization for Nemo NEMO Working group:

"... The WG will impact the CN function.

Once we modify the CN behavior, we need to introduce work on: ... ... [an] informational document
which specifies a negotiation
from the start of the RR test detailed problem statement for route
optimization and looks at various approaches to determine the protocol. In
particular, solving this
problem. This document will look into the Mobile Node issues and tradeoffs
involved in making the CN must decide whether checking
the collocation is possible, and if not, whether a CN is willing network's movement visible to
accept the risk. If not, the some nodes,
by optionally making them "NEMO aware". The interaction between
route optimization may be limited to
triangular and IP routing MR->CN->HA->MR.

This is a major evolution from [1], since MIPv6 has no such
negotiation capability at will also be described in this time.

3. MIPv6 Route Optimization over NEMO

MIPv6 mobile nodes can move everywhere. If the user brings mobile
nodes (e.g. MIP VoIP terminal) into the vehicle that supports NEMO
function, packets destined to
document. Furthermore, security considerations for the mobile node various
approaches will have to be routed
not only to its home agent but also be considered. ..."

To such end, this document first describes the home agent problem of the mobile
router. This pattern resembles Nested NEMO case which is described route
optimization in
later section. This solution is needed to use both MIPv6 and NEMO
technologies efficiently.

When a Mobile Node visits a Mobile Network, the best Route
Optimization is obtained if the path in Section 2. Next, we explore into various
possible approaches to solving the Infrastructure is the
same as if the Mobile Network was attached at the attachment point problem of
the Mobile Router (i.e., there is not additional Tunneling route optimization in
Section 3. Following this, Section 4 discusses various issues that is
linked to NEMO).

A possible approach to a
route optimization solution might face. Finally, Section 5 concludes
this is memo. In addition, we attempt to extend the solution list various proposed
solutions for nested
mobile network route optimization in Appendix A, and classify them
according to include VMN as well. In this case, the VMN is treated as though it is an MR. This type of solution will
most likely require some extensions for a MIPv6 VMN and CN.

4. Optimization within the infrastructure

This section elaborates on cases where the space described in Section 3.

2. Problem Statement of NEMO Route Optimization is
performed within the Routing Infrastructure. This model is useful
when an ISP wants to control

In essence, the problem of route optimization procedures and
does not desire to add any functions in NEMO is to the CN eliminate
limitations, or sub-optimality, introduced by the MR in order to
achieve route optimizations bi-directional
tunnel between CN a mobile router and LFN.

In this model, both the LFN behind its home agent (also known as the MR and
MR-HA tunnel). In the Correspondent can
be MIP agnostic. The drawback is following sub-sections, we will describe the introduction
effects of Mobile Routes in
specific Routers, causing additional signaling sub-optimal routing with NEMO-Basic Support, and load to the
Routing Fabric.

The general idea is that there is a correspondent-side router (C-side
Router) in the infrastructure that is located "closer" to the CN than
the HA how they
get amplified with nesting of mobile networks. We will also look
into the MR. This C-side Router can terminate MIP on behalf nesting of
the CN.

Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent
# n #
o # n # # :== Tunnel
o # n # o :== Optimized
o # n # n :== Non-Optimized
o # n #
################################## n #
C-Side oooooooooooooooooooooooooooooooo a Mobile
Router ################################ Router
|
====Mobile Network=======

Optimization IPv6 (MIPv6) host in a mobile network.
In addition, we will explore the Infrastructure

This optimization is only valid when the path via the C-side Router
is shorter than the path via the Home Agent.

The Optimization can take place independently for the 2 directions impact of
the traffic:

Egress

The MR locates the C-side Router, establishes a MR-HA tunnel with that
Router and sets a route to the Correspondent Node via the C-side
Router over the Tunnel. After this, traffic to the Correspondent
Node does not flow through the Home Agent anymore.

Ingress

The C-side Router is on the way
communications between two mobile network nodes (MNNs) on different
links of the traffic from the
Correspondent Node same mobile network.

Readers might be interested to note the Home Agent. Also, it is aware availability of [6] which
also discusses the MR
and 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 behind the MR and establishes the
appropriate tunnel
node and route. After this, it is able to reroute
traffic to the mobile network over the tunnel to its correspondent node are forwarded through the MR.

4.1 Route Optimization within a ISP network

This form of Route Optimization provides local savings for an ISP. MR-HA
tunnel. This idea was described results in Ohnishi's Mobile Border Gateway draft. The
goal is to locate the closest (BGP) gateway for a Correspondent that
is located outside of the domain, and tunnel between the MR and that
gateway sub-optimal routing, also known as opposed to the Home Agent for that specific Correspondent.

4.2 Correspondent Router

A globally better optimization is obtained if the tunnel from the MR
is terminated closer to the destination on the Correspondent side.
"dog-leg routing", with NEMO Basic Support. This is sub-optimality has
the role of a Correspondent Router (CR).

+-------------------+ # :== Tunnel
| Autonomous System | o :== Optimized
| ----------------- | n :== Non-Optimized
| |
| |
| Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent
| | # n #
| o | # n #
| o | # n #
| o | # n #
| o | # n #
| following undesirable effects:

o | # n #
| #################################### ?
| CR oooooooooooooooooooooooooooooooooooooo Mobile
| #################################### Router
| | |
+-------------------+ ===========Mobile Network========

Correspondent Router

The MR locates the CR for Longer route leading to increased delay

Because a given Correspondent and establishes packet must transit from a
Tunnel to the CR for that destination and its prefix(es). Then, the
CR establishes the Tunnel back mobile network to the MR and the Mobile Routes home
agent then to the
MR's Mobile Networks via that Tunnel.

A key point is that the CR must be on correspondent node, the interception path transit time of the
traffic from
packet is always higher than if the Correspondent packet were to go straight
from the Mobile Networks in order mobile network to
reroute the traffic over the appropriate Tunnel. This can be achieved
in several fashions:

Redistribution

There's a limited Number of CRs that cover an Autonomous System.
They redistribute correspondent node. In the Mobile Routes on best
case, where the fly, or within rate and
amount limits. Garbage Collection is done at appropriate time to
limit correspondent node resides near the perturbation on home agent,
the Routing.

Default Router

The CR increase in packet delay is a Default Router for the Correspondent, or for the whole
AS of the Correspondent (it's a border gateway). minimal. In this the worst case,
redistribution is not needed.

Core Routers

The Core Routers for where
both the mobile network of the Correspondent are all CRs.
If the path from and the correspondent to the Home Agent does not pass
via node are located at
a CR, then it's not worth optimizing. If it is, then point furthest away from the CRs
are home agent on the way. Again, redistribution is not needed.

4.3 Distributed Anchor Routers

Taking Internet, the idea of a correspondent router a step further, it
increase in delay is
possible to have a distributed set of anchor routers across the
Internet. Outgoing packets sent from a mobile network will tremendous. Applications such as real-time
multimedia streaming may not be
tunneled able to one tolerate such increase in
packet delay.

o Increased packets overhead

The encapsulation of packets in the nearest anchor router (instead of MR-HA tunnel results in
increased packet size due to the home
agent addition of the mobile router). an outer packet. This M-Side (Mobile Network Side)
anchor router will decapsulate
reduces the packet, inspect bandwidth efficiency, as IPv6 header can be quite
substantial (at least 40 bytes).

o Increased processing delay

The encapsulation of packets in the destination,
and MR-HA tunnel also results in
increased processing delay at the packet to another anchor router situated near the CN
(C-Side Anchor Router). From there, the packet will be decapsulated points of encapsulation and forwarded to the CN.

Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent
decapsulation.

o # n #
o # n # # :== Tunnel
o # n # o :== Optimized
o # n # n :== Non-Optimized
o # n #
C-Side ################## M-Side ###### n #
Anchor oooooooooooooooooo Anchor oooo Mobile
Router ################## Router #### Router
|
====Mobile Network=======

Optimization in the Infrastructure Increased chances of packet fragmentation

The C-Side Anchor Router will be subjected to the same condition as
listed increased in the previous sub-section if packets sent from the CN to the
mobile network are to be route-optimized too. Otherwise, the
solution will only partially optimize routing packet size due to a triangular routing
(i.e. packet sent by CN will still go through encapsulation may
increase the home agent chances of the
mobile network).

The anchor router share many similarities with packet being fragmented along the concept of
Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)
[9]. In fact, it
MR-HA tunnel. This can be combined with HMIPv6 whereby each M-Side
anchor router occur if there is also an MAP, and the MR obtains a regional
care-of-address from no prior path MTU
discovery conducted, or if the MAP.

5. Nested Mobile Network

5.1 Nested Tunnels Optimization

This section covers MTU discovery mechanism did not
take into account the case where one mobile network is within
another mobile network. For example, a user brings a Personal Area
Network (PAN) consisting encapsulation of some IP devices to a train which is also
using NEMO technology. In another example, a car which conatins 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 network moves into networks, the ferry which has another mobile network.
This configuration use of mobile networks within another mobile network
is called nested Mobile Networks.

Let us illustrate NEMO Basic Support
further amplifies the problem by an example. In sub-optimality of routing. We call this example, the
nested Mobile Network has a tree topology. In
amplification effect of nesting, where the tree (undesirable) effects of
sub-optimal routing with NEMO Basic Support is amplified with each node
level of nesting of mobile networks. This is a
basic Mobile Network, represented best illustrated by its MR.

+---------------------+
| an
example shown in Figure 1.

HAofMR1
+-----------|---------+
HAofMR2 --| Internet |---CN
+---------------|-----+
/ Access Router
MR3_HA
HAofMR3 |
======?======
====?========
MR1
|
====?=============?==============?===
====?===========?===========?===
MR5 MR2 MR6
| | |
=========== ===?========= =============
==|======= ===?====== ======|==
LFN2 MR3 LFN3
|
==|=========?== Net3
LFN1 MR4
|
=========

Figure 1: An example of nested Mobile Network

This example focuses on

Using NEMO Basic Support, the flow of packets between a Local Fixed
Node (LFN) at depth 3 (in Net3)
inside the tree, represented by its mobile router MR3. The path to
the Top Level Mobile Router (TLMR) MR1 LFN1 and then the Internet is:

MR3 -> MR2 -> MR1 -> Internet

Consider the case where a LFN belonging to Net3 sends a packet to a
Correspondent Node (CN) in the Internet, and the correspondent node CN replies back.

With no Nested Tunnels Optimization, we would have need to go through three
bi-directional nested
separate tunnels, as described in [3] and illustrated in
the following drawings:

-----------. Figure 2 below.

----------.
--------/ /-----------. /----------.
-------/ | | /----------- /-------
CN ------( - - | - - - | - - - | - - - | - - - (-------- (------- LFN
MR3_HA -------\
HAofMR3-------\ | | \----------- MR3
MR2_HA --------\ \----------- MR2
MR1_HA ----------- MR1

No Nested \-------MR3
HAofMR2--------\ \----------MR2
HAofMR1---------MR1

Figure 2: Nesting of Bi-Directional Tunnels Optimization

Such a solution introduces

This leads to the following problems:

"Pinball"

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,
the figure
Figure 3 below shows the route taken by a packet sent from LFN LFN1 to
CN:

Figure 3: 'Pinball' Routing

For more illustration of the pinball routing, see [7].

o Increased Packet size Size

An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [4] [8] cannot be
applied because both the source and destination (the intermediate
MR and its HA), are different hop to hop.

On the other hand, with a Nested Tunnel Optimization, we would have
at most one bi-directional tunnel outside the Mobile Network, that
may depend on the traffic flow:

__- --_
Tunnel---------------------------- MR1 ( Mobile ) MR3
CN ----------( - - - - - - - - - - ( - - - - )--------- LFN
Endpoint---------------------------- MR1 ( Network ) MR3
--___---

Nested Tunnels Optimization

The end-point of such a Tunnel on the Mobile side may either be MR1
or MR3, depending on the solution. In the case of a Mobile Node
visiting Net3, that Mobile Node may also be the end-point.

The potential approaches for avoiding the nesting of tunnels include:

Mobile Aggregation

This model applies to a category of problems were the

2.3 MIPv6 Host in Mobile Networks share

When a same administration and consistently move
together (e.g. MIPv6 mobile node joins a fleet at sea). In this model, there is mobile network, it becomes a cascade
visiting mobile node (VMN) of Home Agents.

The main Home Agent is fixed in the infrastructure, mobile network. Packets sent to
and advertises
an aggregated view of all the Mobile Networks. This aggregation is
actually divided over a number of Mobile Routers, from the TLMRs. The
TLMRs subdivide some of their address space visiting mobile node will have to be routed not only to
the other Mobile
Routers forming their fleet, for which they are Home Agent.

As Home Agents, the TLMRs terminate MIP Tunnels from the inside home agent of the Mobile Network. As Mobile Router, they visiting mobile node, but also terminate their to the home Tunnels. As routers, they forward packets between
agent of the 2
tunnels.

Surrogate

The TLMR acts as a proxy mobile router in the MIP registration, in a fashion of
MIPv4 Foreign Agent or HMIP MAP (see [9]). For instance, mobile network. This suffers the TLMR
maintains
same amplification effect of nested mobile router mentioned in
Section 2.2.

In addition, although Mobile IPv6 [2] allows a Tunnel mobile host to each MR, a Tunnel perform
route optimization with its correspondent node to avoid tunneling
with its home agent, the HA of each MR, and
switches packets between "optimized" route is no longer optimized
when the two.

Internal Routing and gateway

This item can be approached from mobile host is attached to a MANET standpoint. mobile network. This was
already done for DSR (see [10]) and AODV (see [11] and [8]) From a
Nemo standpoint, a full MANET is not necessary since
because the route between the goal mobile host and its correspondent node
is
to find a way subjected to the infrastructure, as opposed to any-to-any
connectivity.

RRH

The Reverse Routing Header (RRH) approach avoids sub-optimality introduced by the multiple
encapsulation MR-HA tunnel.
Interested readers may refer to [7] for examples of how the traffic but maintains the home tunnel routes
will appear with nesting of the
first MR on the egress path. It is described in details MIPv6 hosts in [5]. mobile networks.

2.4 Communications within a Mobile Networks

The first MR reliance on the way out (egress direction) encapsulates the
packet over MR-HA tunnel has its reverse tunnel, using a form of Record Route
header, the RRH.

The next MRs simply swap their CoA and the source of the packet,
saving the original source implications on MNNs in a
nested mobile network communicating with each other. Let us consider
the RRH. The HA transforms the RRH previous example illustrated in Figure 1. Suppose LFN1 and LFN2
are communicating with each other. With NEMO Basic Support, a Routing Header packet
sent from LFN1 to perform a Source Routing across the nested
Mobile Network, along LFN2 will follow the ingress path to of: LFN1 -> MR3 -> MR2 ->
MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 ->
MR5 -> LFN2. A round-about trip indeed where the target MR.

Access Router Option direct path would
be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2.

The Access Router Option (ARO) approach [6] consequences of increase packet delay and packet size have been
discussed in previous sub-sections. Here, there is somewhat similar an additional
effect that is undesirable: should MR1 loses its connection to the RRH in that only
global Internet, LFN1 and LFN2 can no longer communicates with each
other, even though the home tunnel direct path from LFN1 to LFN2 is unaffected!

3. Solution Space of NEMO Route Optimization

To address the first MR problems discussed in the egress
path is maintained. Section 2, one can incorporate
route optimization into NEMO. This is done by having MR to send an ARO in
Binding Update to inform its HA also known as the address of its access router.
Using this information, HA can build NEMO
Extended Support. Although a Routing Header standardized NEMO Extended Support has
yet materialize, one can expect it to
source-route show some of the following
benefits:

o Shorter Delay

Route optimization involves the selection and utilization of a packet
shorter (or faster) route to the target MR within in be taken for traffic between a nested mobile
network. Details can
network node and correspondent node. Hence a major benefit of
route optimization should be found shorter delay experiences by the data
traffic between the two end nodes. This may possibly in [6].

Prefix delegation approach

The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo
is turn
leads to MIPv6. The Access Router better overall Quality of the nested structure is both a
Nemo Home Agent and a DHCP-PD server, for an aggregation that it
owns Services characteristics, such
as reduced jitter and advertises to the Infrastructure. When visiting packet loss.

o Reduced Consumption of Overall Network Resources

Through the
nested structure, each MR is delegated selection of a mobile network prefix
from shorter route, the AR using DHCP-Prefix Delegation. The MR registers this
delegated MNP to total link
utilization for all links used by traffic between the AR two end
nodes should be much lower than that used if route optimization is acting as a Nemo Home Agent. The
MR also autoconfigures an address from the delegated MNP and uses
it as
not carried out. This would result in a CareOf to register its own MNPs lighter network load with
reduced congestion.

o Less Susceptibility to its own Home Agent
using Nemo basic support. It is possible for Link Failure

An optimized route would conceivably utilize a MR to protect its
own MNPs while advertising in lesser number of
links between the clear two end nodes. Hence, the local MNP for other
MRs probability of
connectivity loss due to roam in. This allows a strict privacy single point of visited and
visitors, and enables some specific policies in each Mobile
Router. Details can be found in [7].

5.2 Route Optimization inside the Nested Mobile Network

Although optimization within failure at a mobile network is not within link
should be lower as compared to the
charter of longer non-optimized route.

o Greater Data Efficiency

Depending on the actual solution for NEMO working group, it might be insightful to discuss
such optimizations.

The expectation is that Extended Support, the mobile routes installed
data packets exchanged between the two end nodes may not require
as many levels of encapsulation as required by NEMO can
cohabit with a MANET support that Basic Support.
This would perform the RO inside the
Nested Mobile Network. In other words, MIP redistributes its prefixes
locally to a MANET 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 MR-HA tunnel is bypassed.

6. General Considerations

6.1 Securing following
sub-sections, we describe the protocol in nested tunnels solution space of route optimization

These approaches are generally difficult to secure unless all the
Mobile Routers and Visiting Mobile Node belong by
listing different types of approach to a same
administrative domain and share predefined Security Associations.

Even if an intermediate MR is 'trusted', this does not prove it is
able route optimization. Readers
might be interested to provide the necessary bandwidth, and may not provide a good
service. Eventually, a MR that is capable take note of securing (IPSec) its
traffic may select a Mobile Access Router route optimization model
described in [9] which describes route optimization model based on quality of service
heuristics as opposed as trust.

The problem is global to the whole Mobile Network in
the case variations of a
MANET-based solution. For an RRH-based solution, the threat comes
from on-axis MRs in the nested Mobile tunnel end-points.

3.1 MR-to-CN Optimization

o Binding Update with Network but is mostly limited Prefix

A straight-forward approach to denial of service. This route optimization is detailed in [5]. The approach taken NEMO is
to limit
for the threat mobile router to Black Hole and Grey Hole by using IPSec.

6.2 Recursive complexity in attempt route optimization

A number of drafts and publications suggest -or with
correspondent node. This can be extended to- viewed as a
model logical extension to
NEMO Basic Support, where the Home Agent and any arbitrary Correspondent mobile router would
actually get individual send binding from
updates to the chain of nested correspondent node containing one or more Mobile
Routers, and form
Network Prefix option. The correspondent node having received the
binding update, can then set up a routing header appropriately.

An intermediate MR would keep track of all bi-directional tunnel with the pending communications
between hosts in its subtree
mobile router at the current care-of address of Mobile Networks and their CNs, the mobile router,
and inject a
binding message route to each CN each time it changes its point of
attachment.

If this was done, then each CN, by receiving all 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 messages update can optimize the routes of
many flows between the correspondent node and processing them recursively, could infer the MNNs.

o MR as a partial topology of Proxy

A somewhat similar approach is for the nested Mobile Network, sufficient mobile router to build act as a multi-hop routing
header
"proxy" for packets sent to nodes inside the nested Mobile Network.

However, MNNs in its mobile network. In this extension has a cost:

1. Binding Update storm

when one case, The MR changes its point of attachment, it needs
uses standard MIPv6 route optimization procedure to send bind the
address of a
BU MNN to all its care-of address. This has the CNs advantage
of each node behind him. When the Mobile
Network is nested, keeping the number implementations of MNNs and correspondent nodes
unchanged, and relative CNs can be
huge, leading to congestions and drops.

2. Protocol Hacks

Also, in order to send the BUs, done by having the MR has mobile router to keep track of all perform
the traffic it forwards following steps:

* determining when to maintain his list of CNs. In case of
IPSec tunneled traffic, that CN information may not be available.

3. CN operation

The computation burden perform RO (eg. by the flow packet count)

* sending CoTI and HoTI on behalf of the CN becomes heavy, because MNN

* receiving CoT (trivial, since it has to
analyze each BU in a recursive fashion in order to infer nested
Mobile Network topology required is addressed to build a multi hop routing
header.

4. Missing BU

If a CN doesn't receive the full set MR)

* intercepting the HoT (which requires inspection of PSBU sent by the MR, it
will not be able packets
addressed to infer the full path to a node inside MNN)

* sending the
nested Mobile Network. The RH will be incomplete BU and receiving the packet
may or may not be delivered.

5. Obsolete BU

If BA on behalf of MNN

* inserting the Binding messages are Home Address Option in packets sent asynchronously by each MR, then,
when the relative position of MRs and/or the TLMR point of
attachment change rapidly, the image of Mobile Network that MNN

* removing the
CN maintains is highly unstable. If only one BU type 2 routing header in packets sent to the chain is
obsolete due MNN

* adjusting various ICMP packets to account for the movement modification
it performs

3.2 Infrastructure Optimization

There are two known approaches to achieve infrastructure
optimization. The first approach involves the introduction of an intermediate MR, the
connectivity may be lost.

6.3 Mobile Access
entity known as a correspondent-side router selection

In some case, nested Mobile Networks attaches to visiting network
with multiples mobile access (C-side Router), or
sometimes known simply as a correspondent router that are gateways to the global
internet. These RO methods may cover (CR) within the function in which how
routing infrastructure. As long as the MR
in correspondent router is
located "closer" to the nested Mobile Network choose correspondent node than the one home agent of the
mobile access
routers. This function is not explicitly described in current
methods and needs to be discussed.

6.4 Mobility transparency router, the route between MNN and RO

[cwng's interpretation of Mobility Transparency in RO]

It is desirable in mobility-related protocols that the mobility of a
mobile correspondent node is transparent can
be said to other entities and other layers have optimized. This is illustrated in the
mobile node. The Basic Figure 4.

Figure 4: Infrastructure Optimization

This form of optimization can take place independently for the 2
directions of the mobile network traffic:

o From MNN to CN

The mobile router locates the MNNs by correspondent router, establishes a MR-HA
tunnel so with that MNNs need not be aware of the MR's change in point of
attachment.

Such correspondent router and sets a feature is, as mentioned, desirable. However, when route
optimizations, end-to-end principle, and other factors come into
consideration, achieving mobility transparency may to the
correspondent node via the correspondent router over the tunnel.
After this, traffic to the correspondent node does not be practical.

For instance, flow
through the home agent anymore.

o From CN to achieve nested tunnel optimizations, MNN

The correspondent router is on the mobility path of the top-level MR is often exposed traffic from the
correspondent node to other entities, such as the HA
of a nested MR. home agent. In addition, it has an
established tunnel with the case current care-of address of MR performing BU for MNNs, it might
be necessary to pass mobility information the mobile
router and is aware of the MR mobile network prefix(es) managed by
the mobile router. The correspondent router can thus intercept
packets going to CN (and even
MNN) in order not the mobile network, and forward them to break the end-to-end principle. For
mobile router over the
scenario established tunnel.

The advantage of optimization using infrastructure, this approach is that no additional functionality is
required for the mobility
information might be necessarily exposed to correspondent routers node and mobile network nodes.

The second approach is to have optimizations carried out fully in
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
MAP.

Thus, one should bear proxies in mind when designing RO 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 that 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
sacrifice might nested mobile network will be necessary when weighing conflicting factors such the
same as mobility transparency, optimization level, though there were no nesting of mobile networks.

There have been various proposals on nested tunnels optimization, and end-to-end
integrity.

[Hosik's interpretation
we can model them according to:

o Sending Information of Mobility Transparency 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
header recursively.

o Prefix Delegation

An alternative approach to nested tunnels optimization is to use
prefix delegation. Here, each mobile router in RO] 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 case care-of addresses of extended support each mobile router are all from
an aggregatable address space starting from the access router.
This may be used to eliminate any nesting of NEMO such 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 NEMO, mobility
transparency 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 desirable but that very similar to "Nested Tunnels Optimization" described in
Section 3.3. Thus, a possible approach is not mandatory to extend the solution
for nested tunnels optimization to visiting mobile node as well.

o MIPv6 Route Optimization

This aims to remove the
efficiency sub-optimality of a MR-HA tunnel from the
MIPv6 route optimization. For example, 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 notebook return routability
procedure between the visiting mobile node and
PDA inside 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 vehicle Proxy"). Alternatively, the mobile router can access 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 Internet through functionality of the correspondent node
unchanged.

3.5 Intra-NEMO Optimization

A route optimization solution may seek to improve the communications
between two mobile
router 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 vehicle. 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.

4. Analysis of Solution Space

In this section, we present an analysis of the solution space.
First, we discuss the general issues that case, if 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 movement 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 vehicle
affects actual solution. Such a cost may scale to
unacceptable height when the notebook 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 PDA, they can perform individual 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 operation 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).

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 correspondent node or its home agent
but
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 can cause 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 problem.

[Onishi's interpretation 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 Mobility Transparency whether to trade location privacy for an optimized route. It will
be desirable that such control is also available in RO] 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 RO solutions, MR can optimize 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.

In addition, if route between its own HA 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 MR. 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 desirable 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 communication can 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
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 interrupted by 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. ????

6.5 Multihoming Considerations optimization approach. In multihomed mobile networks, 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 dependant a question on
the additional risk imposed on how the connections correspondent node. Although
return routability procedure allows the correspondent node to
verify that the Internet care-of and home addresses of the mobile router
are available 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 selected.

In 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 macro mobility, we 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 multiple HAs from place an influence to
place. New route optimization could the decision of whether the tradeoff should
be possible 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 between 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
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 multiple Home Agents (possibly 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 differenc Home
Addresses).

When multiple connections are available for correspondent routers
may face the following issues:

o Security Considerations

The first security-related issue is how do the mobile router
verify the purpose validity of fault
tolerance, a selection 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.

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 needed 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 CN consideration is whether the home agent should trust
the upstream information supplied by the nested mobile router. If
the upstream information falsely points to eveluate a victim node, the
connection availability 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.

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,
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.

7. The expense will be that a new form of signaling
between the visiting mobile node and mobile router would most
likely be required.

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).

5. Conclusion

The Problem problem space of Route Optimization route optimization in the NEMO context is
multifold and can be split is 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.

Hopefully, the solutions will build on MIPv6 ([1]), as recommended by
the

This memo explored into various problems of sub-optimality of NEMO Charter. On the other hand, MIPv6 seems to be evolving in a
direction that makes it more
Basic Support, and more difficult to provide discussed different aspects of a NEMO route optimized
solution with backward compatibility, since:

1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,

2) The RR test has no negotiable option and is not open for
extension, and

3) The HaO and RH type 2 are designed for a collocated CareOf
Address. More specifically, they are not designed to be multi-hop as
RRH is, and not extensible, though RRH can be considered as an
extension of HAO. in NEMO. The authors intent of this document is to trigger fruitful
discussions that in turn will enhance our common understanding of the
route optimization problem space so that at
some point, this paper turns into a problem statement for the Nemo
Route Optimization.

8. Acknowledgements and solution space.

6. Acknowledgments

The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki
Ohnishi, 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", draft-ietf-mobileip-ipv6-24 (work in progress), July
2003.

[2] 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-00
draft-ietf-nemo-terminology-01 (work in progress), May 2003.

[3] kniveton, t., "Mobile Router 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 Mobile IP",
draft-kniveton-mobrtr-02 Nested
Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in
progress), July 2002.

[4] 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.

[5]

[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)",
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-04
draft-thubert-nemo-reverse-routing-header-05 (work in
progress), February June 2004.

[6] Tanaka, T. and

[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-00
draft-ng-nemo-access-router-option-01 (work in progress),
November 2002.

[7] 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.

[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.

[8] Wakikawa, R., "Global Connectivity

[24] Lee, K., "Route Optimization for IPv6 Mobile Ad Hoc
Networks", draft-wakikawa-manet-globalv6-03 (work Nodes in progress),
October 2003.

[9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
"Hierarchical MIPv6 mobility management (HMIPv6)",
draft-ietf-mobileip-hmipv6-06 Mobile Network
based on Prefix Delegation", draft-leekj-nemo-ro-pd-02 (work
in progress), July 2002.

[10] Johnson, D., "The Dynamic Source Routing Protocol February 2004.

[25] Jeong, J., "ND-Proxy based Route Optimization for Mobile Ad
Hoc Networks (DSR)", draft-ietf-manet-dsr-09 Nodes
in Mobile Network", draft-jeong-nemo-ro-ndproxy-02 (work in
progress), April 2003.

[11] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance
Vector (AODV) Routing", draft-ietf-manet-aodv-11 February 2004.

[26] Perera, E., "Extended Network Mobility Support",
draft-perera-nemo-extended-00 (work in progress), July 2002.

[12] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.

[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. 2003.

Authors' Addresses

Pascal Thubert
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE

EMail: pthubert@cisco.com

Marco Molteni
Cisco Systems Technology Center
Village d'Entreprises Green Side
400, Avenue Roumanille
Biot - Sophia Antipolis 06410
FRANCE

EMail: mmolteni@cisco.com

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
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 Paik
Seoul National University
Shillim-dong, Kwanak-gu
KT
Portable Internet Team, Convergence Lab., KT
17 Woomyeon-dong, Seocho-gu
Seoul 151-744
KOREA 137-792
Korea

Phone: +82-2-526-5233
Fax: +82-2-526-5200
EMail: eun@mmlab.snu.ac.kr euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/

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
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.

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
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).

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.

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property
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; neither nor does it represent that it has
made any independent effort to identify any such rights. Information
on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation RFC documents can be
found in BCP-11. BCP 78 and BCP 79.

Copies of
claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose at
ietf-ipr@ietf.org.

Disclaimer of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. Validity

This document and the information contained herein is 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 DISCLAIMS 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 (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.