wdiff draft-clausen-nemo-ro-problem-statement-00.txt draft-clausen-nemo-ro-problem-statement-01.txt

INTERNET-DRAFT Thomas Clausen
IETF NEMO Working Group Emmanuel
(MA)NEMO E. Baccelli
Expiration: 15 April 2005
Internet-Draft INRIA
Expires: September 6, 2007 T. Clausen
LIX, Ecole Polytechnique, France
Ryuji
R. Wakikawa
Keio University/WIDE
15 October 2004 University, WIDE
March 5, 2007

NEMO Route Optimisation Problem Statement
draft-clausen-nemo-ro-problem-statement-00.txt
draft-clausen-nemo-ro-problem-statement-01

Status of this Memo

This document is a submission to the Network Mobility Working Group
of the Internet Engineering Task Force (IETF). Comments should be
submitted to the nemo@ietf.org mailing list.

Distribution of this memo is unlimited.

By submitting this Internet-Draft, I certify each author represents that any
applicable patent or other IPR claims of which I am he or she is aware
have been disclosed, or will be disclosed, and any of which I become he or she becomes
aware will be disclosed, in accordance with RFC 3668.

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 6 of RFC 2026. BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. Internet-
Drafts.

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.

Abstract

The NEMO working group has developed a protocol suite, extending the
notion of edge-mobility on the Internet to include that of network
mobility. This implies that a set of nodes, along with their mobile
router, change their point of attachment and that traffic to these
nodes is tunneled to be delivered through their new point of
attachment.

This mechanism is transparent to applications in that
existing traffic to a node is being encapsulated and tunneled,
regardless of where the network containing the destination node is
attached. Internet-Draft will expire on September 6, 2007.

Abstract

The NEMO basic support specification is not limited to a single level
of mobile
networks, networks attaching to the stationary Internet. Rather,
arbitrary levels of nested mobile networks are supported, employing
for each level of nesting the same attachment, encapsulation and tunneling
tunnelling mechanisms. With arbitrarily deep nested mobile networks,
paths taken by data traffic can be extremely sub-optimal both inside
the nested topology through successive mobile routers, and outside
the nested topology, through successive Home Agents over the
Internet. Moreover, the overhead incurred through tunneling tunnelling and
encapsulation of data traffic can, however, can become prohibitively large. As a consequence, a number of different proposals
exist, which aim at performing "route optimization" for nested mobile
networks. This
document aims at describing analyses the different scenarios in which
route-optimization is desired, as well as the different proposed
solutions for achieving route-optimization in nested mobile networks. these problems are
particularly acute.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.
3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. NEMO-to-NEMO . . . . . . . . . . . . . . 5
3.1. Internet - Nested NEMO Communication . . . . . . . . . . . 5
2.2. Internet-to-NEMO . . . . . . . . . .
3.2. Intra Nested NEMO Communication . . . . . . . . . . . . . 6
3. Solutions .
3.3. RFC3963 Loops . . . . . . . . . . . . . . . . . . . . . . 7
4. Problem Statement . . . . . 7
3.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . 8
4.1. Lack of Nested Topology State Information . . . . . . . . 8
3.1.1.
4.2. Goals of Route Optimization Mechanisms Within for Nested NEMO . . . networks . . . 9
3.1.2. Ad-hoc Network of Mobile Routers .
4.3. Solution Guidelines . . . . . . . . . . . . . 9
3.2. Internet-to-NEMO . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . 11
3.2.1. Route Optimization Mechanisms Initiated by MR or MNN . . . . 11
3.2.2. Route Optimization Initiated by a Non-Mobile Router . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Authors' Addresses . .
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6.
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . .
Authors' Addresses . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.
Intellectual Property and Copyright Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15

1. Introduction

The NEMO protocol suite basic support specification [1] extends Mobile IP in enabling the notion of edge-
mobility on the Internet to include that of network mobility. This
implies that a set of nodes, along with their mobile router, to change
their point of attachment
to the Internet. NEMO enables the and that traffic to these nodes is
tunnelled to be tun-
neled for delivery delivered through their new point of attachment. The use of
tunneling makes this
This mechanism is transparent to applications, wherever
the new point of attachement, even applications in case that existing
traffic to a node is being encapsulated and tunnelled, regardless of several layers
where the network containing the destination node is attached.

