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

Network Working Group P. Thubert
Internet-Draft M. Molteni
Expires: December 2, 2003 August 15, 2004 Cisco Systems
C. Ng
Panasonic Singapore Labs
June 3, 2003
H. Ohnishi
NTT
E. Paik
Seoul National Univ.
February 15, 2004

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

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

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.

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

This Internet-Draft will expire on December 2, 2003. August 15, 2004.

Abstract

Nemo

NEMO enables Mobile Networks by extending Mobile IP to support Mobile
Routers. This paper memo documents how the MIPv6 concept of Route
Optimization can to be adapted for Nemo NEMO to optimize: optimize traffic routing
between nodes in a mobile network and their correspodnet nodes.
Different route optimizations schemes are discussed, including:

1. the nested tunnels route optimization with corresponding nodes initiated bu mobile
routers on behalf of the nested Nemo configuration mobile network nodes;

2. router-to-router in a visiting mobile node performing MIPv6 RO over the NEMO base
protocol;

3. performing RO over the routing infrastructure as opposed involving
optimizing the route between two routers situated near to end-to-end. each
end point, instead of end-to-end; and much more ... :)

4. minimizing the number of tunnels required when there is multiple
levels of nesting.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Nested Mobile Network MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Nested Tunnels
3. MIPv6 Route Optimization over NEMO . . . . . . . . . . . . . . 4
4. Optimization within the infrastructure . 3
2.1.1 Pitfalls and threats . . . . . . . . . . . 4
4.1 Route Optimization within a ISP network . . . . . . . . 7
2.1.1.1 Securing the protocol . . . 5
4.2 Correspondent Router . . . . . . . . . . . . . . . . . 7
2.1.1.2 Recursive complexity . . . . 6
4.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . . . 7
2.2 Route Optimization inside the
5. Nested Mobile Network . . . 8
3. MR-to-CN . . . . . . . . . . . . . . . . . 8
5.1 Nested Tunnels Optimization . . . . . . . . 9
4. MIPv6 . . . . . . . . . 8
5.2 Route Optimization over Nemo inside the Nested Mobile Network . . . . . 12
6. General Considerations . . . . . . . 9
5. Optimization within the infrastructure . . . . . . . . . . 9
5.1 Route Optimization within a ISP network . . . 12
6.1 Securing the protocol in nested tunnels optimization . . . . . 12
6.2 Recursive complexity in route optimization . 10
5.2 Correspondent Router . . . . . . . . . 12
6.3 Mobile Access router selection . . . . . . . . . . . 11
5.3 Distributed Anchor Routers . . . . . 13
6.4 Mobility transparency and RO . . . . . . . . . . . 12
6. Conclusion . . . . . . 14
6.5 Multihoming Considerations . . . . . . . . . . . . . . . . . . 13 15
7. Acknowledgements Conclusion . . . . . . . . . . . . . . . . . . . . . 13
References . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . 15
References . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . 16
Authors' Addresses . . . . . . . . . . 16 . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 19

1. Introduction

This document assumes the reader is familiar with Mobile IPv6 defined
in [1], with the concept of Mobile Router (MR) and with the Nemo
terminology defined in [2].

From the discussions on the mailing list, it appears that the common
current understanding of the problem space of Route Optimization
(RO), in the Nemo context, is still limited.

This paper draft attempts to clarify the state of the discussion and
propose a taxonomy of the various aspects of the problem. We will
look at different possible types of route optimizations related to
mobile network.

Firstly, route optimizations involving nested mobile networks are
explored. This involves minimizing the number of tunnels required
when there is multiple levels of nesting.

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

Thirdly,

Secondly, we consider the feasibility of having a visiting mobile
node (VMN) performing MIPv6 RO over the NEMO base protocol.

Lastly,

Thirdly, we explore the prospect of performing RO over the routing
infrastructure. This involve involves optimizing the route between two
routers situated near to each end point.

Lastly, route optimizations involving nested mobile networks are
explored. This involves minimizing the number of tunnels required
when there is multiple levels of nesting.

2. MR-to-CN

This section covers the case where the Route Optimization is
performed between the MR and the correspondent nodes which mobile
network nodes (MNNs) are communicating with. This scenario is useful
when a lot of MNNs in a mobile network 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 this form of optimization is that the end-to-end
principle of the MIPv6 Reverse Routability (RR) test is broken. The
RR test is meant to ensure the care-of address (CoA) and the home
address (HoA) are collocated. With a mobile network, when the MR
performs RO on behalf of the MNNs, the CoA 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 the fly by the MRs but it seems that
a clean MR-to-CN optimization for Nemo will impact the CN function.

Once we modify the CN behavior, we need to introduce a negotiation
from the start of the RR test to determine the protocol. In
particular, the Mobile Node and the CN must decide whether checking
the collocation is possible, and if not, whether a CN is willing to
accept the risk. If not, the optimization may be limited to
triangular routing MR->CN->HA->MR.

This is a major evolution from [1], since MIPv6 has no such
negotiation capability at 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 the mobile node will have to be routed
not only to its home agent but also the home agent of the mobile
router. This pattern resembles Nested NEMO case which is described 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 the Infrastructure is the
same as if the Mobile Network

2.1 was attached at the attachment point of
the Mobile Router (i.e., there is not additional Tunneling that is
linked to NEMO).

A possible approach to this is to extend the solution for nested
mobile network optimization 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 Route Optimization is
performed within the Routing Infrastructure. This model is useful
when an ISP wants to control the route optimization procedures and
does not desire to add any functions to the CN or the MR in order to
achieve route optimizations between CN and LFN.

In this model, both the LFN behind the MR and the Correspondent can
be MIP agnostic. The drawback is the introduction of Mobile Routes in
specific Routers, causing additional signaling 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 of the MR. This C-side Router can terminate MIP on behalf 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 Mobile
Router ################################ Router
|
====Mobile Network=======

Optimization in 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 of
the traffic:

Egress

The MR locates the C-side Router, establishes a 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 of the traffic from the
Correspondent Node to the Home Agent. Also, it is aware of the MR
and the mobile network behind the MR and establishes the
appropriate tunnel and route. After this, it is able to reroute
traffic to the mobile network over the tunnel to the MR.

4.1 Route Optimization within a ISP network

This form of Route Optimization provides local savings for an ISP.
This idea was described 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 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.
This is 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 #
| o | # n #
| #################################### ?
| CR oooooooooooooooooooooooooooooooooooooo Mobile
| #################################### Router
| | |
+-------------------+ ===========Mobile Network========

Correspondent Router

The MR locates the CR for a given Correspondent and establishes a
Tunnel to the CR for that destination and its prefix(es). Then, the
CR establishes the Tunnel back to the MR and the Mobile Routes to the
MR's Mobile Networks via that Tunnel.

A key point is that the CR must be on the interception path of the
traffic from the Correspondent to the Mobile Networks in order 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 the Mobile Routes on the fly, or within rate and
amount limits. Garbage Collection is done at appropriate time to
limit the perturbation on the Routing.

Default Router

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

Core Routers

The Core Routers for the network of the Correspondent are all CRs.
If the path from the correspondent to the Home Agent does not pass
via a CR, then it's not worth optimizing. If it is, then the CRs
are on the way. Again, redistribution is not needed.

4.3 Distributed Anchor Routers

Taking the idea of a correspondent router a step further, it is
possible to have a distributed set of anchor routers across the
Internet. Outgoing packets sent from a mobile network will be
tunneled to one of the nearest anchor router (instead of to the home
agent of the mobile router). This M-Side (Mobile Network Side)
anchor router will decapsulate the packet, inspect the destination,
and tunnel the packet to another anchor router situated near the CN
(C-Side Anchor Router). From there, the packet will be decapsulated
and forwarded to the CN.

Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent
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

The C-Side Anchor Router will be subjected to the same condition as
listed 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 to a triangular routing
(i.e. packet sent by CN will still go through the home agent of the
mobile network).

The anchor router share many similarities with the concept of
Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)
[9]. In fact, it can be combined with HMIPv6 whereby each M-Side
anchor router is also an MAP, and the MR obtains a regional
care-of-address from the MAP.