The NEMO basic support specification is furthermore not limited to a
single level of
nested mobility (i.e. mobile nodes, or mobile routers, indirectly
accessing networks attaching to the Internet through other stationary Internet.
Rather, arbitrary levels of nested mobile routers). networks are supported,
employing for each level of nesting the same transparent mechanisms
relying on attachment, encapsulation and tunnelling.

However, this approach is not without a certain cost: with arbitrar-
ily arbitrarily deep nested mobile networks, paths taken by
data traffic can become extremely sub-optimal both (i) inside the
nested topology through successive mobile routers, and (ii) outside
the nested topology, through successive Home Agents over the
Internet. Moreover, the overhead due to tunneling, dog-
leg routing incurred through tunnelling and
encapsulation of data traffic can become prohibitively large. A
number of different solutions have been proposed in order

This document describes cases where problems due to optimize
this routing in some of these cases.

A review of some of these solutions is provided in this document, as
well as the sub-optimal data
traffic paths and encapsulation overhead are acute, providing a
discussion of which cases and to what extent route opti-
mization optimisation is desireable
desirable with NEMO.

1.1.

2. Terminology

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [5].

It is moreover assumed that readers are familiar with NEMO
terminology as described and employed in [1] and [8].

1.2. Applicability

This document aims at discussing scenarios where route optimization
is desirable in a NEMO environment, and what level of route optimiza-
tion is desired in those cases. A review of some existing solutions
and ideas is thereby provided.

2. [2].

3. Deployment Scenarios

At least two distinct

Two categories of scenarios exist, where route optimization optimisation is
desireable.
desirable. Those are, respectively, respectively: (i) when a node host from the
Internet wishes to communicate with a host in a nested NEMO, and (ii)
when a host in a nested NEMO network wishes to communicate with a node host in
another nested NEMO network which is part of the same nesting, and when a node from the Internet wishes to
communicate with a node in a nested NEMO network.

While the scenarios may have commonalities, their possible solution-
space differs and they topology.
Some of these issues are therefore described seperately below.

2.1. NEMO-to-NEMO also elaborated in [4].

3.1. Internet - Nested NEMO Communication

In this category of scenario, a number of NEMO networks are nested to
one another, and nodes a host in the different NEMO networks are communicating Internet wishes to communicate with a
host in one another. of the NEMO networks. For the purpose of describing this scenario description, refer
to
scenario, the schematics below: example depicted in Fig. 1 below is considered.

---------- ---------- ---------- ----------
| | | | | | | |
| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet |--Internet--| Host 1 |
| | | | | | | | |
---------- ---------- ---------- | ----------
| ----------
---------- | | |
| | |----| HA 2 |
| HA 1 |---------| | |
| | | ----------
---------- |
----------
| |
| HA 3 |
| |
----------

Figure 1: Nested NEMO networks -- NEMO-to-NEMO Internet-to-NEMO communication

We assume that each box labeled labelled "NEMO x" refers to a Mobile Router
(MR), running the NEMO protocol, as well as the nodes hosts attached to
that mobile router. We further assume, that each line indicates a
direct connection between routers -- i.e. the mobile router in "NEMO
1" has a direct connection to the mobile router in "NEMO 2". Each
box
labeled labelled "HA x" refers to the Home Agent for the NEMO network x
-- i.e. that HA 1 is the Home Agent for the mobile network NEMO 1.

If a node from NEMO 3

The host labelled "Host 1" wishes to communicate with a node from "NEMO
1", then the data host in NEMO
1. Data traffic would will first be sent to routed through HA 1 the Home Agent of
NEMO 1 -- i.e. to HA 1. At HA 1, a binding would exist, identifying NEMO 1 as being
attached to the network of NEMO 2. Thus, the traffic would be
encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA 2, a
binding would exist, identifying that, indeed, NEMO 2 is attached to
the network of NEMO 3. Another encapsulation would ensure, and the
traffic sent to HA 3. At HA 3, a binding would identify the point of
attachment of NEMO 3 to the internet, and the data traffic would be
encapsulated one final time prior to being delivered to NEMO 3 --
where decapsulation and handoff to NEMO 2, then NEMO 1 occurs.

In this scenario, short path between NEMO 1 and NEMO 3, without
transversing