5. Nested Mobile Network

5.1 Nested Tunnels Optimization

This section covers the case where one mobile network is within
another mobile network. For example, a user brings a Personal Area
Network (PAN) consisting of some IP devices to a train which is also
using NEMO technology. In another example, a car which conatins a
mobile network moves into the ferry which has another mobile network.
This configuration of mobile networks within another mobile network
is called nested Mobile Networks.

Let us illustrate the problem by an example. In this example, the
nested Mobile Network has a tree topology. In the tree each node is a
basic Mobile Network, represented by its MR.

+---------------------+
| Internet |---CN
+---------------|-----+
/ Access Router
MR3_HA |
======?======
MR1
|
====?=============?==============?===
MR5 MR2 MR6
| | |
=========== ===?========= =============
MR3
|
==|=========?== Net3
LFN1 MR4
|
=========

An example nested Mobile Network

This example focuses on 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 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 CN replies back.

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

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

No Nested Tunnels Optimization

Such a solution introduces the following problems:

"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 below shows the route taken by a packet sent from LFN
to CN:

'Pinball' Routing

Packet size

An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [4] 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 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 TLMRs. The
TLMRs subdivide some of their address space 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 of
the Mobile Network. As Mobile Router, they also terminate their
home Tunnels. As routers, they forward packets between the 2
tunnels.

Surrogate

The TLMR acts as a proxy in the MIP registration, in a fashion of
MIPv4 Foreign Agent or HMIP MAP (see [8]). [9]). For instance, the TLMR
maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and
switches packets between the two.

Internal Routing and gateway

This item can be approached from a MANET standpoint. This was
already done for DSR (see [9]) [10]) and AODV (see [10] [11] and [7]) [8]) From a
Nemo standpoint, a full MANET is not necessary since the goal is
to find a way to the infrastructure, as opposed to any-to-any
connectivity.

RRH

The Reverse Routing Header (RRH) approach avoids the multiple
encapsulation of the traffic but maintains the home tunnel of the
first MR on the egress path. It is described in details in [5].
The first MR on the way out (egress direction) encapsulates the
packet over 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 in the RRH. The HA transforms the RRH
in a Routing Header to perform a Source Routing across the nested
Mobile Network, along the ingress path to the target MR.

Access Router Option

The Access Router Option (ARO) approach [6] is somewhat similar to
the RRH in that only the home tunnel of the first MR in the egress
path is maintained. This is done by having MR to send an ARO in
Binding Update to inform its HA the address of its access router.
Using this information, HA can build a Routing Header to source-
route
source-route a packet to the target MR within in a nested mobile
network. Details can be found in [6].

2.1.1 Pitfalls

Prefix delegation approach

The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo
is to MIPv6. The Access Router of the nested structure is both a
Nemo Home Agent and threats

2.1.1.1 a DHCP-PD server, for an aggregation that it
owns and advertises to the Infrastructure. When visiting the
nested structure, each MR is delegated a mobile network prefix
from the AR using DHCP-Prefix Delegation. The MR registers this
delegated MNP to the AR that is acting as a Nemo Home Agent. The
MR also autoconfigures an address from the delegated MNP and uses
it as a CareOf to register its own MNPs to its own Home Agent
using Nemo basic support. It is possible for a MR to protect its
own MNPs while advertising in the clear the local MNP for other
MRs to roam in. This allows a strict privacy 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 a mobile network is not within the
charter of the NEMO working group, it might be insightful to discuss
such optimizations.

The expectation is that the mobile routes installed by NEMO can
cohabit with a MANET support that would perform the RO inside the
Nested Mobile Network. In other words, MIP redistributes its prefixes
locally to a MANET and the MR-HA tunnel is bypassed.

6. General Considerations

6.1 Securing the protocol in nested tunnels optimization

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

Even if an intermediate MR is 'trusted', this does not prove it is
able to provide the necessary bandwidth, and may not provide a good
service. Eventually, a MR that is capable of securing (IPSec) its
traffic may select a Mobile Access Router based on quality of service
heuristics as opposed as trust.

The problem is global to the whole Mobile Network in the case of a
MANET-based solution. For an RRH-based solution, the threat comes
from on-axis MRs in the nested Mobile Network but is mostly limited
to denial of service. This is detailed in [5]. The approach taken is
to limit the threat to Black Hole and Grey Hole by using IPSec.

2.1.1.2

6.2 Recursive complexity in route optimization

A number of drafts and publications suggest -or can be extended to- a
model where the Home Agent and any arbitrary Correspondent would
actually get individual binding from the chain of nested Mobile
Routers, and form a routing header appropriately.

An intermediate MR would keep track of all the pending communications
between hosts in its subtree of Mobile Networks and their CNs, and a
binding message to each CN each time it changes its point of
attachment.

If this was done, then each CN, by receiving all the binding messages
and processing them recursively, could infer a partial topology of
the nested Mobile Network, sufficient to build a multi-hop routing
header for packets sent to nodes inside the nested Mobile Network.

However, this extension has a cost:

1. Binding Update storm

when one MR changes its point of attachment, it needs to send a
BU to all the CNs of each node behind him. When the Mobile
Network is nested, the number of nodes and relative CNs can be
huge, leading to congestions and drops.

2. Protocol Hacks

Also, in order to send the BUs, the MR has to keep track of all
the traffic it forwards 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 of the CN becomes heavy, because it has to
analyze each BU in a recursive fashion in order to infer nested
Mobile Network topology required to build a multi hop routing
header.

4. Missing BU

If a CN doesn't receive the full set of PSBU sent by the MR, it
will not be able to infer the full path to a node inside the
nested Mobile Network. The RH will be incomplete and the packet
may or may not be delivered.

5. Obsolete BU

If the Binding messages are 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 the
CN maintains is highly unstable. If only one BU in the chain is
obsolete due to the movement of an intermediate MR, the
connectivity may be lost.

2.2 Route Optimization inside the Nested Mobile Network

This is not part of the Nemo Charter.

The expectation is that the mobile routes installed by Nemo can
cohabit with a MANET support that would perform the RO inside the
Nested

6.3 Mobile Network. Access router selection

In other words, MIP redistributes its
prefixes locally to a MANET and the MR-HA tunnel is bypassed.

3. MR-to-CN

This section covers the case where the Route Optimization is
performed between the MR and the Correspondent Node.

A major issue is that the MIPv6 Reverse Routability test is broken,
since it is meant some case, nested Mobile Networks attaches to ensure visiting network
with multiples mobile access router that the CoA (the MR) an the Home Address
(the Mobile Node) are collocated. With a Mobile Network, a LFN is
reachable via the Care-Of Address, but not at the Care-Of Address.
Some tricks may be performed on the fly by the MRs but it seems that
a clean MR-to-CN optimization for Nemo will impact the CN function.

Once we modify the CN behavior, we need to introduce a negotiation
from the start of the RR test to determine the protocol. In
particular, the Mobile Node and the CN must decide whether checking
the collocation is possible, and if not, whether a CN is willing gateways to
accept the risk. If not, the optimization global
internet. These RO methods may be limited to
triangular routing MR->CN->HA->MR.

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

4. MIPv6 Route Optimization over Nemo

When a Mobile Node visits a Mobile Network, the best Route
Optimization is obtained if cover the path function in which how the Infrastructure is the
same as if MR
in the nested Mobile Network was attached at choose the attachment point one of the Mobile Router (i.e., there is not additional Tunneling that is
linked to Nemo).

A possible approach to this is to extend the solution for nested mobile network optimization 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.

5. Optimization within the infrastructure access
routers. This section elaborates on cases where the Route Optimization function is
performed within the Routing Infrastructure. In this model, both the
LFN behind the MR not explicitly described in current
methods and the Correspondent can needs to be MIP agnostic. The
drawback is the introduction discussed.

6.4 Mobility transparency and RO

[cwng's interpretation of Mobile Routes Mobility Transparency in specific Routers,
causing additional signaling and load to the Routing Fabric.

The general idea is that there RO]