This simple example scenario therefore involves communication with
(i) triple encapsulation of the Internet data, and HA1-3, exists, however is not used in (ii) its transmission via 3
arbitrary locations across the current NEMO specification. Internet. More generally, assume a set if instead
of a depth 3 the nested NEMO networks forming structure had a connected
network depth N, the
communication would involve worst case N levels of encapsulation of
the data, and its transmission via their mobile routers without transversing N arbitrary locations across the
Internet.
For This is thus very sub-optimal communication between nodes in these NEMO networks, a solution
should exist, which provides routes between the nodes without
transversing across the
Internet and without incuring excessive nested
encapsulations.

2.2. Internet-to-NEMO ([3].

3.2. Intra Nested NEMO Communication

In this category of scenario, a number of NEMO networks are nested to
one another, and a node hosts in the Internet wishes to communicate to a node
in different nested NEMOs are
communicating with one of the NEMO networks. another. For the purpose of describing this scenario
description, refer to
scenario, the schematics below:

---------- example depicted in Fig. 2 below is considered.

---------- ---------- ----------
| | | | | |
| |
| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Node 1 |
| | |--Internet
| | | | | | |
---------- ---------- ---------- | ----------
| ----------
---------- | | |
| | |----| HA 2 |
| HA 1 |---------| | |
| | | ----------
---------- |
----------
| |
| HA 3 |
| |
----------

Figure

Fig. 2: Nested NEMO networks -- Internet-to-NEMO NEMO-to-NEMO communication

The node labeled "Node 1"

If a host from NEMO 3 wishes to communicate with a node in host from NEMO
1. Similarly to 1,
then the previous scenario, this will happen through con-
necting data traffic would first be sent out the nested NEMO
network, over the Internet to HA 1, 1. The data traffic would then encapsulation be
encapsulated and tunneling data tunnelled to HA 2 2, which will in turn add another
layer of encapsulation and tunnel the traffic to HA3 which will do
the same before the data arrives at the edge of returns to our nested NEMO network.

Only then can
Successive decapsulation and transmission via NEMO 3, NEMO 2 and NEMO
1 happen.

In this scenario, while no direct link exists between Node 1 and will then happen before data is delivered to the
node in NEMO 1, destination.

Again, this simple example scenario involves communication with (i)
triple encapsulation of the data, and (ii) its transmission via HA1-3
occurs.

More generally, a path between a node in the Internet and 3
arbitrary locations across the edge Internet. And again, more generally,
if instead of a depth 3 the nested NEMO networks exists, which does not necessarilly involve
any of the Home Agents for the NEMO networks. For such communication, structure had a solution should exist which avoids nested encapsulations (i.e.
allows data to be encapsulated only once, in order to arrive at depth N, the
edge
communication would involve N levels of encapsulation of the nested NEMO networks), data,
and which does not force a path
which involves all the Home Agents of its transmission via N arbitrary locations across the nested NEMO networks on Internet.
This is therefore very sub-optimal communication across the
path to Internet,
as communication inside the destination.

In addition, nested encapsulation brings a limitation NEMO network should be sufficient.

3.3. RFC3963 Loops

[1] allows for NEMO mobile routers to the number
of nested levels, due nest to MTU size. For example, the current NEMO
basic support specification one another, however
does not allow a level higher than 40 in
nesting in NEMO (with usual MTU = 1500 bytes), due stipulate how to form the size links of the
40 IPv6 headers, i.e. 40 bytes x 40 > MTU. nest. In this case IP fragmen-
tation does not help, since the total size of IPv6 headers exceeds
the MTU. Thus, particular,
[1] allows for, as is illustrated in the avoidance following Fig. 3, NEMO 1 to
select NEMO 2 as its point of nested encapsulations also eliminates
the limitation on the level attachment, with NEMO 2 selecting NEMO
3 as point of nesting in NEMO.

3. Solutions

Common for the scenarios attachment and NEMO 3 selecting NEMO 1 - thereby
forming a loop. Absent other mechanisms, this loop will persist,
potentially disconnecting both NEMO 1, NEMO 2 and NEMO 3 from the previous section is, that
wider network, from the
encapsulation Internet, and tunneling - if traffic between NEMO nodes
is due tunnelled through HAs, also from each other. [1] does not provide
functionality allowing to detect this loop: a MR cannot know whether
it connects to a mobile network or a general IPv6 network.

---------- ----------
| |--| |
| NEMO 1 | | NEMO 2 |
| | | |
---------- ----------
| |
----------
| |
| NEMO 3 |
| |
----------

Fig. 3: Loop in Nested NEMO networks

4. Problem Statement

Encapsulation and tunnelling specified by NEMO basic support [1] are
governed by the facts that:

- the node following principles:

1. A router which originates forwards data traffic does not know where the
destination node is located and therefore assumes that the
node it is at its
Home Network;

- no router knows the full path

2. A Home Agent does not know if a NEMO is directly or indirectly
bound to the destination, Internet, which in particular means that:

- no

3. No router knows the topology of the nested NEMO network(s).

As a concequence, each

While these principles are functional, they have the consequences
that are described in the following.

4.1. Lack of Nested Topology State Information

The lack of state information about the nested NEMO topology and its
point(s) of attachment to the Internet causes routing to involve
logical hop hops (from source to Home Agent of des-
tination, destination, or from Home
Agent to Home Agent Agent), each of the nested NEMO net-
works) adds layers those adding a layer of encapsulation, until encapsulation
and a detour across the Internet, until a point of attachment between
the Internet and the nested NEMO edge, the Access Router (AR) network is reached.

Concequently, if the source node, or any intermediate node, had addi-
tional information about the network topology, more beneficial
tunnels could be created,

This lack causes extreme data paths sub-optimality and less extreme data
encapsulation would be required.

For example if, overhead in figure 2 above, Node 1 knew directly that the
gateway from the Internet to "the network cases where nodes from NEMO 1 are
attached" was the Access Router of NEMO 3, and if the mobile router
in NEMO 3 knew the nested topology is of the nested NEMO network, a tunnel
could be directly created from Node 1 to NEMO 3, with assurance that
the mobile router depth
greater than 2, as depicted in NEMO 3 would be able to route data packets cor-
rectly to the destination. Section 3.2 and Section 3.1. NEMO-to-NEMO

The NEMO-to-NEMO problem, as described in section 2.1, is one of how
to avoid transversing the Internet in order to communicate between
two nodes which are part of the same nested NEMO network. More gener-
ally, this can be expressed as "how traffic is routed within following items summarise the NEMO
network".

NEMO basic support [1] specifies that traffic be routed via Home
Agents, indicating an assumption of limited depth problems incurring from lack of
nested networks
and traffic patterns being predominantly topology state information:

Internet Route Suboptimality - where traffic of from the Internet-to-
NEMO type. Each mobile router in a NEMO network knows only of its
attachments, i.e. its access router internet
transverses more than one HA, incurring both route sub-optimality
and the nodes within its own
mobile network. A mobile router in NEMO does not know about any nest-
ings, i.e. it does not know the topology of the nested NEMO network
-- and as such, can only provide routes to the Home Agents on the
Internet.

In order to avoid the scenario described in section 2.1, encapsulation;

Intra-NEMO Route Suboptimality - where data
packets for delivery within traffic between hosts in the
nested NEMO network are routed is forced through the Internet gateway and the nested networks Home Agents, when a
subsequently through one or more
localized aproach would have been possible, additional state can be
maintained in the HAs, incurring both route sub-
optimality and nested NEMO networks. A number of approaches for
maintaining state in mobile routers and/or Home Agents encapsulation;

Intra-NEMO loops - where, due to unfortunate selection of mobile net-
works have been discussed, including [3], [4], [9], [10], [11], [12],
[13], in which techniques such as route caching are discussed. These
techniques can be deployed in Home Agents, in routers, specifically
designated as aggregation points for NEMO tunnels, as well as within
the mobile routers in order MR
is attaching to optimize routes within a nested which MR, loops occur.

4.2. Goals of Route Optimization for Nested NEMO
network. This is detailed in section 3.1.1.

Essentially, however, the issue networks

The goal of route optimization within a optimisation for nested NEMO network is one of routing: maintaining state in each mobile
router such that an intelligent forwarding decision can be made.
I.e., if the destination can be detected to be "local" to alleviate the nest of
NEMO networks, a
problems regarding (i) Internet route to sub-optimality, (ii) Intra-NEMO
route sub-optimality, and (iii) Intra-NEMO loops. Additional
information about the destination can nested topology must be constructed directly
through the NEMO mobile routers without passing through the Home
Agents. Alternatively, if the destination is not local, data are
routed available to the Mobile
Routers and/or Home Agent, where basic agents, which:

o may serve to allow NEMO tunneling MRs to detect and encapsula-
tion take effect. Deploying a routing protocol for maintaining suffi-
cient state in the nodes alleviate loops or to
prevent such from occurring in the nested NEMO network is detailed in
section 3.1.2.