It is a correspondent-side Router desirable in the
infrastructure mobility-related protocols that is located "closer" to the Correspondent than the
HA. That Router can terminate MIP on behalf mobility of the CN.

Optimization in the Infrastructure

This optimization is only valid when the path via the correspondent-
side Router a
mobile node is shorter than the path via transparent to other entities and other layers in the Home Agent.
mobile node. The Optimization can take place independently for the 2 directions Basic NEMO support achieve this mobility
transparency of the traffic:

Egress

The MR locates mobile network to the correspondent-side Router, establishes MNNs by a Tunnel
with MR-HA tunnel so
that Router and sets a route to the Correspondent via the
correspondent-side Router over the Tunnel. At this point, the
traffic to the Correspondent does MNNs need not flow via the Home Agent
anymore.

Ingress

The correspondent-side Router is on the way of the traffic from
the Correspondent to the Home Agent. Also, it is be aware of the MR
and the Mobile Networks behind the MR and establishes the
appropriate Tunnel and Route. At that point, it is able to
reroute the traffic to the Mobile Network over the Tunnel to the
MR.

5.1 Route Optimization within a ISP network

This form of Route Optimization provides local savings for a ISP.
This idea was described MR's change in Ohnishi's Mobile Border Gateway draft.
The goal is to locate the closest (BGP) gateway for a Correspondent
that is located outside point of the domain, and tunnel between the MR and
that gateway
attachment.

Such a feature is, as opposed mentioned, desirable. However, when route
optimizations, end-to-end principle, and other factors come into
consideration, achieving mobility transparency may not be practical.

For instance, to the Home Agent for that specific
Correspondent.

5.2 Correspondent Router

A globally better optimization is obtained if the achieve nested tunnel from optimizations, the mobility of
the top-level MR is terminated closer often exposed to other entities, such as the destination on the Correspondent side.
This is the role HA
of a Correspondent Router (CR).

Correspondent Router

The MR locates the CR for a given Correspondent and establishes a
Tunnel to the CR for that destination and its prefix(es). Then, the
CR establishes the Tunnel back to nested MR. In the case of MR and the Mobile Routes to the
MR's Mobile Networks via that Tunnel.

A key point is that the CR must performing BU for MNNs, it might
be on the interception path necessary to pass mobility information of the
traffic from the Correspondent MR to the Mobile Networks CN (and even
MNN) in order not to
reroute break the traffic over end-to-end principle. For the appropriate Tunnel. This can be
achieved in several fashions:

Redistribution

There's a limited Number
scenario of CRs that cover an Autonomous System.
They redistribute the Mobile Routes on optimization using infrastructure, the fly, or within rate and
amount limits. Garbage Collection is done at appropriate time mobility
information might be necessarily exposed to
limit the perturbation on the Routing.

Default Router

The CR is a Default Router for the Correspondent, correspondent routers or for the whole
AS of the Correspondent (it's
MAP.

Thus, one should bear in mind when designing RO solution that a border gateway).
sacrifice might be necessary when weighing conflicting factors such
as mobility transparency, optimization level, and end-to-end
integrity.