3.1.1. Route Optimization Mechanisms Within Nested first place. Specifically,
this allows a NEMO

Some approaches have been proposed MR to tackle the problem of route
optimization inside nested NEMO networks. For instance, Nested NEMO
Tree Discovery [4] offers a mechanism ensure that aims at avoiding routing
loops by organizing and maintaining a tree structure within the net-
work of nested NEMOs, the root being the Access Router or the Mobile
Router directly connected loop-free path to the Access Router (the Top Level Mobile
Router).

Source routing is also proposed to be used in this environment.
Approaches like RRH [12] use the recording of the sequences of tra-
versed Mobile Routers on the way out of the nested NEMO network (to
the Internet, say,
Internet Gateway exists;

o may serve to bind) in order establish and maintain an intra-NEMO routing mesh,
allowing to forward traffic efficiently
in the nested NEMO network.

On bypass the other hand, approaches like ORC (Optimized Route Cache Proto-
col [3]) could be adapted to Internet Gateway and HAs for intra-NEMO
communications;

o may serve the purpose of insuring some level
of optimized to bypass dog-leg routing inside nested NEMO networks. Some router, say in communications from sources
on the top level mobile router, could be configured to play a role simi-
lar Internet to a correspondent router, organizing the forwarding of packets
inside the nested NEMO network. This special router could be dynami-
cally discovered inside mobile node in the nested NEMO network.

4.3. Solution Guidelines

A more general form of this mechanism would be solution to have each MR in the
nested NEMO network possess this extended information about the
nested NEMO network. This does then, de-facto, become Route Optimisation problem will:

o provide a situation
where mechanism whereby each MR knows the entire topology of the nested NEMO network,
and will be able to act in the capacity of router for such traffic.
This generalized mechanism is described in more details in section
3.1.2.

3.1.2. Ad-hoc Network of Mobile Routers

A NEMO network consists of a mobile router, to which a set of nodes
are (statically) attached. The mobile router communicates with (i.e. has direct links with) other mobile routers, and possibly with the
Internet at large. As such, a NEMO network is not much different from
any other network. What makes NEMO networks different from other net-
works is, sufficient topological
awareness such that they it may change their point of attachment at will --
i.e. select the topology formed by NEMO mobile routers is dynamic.

Thus, in order router(s) to provide routes between any two nodes in the nested
NEMO network, a mechanism must be in place which ensures it
attaches such that the
dynamic topology of the nested NEMO network can be accurately tracked
and used for routing table calculations.

The IETF MANET working group loops are avoided;

o provide a mechanism whereby each MR has been developing routing protocols
for dynamic ad-hoc networks, sufficient topological
awareness such as OLSR [2] and AODV [6] (both
RFC), with the characteristics that it may select a suitable path towards the developed protocols should be
light-weight, able to react to rapid topology changes and limit the
signalling overhead. An approach to route optimization within the
NEMO-to-NEMO scenario could therefore be to consider the mobile
routers of the nested NEMO networks as nodes in an ad-hoc network,
and run an ad-hoc routing protocol to ensure that each mobile router
would be able to determine if data could be locally (i.e. within the
nested NEMO network) delivered, or had to be tunneled back to the
Home Agent.

OLSR [2],
Internet Gateway for example, provides light-weight OSPF-like [7] routing
functionality. This includes efficient maintenance of the topology
spanned by the links between communication towards the mobile routers Internet and - in the face of net-
work dynamics, as well as the ability for
particular - towards its HA;

o provide a mobile router to adver-
tize associated nodes which do not run the OLSR routing protocol
(e.g. nodes associated to mechanism whereby each Internet Gateway has sufficient
topological awareness such that it may select a mobile router, which are not themself
mobile routers). It is also possible for Mobile Network Nodes to
obtain global connectivity, as described suitable path
towards each MR in [16].

Employing a protocol such as OLSR among the mobile routers in a nested NEMO network would yield the ability for any mobile router to
determine if a destination can be reached through a path local to the
nested NEMO network, or if forwarding to the Home Agent which it is required.
Additionally, this would also ease the Internet-to-NEMO scenario. In
order to deliver an IP datagram to
providing Internet access;

o provide a node in the nested NEMO network,
only mechanism whereby each MR has sufficient topological
awareness such that it may select a suitable path to the access router between towards another
MR within the nested NEMO network and without transversing the Internet would be required: once an IP datagram arrives in the
nested NEMO network, the routing tables in the mobile routers, as
provided by OLSR, would allow direct routing to the destination.
Thus, there would no longer be Gateway;

o provide a requirement to do nested encapsula-
tion on each logical hop (i.e. mechanism whereby each transversal MR has sufficient topological
awareness such that it may provide suitable binding updates with
its HA. A particular case of a Home Agent) in
order to be able to decapsulate and correctly forward IP datagrams in
the nested NEMO network.

Thus even this is if no route optimizations are performed in the Internet-to-
NEMO scenario, an overhead reduction MR can still be achieved through
much lower encapsulation requirements.

3.2. Internet-to-NEMO

The goal here is, again, to avoid unnecessary encapsulation provide
binding updates such that multiple encapsulations and dog-
leg routing. Indeed, it is desirable to avoid letting the level of
nested mobility sub-optimal
routes on the edges of the network dictating the number of
Home Agents (and therefore the amount of encapsulation) the packets
have to go through. There should Internet can be avoided when a way MR is connected to limit
the level of tun-
neling to only one encapsulation IP Internet Gateway through multiple intermediate MRs in IP, and at the same time, min-
imize the traffic relayed by Home Agents.

Existing solution to route optimization problems in NEMO therefore
aim at, basically, minimizing the required amount of tunneling in
various nested mobility cases. They can be categorized as follows:

- route optimization initiated by Mobile Routers (MR) or Mobile
Network Nodes (MNN);

- route optimization initiated by intermediate non-mobile
routers on the path to Corresponding Nodes.

The following sub-sections briefly review these solutions.

3.2.1. Route Optimization
nest.

Mechanisms Initiated by MR or MNN

In case developed for maintaining and using such information must
address the distributed, multi-hop nature of nested mobility (i.e. a mobile router attaches to another
mobile router, or a visiting mobile node attaches to a mobile
router), several encapsulations will occur on top of each other, NEMO networks,
and
a sub-optimal path will be used able to reach the destination, going
through each follow topology and every Home Agent. In order to slim this down, sev-
eral nested tunnel optimizations have been discussed.

The HMIP-like mechanisms suggested connectivity changes by updating
state information in [15] or the TLMR (Top Level
Mobile Router [11]) approach use one or more Mobile Routers chosen
for their location (closest to the Access Router) to act as proxy for
Mobile IP, and/or act as Home Agents for other mobile nodes inside
the attached mobile networks, like proposed in [14]. Instead of
adding another layer encapsulation, those TLMR switch between ingress
and egress tunnels and can reduce the amount of binding.

Similarily, ARO (Access Router Option [13]) proposes nested tunnel
optimizations based on the registration of the top level Access
Router of any nested NEMO to the Home Agent in order to bypass the
HAs of all the MR on the way to the Access Router.

On the other hand, source routing approaches like RRH (Reverse
Routing Header [12]) or Path Control Header [9] use loose source
routing in order to avoid IP encapsulation. However, source routing
is not always desirable, and might not be widely accepted.

3.2.2. Route Optimization Initiated by a Non-Mobile Router

Some approaches such as ORC (Optimized Route Cache Protocol [3]) or
other proposals using so called Anchor Routers or Correspondent side
routers (see [10] for further references), advocate the adding of new
functionalities accordingly.

Solutions must achieve their task while being conservative in some routers that are ideally chosen to be opti-
mally placed with respect to traffic flows between ASs. Those routers
intercept and terminate the tunneling on behalf of the Correspondent
Node, therefore optimizing the route from then on. However, this is
not easy to deploy, and the optimization is partial.

4. Acknowledgements

The authors would like to thank Hitachi Labs Europe for their support.

5. Authors' Addresses

Thomas Heide Clausen,
Project PCRI
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: T.Clausen@computer.org

Emmanuel Baccelli
HITACHI Labs Europe/ Project PCRI,
Pole Commun de Recherche en Informatique du plateau de Saclay,
CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
Ecole polytechnique,
Laboratoire d'informatique,
91128 Palaiseau Cedex, France
Phone: +33 1 69 33 40 73,
Email: Emmanuel.Baccelli@inria.fr

Ryuji Wakikawa
Keio University
network resource consumption and WIDE
5322 Endo Fujisawa Kanagawa
252 JAPAN
Phone: +81-466-49-1394
EMail: ryuji@sfc.wide.ad.jp
Fax: +81-466-49-1395 while avoiding prohibitively long
delays.