[Hosik's interpretation of Mobility Transparency in RO]

In this case,
redistribution is not needed.

Core Routers

The Core Routers for the network case of the Correspondent are all CRs.
If the path from the correspondent to the Home Agent does not pass
via a CR, then it's not worth optimizing. If it is, then the CRs
are on the way. Again, redistribution extended support of NEMO such as nested NEMO, mobility
transparency is desirable but that is not needed.

5.3 Distributed Anchor Routers

Taking mandatory for the idea of a correspondent router a step further, it is
possible to have a distributed set
efficiency of anchor routers across the
Internet. Outgoing packets sent from a mobile network will be
tunneled to one of route optimization. For example, the nearest anchor router (instead of notebook and
PDA inside a vehicle can access to the home
agent of Internet through the mobile router). This M-Side (Mobile Network Side)
anchor
router will decapsulate of the packet, inspect vehicle. In that case, if the destination,
and tunnel movement of the packet vehicle
affects to another anchor router situated near the CN
(C-Side Anchor Router). From there, notebook or the packet will be decapsulated
and forwarded PDA, they can perform individual
binding update operation to the CN.

Optimization correspondent node or its home agent
but that can cause location privacy problem.

[Onishi's interpretation of Mobility Transparency in RO]

In RO solutions, MR can optimize the Infrastructure

The C-Side Anchor Router will route between its own HA and MR.
It is desirable that communication can not be subjected to the same condition as
listed in the previous sub-section if packets sent from interrupted by this
route optimization. ????

6.5 Multihoming Considerations

In multihomed mobile networks, route optimization is dependant on how
the CN connections to the
mobile network Internet are available and selected.

In case of macro mobility, we may have multiple HAs from place to
place. New route optimization could be route-optimized too. Otherwise, the
solution will only partially optimize routing to a triangular routing
(i.e. packet sent possible by routing between CN will still go through the home agent
and one of the
mobile network).

The anchor router share many similarities with multiple Home Agents (possibly using differenc Home
Addresses).

When multiple connections are available for the concept purpose of
Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)
[8]. In fact, it can be combined with HMIPv6 whereby each M-Side
anchor router is also an MAP, and the MR obtains fault
tolerance, a regional care-of-
address from selection mechanism is needed for CN to eveluate the MAP.

6.
connection availability in order to perform route optimization.

7. Conclusion

The Problem space of Route Optimization in the Nemo NEMO context is
multifold and can be split is 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 Nemo NEMO Charter. On the other hand, MIPv6 seems to be evolving in a
direction that makes it more and more difficult to provide a Nemo NEMO
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. HAO.

The authors intent is to trigger fruitful discussions that in turn
will enhance our common understanding of the problem space so that at
some point, this paper turns into a problem statement for the Nemo
Route Optimization.

8. Acknowledgements

The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki
Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji
Wakikawa and Patrick Wetterwald for their various contributions.

References

[1] Perkins, C., Johnson, D. D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", draft-ietf-mobileip-ipv6-21 draft-ietf-mobileip-ipv6-24 (work in progress), March July
2003.

[2] Lach, H. and T. Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-00 (work in progress), May 2003.

[3] Kniveton, T., kniveton, t., "Mobile Router Tunneling Protocol", draft-
kniveton-mobrtr-03 Support with Mobile IP",
draft-kniveton-mobrtr-02 (work in progress), November July 2002.

[4] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-
deletion-00
draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
November 2001.

[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks", draft-thubert-nemo-
reverse-routing-header-01
draft-thubert-nemo-reverse-routing-header-04 (work in
progress), October 2002. February 2004.

[6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization
with Access Router Option", draft-ng-nemo-access-router-option-
00
draft-ng-nemo-access-router-option-00 (work in progress),
November 2002.

[7] 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 for IPv6 Mobile Ad Hoc
Networks", draft-wakikawa-manet-globalv6-02 draft-wakikawa-manet-globalv6-03 (work in progress),
November 2002.

[8]
October 2003.

[9] Soliman, H., Castelluccia, C., Malki, K., Soliman, H. K. and L. Bellier,
"Hierarchical Mobile IPv6 MIPv6 mobility management (HMIPv6)", draft-
ietf-mobileip-hmipv6-07
draft-ietf-mobileip-hmipv6-06 (work in progress), October July 2002.

[9]

[10] Johnson, D., Maltz, D., Broch, J. and J. Jetcheva, "The Dynamic Source Routing Protocol for Mobile Ad
Hoc Networks", draft-
ietf-manet-dsr-07 Networks (DSR)", draft-ietf-manet-dsr-09 (work in
progress), February 2002.

[10] Das, S., April 2003.

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

[11] July 2002.

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

[12]

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

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

EMail: cwng@psl.com.sg

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
Eun Kyoung Paik
Seoul National University
Shillim-dong, Kwanak-gu
Seoul 151-744
KOREA

EMail: eun@mmlab.snu.ac.kr

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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 does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
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 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 assigns. assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.

Acknowledgement

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.