5. Security Considerations

This document does currently not specify security considerations.

6. IANA Considerations

This document does currently not specify IANA considerations.

7. References

[1] V. Devarapalli, R. V., Wakikawa, A. R., Petrescu, A., and P. Thubert. Nemo Thubert,
"Network Mobility (NEMO) Basic Support Protocol (work in progress). Internet Draft (draft-
ietf-nemo-basic-support-02), Internet Engineering Task Force,
December 2003. Protocol", RFC 3963,
2005.

[2] Ernst, T. Clausen, P. Jacquet, Optimized Link State Routing Protocol.
Request for Comments (Experimental) 3626, October 2003. and H-Y. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-06 (work in progress), 2006.

[3] R. Wakikawa, M. Watari. Optimized NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
Route Cache Protocol (ORC) Optimization Solution Space Analysis",
draft-ietf-nemo-ro-space-analysis-03 (work in progress). Internet Draft (draft-wakikawa-nemo-orc-00.txt),
Internet Engineering Task Force, July 2004. progress), 2006.

[4] NG, C., Zhao, F., Watari, M., and P. Thubert, N. Montavont. Nested Nemo Tree Discovery "Network Mobility
Route Optimization Problem Statement",
draft-ietf-nemo-ro-problem-statement-03 (work in
progress). Internet Draft (draft-thubert-tree-discovery-00.txt),
Internet Engineering Task Force, May 2004. progress),
2006.

[5] S. Bradner. Key Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev-
els. Request for Comments (Best Current Practice)
Levels", RFC 2119, Internet
Engineering Task Force, March 1997.

[6] C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vec-
tor (AODV) Routing, Request for Comments (Experimental) 3561, July
2003

[7] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

[8] T. Ernst, H-Y. Lach. Network Mobility Support Terminology (work in
progress). Internet Draft (draft-ietf-nemo-terminology-01), Inter-
net Engineering Task Force, February 2004.

[9] Jongkeun Na et al. Route Optimization Scheme based on Path Control
Header (work in progress). Internet Draft (draft-na-nemo-path-con-
trol-header-00), Internet Engineering Task Force, April 2004.

[10] P. Thubert et al. Taxonomy of Route Optimization models in the Nemo
Context (work in progress). Internet Draft (draft-thubert-nemo-ro-
taxonomy-02), Internet Engineering Task Force, February 2004.

[11] H. Kang et al. Route Optimization for Mobile Network by Using Bi-
directional Between Home Agent and Top Level Mobile Router (work in
progress). Internet Draft (draft-hkang-nemo-ro-tlmr-00.txt), Inter-
net Engineering Task Force, June 2003.

[12] P. Thubert et al. IPv6 Reverse Routing Header and its application
to Mobile Networks (work in progress). Internet Draft (draft-thu-
bert-nemo-reverse-routing-header-05), Internet Engineering Task
Force, June 2004.

[13] C. Ng et al. Securing Nested Tunnels Optimization with Access
Router Option (work in progress). Internet Draft (draft-ng-nemo-
access-router-option-01), Internet Engineering Task Force, July
2004.

[14] E. Perera et al. Extended Network Mobility Support (work in
progress). Internet Draft (draft-perera-nemo-extended-00.txt),
Internet Engineering Task Force, July 2003.

[15] H. Ohnishi et al. HMIP based Route Optimization Method in a Mobile
Network (work in progress). Internet Draft (draft-ohnishi-nemo-ro-
hmip-00.txt), Internet Engineering Task Force, April 2003.

[16] R.

Authors' Addresses

Emmanuel Baccelli
INRIA

Phone: +33 1 69 33 55 11
Email: Emmanuel.Baccelli@inria.fr

Thomas Heide Clausen
LIX, Ecole Polytechnique, France

Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/

Ryuji Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net-
works (work in progress). Internet Draft (draft-wakikawa-manet-
globalv6-03.txt), Internet Engineering Task Force, October 2003.

7. Changes

This is the initial version of this specification.

8. IANA Considerations

This document does currently not specify IANA considerations.

9. Security Considerations

This document does not specify any security considerations.

10.
Keio University, WIDE

Phone: +81-466-49-1394
Email: Ryuji@sfc.wide.ad.jp

Full Copyright Statement

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.

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 SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFOR-
MATION INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).