wdiff draft-wakikawa-manemo-problem-statement-00.txt draft-wakikawa-manemo-problem-statement-01.txt

No Working Group R. Wakikawa
Internet-Draft Keio University
Expires: August 9, 2007 January 10, 2008 P. Thubert
Cisco
T. Boot
Infinity Networks
J. Bound
HP
B. McCarthy
Lancaster University
February 5,
July 9, 2007

MANEMO

Problem Statement
draft-wakikawa-manemo-problem-statement-00 and Requirements for MANEMO
draft-wakikawa-manemo-problem-statement-01.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 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 August 9, 2007. January 10, 2008.

Abstract

This document outlines the fundamental problems and approach
rationale of MANEMO. When

The NEMO Basic Support protocol has well-known issues when multiple
mobile nodes converge at the edge of the
Internet using wireless interfaces, they can form a network in an ad-
hoc fashion and routers are able to provide Internet connectivity connected to one
another. This type of network is called each other in a MANEMO Fringe Stub (MFS).
Several nested fashion.
These issues exist have been already analyzed in the MFS such as network loop, un-optimized
path and multiple exit routers to the Internet. While fixed routers
provide connectivity constantly, mobile routers can experience
intermittent connectivity to the Internet due to their movement.
When NEMO Basic Support is used Working Group.
However, solutions are not yet considered and discussed in this context, network loops
naturally occur. NEMO forces the packets to always travel through the home agent, which in turn causes IETF.
MANEMO (MANET for NEMO) is an un-optimized path that can
become a considerable problem when mobile routers form a nested
topology. Multicast support introduces emphasized inefficiency.
Different types approach to resolve these issues.
Although most of routers issues are able to provide Internet connectivity
in the MFS, including both mobile routers and fixed access routers.
Any node requiring Internet connectivity has relevant to select the best exit
router toward what the Internet, therefore it MANET working group
is necessary for mobile
nodes chartered to maintain deliver, a local topology in different approach may be required. This
document identifies the MFS problems which MANEMO will solve and to utilise any
available connectivity with a degree of Intelligence. provides
the MANEMO requirements.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 5

3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Layer 3 Mesh Network . . . . . . . . . . . . . . . . . . . 9
3.2. Layer 3 Sensor Network . . . . . . . . . . . . MANEMO Characteristic . . . . . . 9
3.3. Fleet at sea . . . . . . . . . . . . . . 6

4. Problem Statements . . . . . . . . . 10
3.4. Crowd of Personal Mobile Router . . . . . . . . . . . . . 10
3.5. Deployable

5. Existing Solutions and Mobile networks . . . . . . . . . . . . . . 11
3.6. Disaster-Ready municipal network . . . . . . MANEMO approach . . . . . . . 11
3.7. Various Access Points Discovery (beyond 802.21) . . . . . 12

4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13

5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Network Loop . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Un-optimized Route . . . . . . . . . . . . . . . . . . . . 16
5.3. Multiple Exit Routers . . . . . . . . . . . . . . . . . . 18

6. Approach Rationale . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Layer 2 (mesh, spanning tree) based approach . . . . . . . 20
6.2. 802.21 based approach . . . . . . . . . . . . . . . . . . 20
6.3. MANET based approach . . . . . . . . . . . . . . . . . . . 21
6.4. Neighbor Discovery based approach . . . . . . . Requirements . . . . . 22
6.4.1. MANEMO ND and other MANET protocols . . . . . . . . . 23
6.4.2. MANEMO ND and AUTOCONF . . . . . . . . . . . . . . . . 23 14

7. Related Information . . . . . . . . . . . . . . . . . . . . . 25

8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26

9. 16

8. Security Considerations . . . . . . . . . . . . . . . . . . . 27

10. 17

9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28

11. 18

10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. 18
10.1. Normative reference . . . . . . . . . . . . . . . . . . . 28
11.2. 18
10.2. Informative Reference . . . . . . . . . . . . . . . . . . 29 19

Appendix A. Change Log From Previous Version . . . . . . . . . . 31 21

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 21
Intellectual Property and Copyright Statements . . . . . . . . . . 33 23

1. Introduction

With routers and access points now being priced as a commodity, a
cloud of

Mobile Ad-hoc Network mechanisms have been standardized for local
communication when wireless nodes are connected by wireless technology is being created at
the edge of the Internet. This cloud is called a MANEMO Fringe Stub
(MFS) in this document. The definition of all the terms used in this
document can be found in Section 2. Examples of these wireless
technologies used an ad-hoc fashion.
Several routing protocols were already standardized within a MFS are wireless metropolitan the MANET
working group and almost ready for deployment. The AUTOCONF working
group has been recently formed to standardize the IP address
configuration (both local
area network protocols (WiMAX, WLAN, 802.20, etc), short distance
wireless technology (bluetooth, irDA, UWB), address and radio mesh networks
(ex. 802.11s). As global address). On the MFS extends to other
hand, the consumer market and into NEMO working group has standardized the homes, it's ease NEMO Basic Support
Protocol [1] for global mobility of use should become comparable networks to that of
existing electrical appliances support network
movement transparency. The MANET/AUTOCONF and extension cords, i.e. highly user
friendly with little or no user interaction required. As a result,
networking in the MFS will be highly unmanaged and ad-hoc, but at NEMO working
groups discuss their solutions separately without the
same time will need to offer excellent service availability. consideration
of integrating them. In particular, the NEMO basic support [1] could be used to provide global
reachability for a mobile access network within Working Group, the MFS. However,
when Mobile Nodes attach randomly well-known
issues caused by nested NEMO are addressed. Some of them are very
similar to one another in this model (to
form what is termed a nested NEMO) the overall structure can become
highly suboptimal and loops can also possibly occur.

Therefore, there is MANET/AUTOCONF working groups deal with as a need for additional information to be made
available to Mobile Nodes to help them select an interface
problem space. However, the NEMO Basic Support protocol requires
always connected Home Agent reachability and an
attachment router over that interface network movement
transparency in order relation to reach the Internet
(possibly indirectly) in a fashion avoiding network loops. The aim
of MANEMO is to enable mobile network. These multiple effort
creates some contradiction between MANET/AUTOCONF and NEMO. We
discuss this to happen contradiction briefly in this document and also in [11].

In addition to that, the MFS through MANET protocols (DYMO [12] and OLSR [13])
may solve many of the design upcoming problems introduced by new
technologies, but implementing all functionalities of a specific MANET, tailored the MANET
routing protocols may not be always desired for some specific issues.
As the needs of nested NEMO that can
form an optimized acyclic graph directed 6lowpan Working Group works on how to the apply MANET protocols to the outside
infrastructure and the Internet when
LoWPANs (ex. RSN mailing list: Routing Sensor Network), it is reachable.

MANEMO enables a Mobile Router to install one or more default
route(s) towards the Internet and be globally reachable using NEMO.

MANEMO may also be
required to install backward routes towards
prefixes owned by a Mobile Router in each determine the possibility of either extending or
downsizing the intermediate routers
from existing MANET/ AUTOCONF solutions for the selected Exit Router down to that Mobile Router.

Finally, Internet connectivity in mobile scenarios can be costly,
limited or unavailable, therefore there is nested NEMO
problems for a need to enable local
routing between sensor network. Since the Mobile Routers nested NEMO problems are
minor issues caused only within a portion of the MFS. This
form of local routing is useful for route optimization between Mobile
Routers that are communicating directly in NEMO Basic Support model, it may
be time to look at a portion of light-weight approach for the MFS.

This type of local communication is especially an efficiency
improvement issues within the
IETF.

Solutions for multicast, as MANEMO multicast traffic could be
distributed in have already been proposed within the MFS without IETF such
as [14] and [15]. The NEMO Working Group has the analysis document
[16] for the overhead of nested tunnels NEMO issue. MANEMO is possibly related to the
following on- going work in IETF.

o Existing Routing Protocols (MANET, OSPF)

o Network Mobility Support (NEMO)

o Mobile Ad-hoc Network and Auto Configuration (AUTOCONF)

o Mobile Ad-hoc Sensor Network (6LOWPAN)
o Mobile Nodes and
pseudo-broadcasting. Multiple Interfaces in IPv6 (Monami6)

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 RFC 2119 [2]

Readers are expected to be familiar with all the terms defined in the
RFC3753 [3] and the NEMO Terminology draft [4]

Directed Graph A graph whose edges are ordered pairs

MANEMO Fringe Stub (MFS) The MANEMO Fringe Stub is a cloud of vertices.
That is, each edge Mobile
Routers connected by wireless or wired links. Any type of link
supporting IPv6 connectivity can be followed from one vertex to another
vertex.

Directed Acyclic Graph (DAG) Directed graph with no path that starts
and ends used, including partly meshed
wireless topologies. An MFS is a stub at the same vertex - in edge of the
Internet, interconnecting various types of devices which discover
each other words, loopless.

Capability, Innocuousness and Anonymity (CIA) Concepts which might
replace the traditional AAA model in some circumstances form a network in the
MFS:

Capability: Capability explores whether an Attachment Router can
actually provide the requested services (reach back to Home,
bandwidth...)

Innocuousness: Innocuousness guarantees that giving a service to
a peer (forwarding) or using a service from a peer (attaching)
is harmless ad-hoc fashion to itself.

Anonymity: Anonymity ensures that peers are unable provide
global connectivity to identify one another. This concept might contradict that of rating
peers which Many disjunctive MFS can be useful for peer
connected to peer policing (tit for
tat). the Internet. An MFS can also be floating, which
means the cloud is not connected to the Internet.

Exit Router The Exit Router is a router which provides Internet connectivity
to the Internet and acts as a layer-3 sink for the MFS. The Exit
Router can be a fixed Access Router supporting MANEMO or a mobile
router (root-MR) connected directly to the Internet. Multiple
Exit Routers may be available in an MFS.

Exit Route An Exit Route is a next hop on a Mobile Router towards an
Exit Router

Local Communication Local Communication is communication between
nodes in the same MFS without going through the Internet.

Local Routing Local Routing is a routing scheme inside a MFS.
MANEMO is used for arranging a tree structure towards the
Internet. In addition, other MANET protocols can be used to
optimise Local Communication.

MANEMO MANET for NEMO. MANEMO provides the necessary additions to
existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to
find the most suited exit towards the infrastructure. Internet. MANEMO enables
some internal connectivity within the nested NEMO whether the infrastructure
Internet is reachable or not. MANEMO is not MANET + NEMO. MANET
+ NEMO could suggest a MANET protocol reuse whereas MANET for NEMO
suggests the development of a new protocol.

MANEMO Fringe Stub (MFS)

Nested NEMO The MANEMO Fringe Stub is a cloud of Mobile
Routers connected by wireless or wired links. Any type of link
supporting IPv6 connectivity can be used, including partly meshed
wireless topologies. An MFS Nested NEMO is a stub at the edge of the
Internet, interconnecting various types of devices which discover
each other and form a network in an ad-hoc fashion to provide
Internet connectivity to configuration where one another. Many disjunctive MFS can be
connected to the Internet. An MFS can also be floating, which
means the cloud is not or
more mobile routers are connected to the Internet.

MANEMO Link A MANEMO Link is in a MANEMO enabled Mobile Router
interface and the data link layer transmission medium connected to
it. Via the link, other nodes nested formation. The
detailed issues can be reached, called found in [17] and [18].

3. MANEMO Characteristic

Before discussing the 1st hop
neighbors. detail of MANEMO Path A problems, we highlight the
characteristics of MANEMO Path is Fringe Stub (MFS) by comparing it with a
traditional ad-hoc network path between a (MANET) in this section.

Mobile Router
and the root routers of RFC3963 are the MANEMO Tree, the Exit Router. For Local
Communication, core nodes of an up-tree and down-tree path provides connectivity
within a MANEMO tree.

MANEMO Tree MFS. A MANEMO Tree is the simplest mobile
network topology
connecting Mobile Routers within a MFS to served by a single Exit Router.
The Exit Router mobile router is the root of the MANEMO Tree. In case of a
floating MFS, a Mobile Router shall be elected seen as root of the
MANEMO Tree.

Wireless Node A Wireless Node is a node that has a wireless link to
access the Internet. Example Wireless Nodes are a Mobile Node
(Mobile Host or Mobile Router) and a normal IPv6 node [5] with a
wireless link.

Nested NEMO The Nested NEMO network.
It is possible for a network configuration where one or
more mobile router to connect to another mobile
router's mobile network. As a result, mobile routers are connected in nested formation. The
detailed issues can be found in [13]
and [14].

Self Optimizing A Self-Optimizing network is form a self-forming, self-
healing network that adapts its nested topology dynamically in order to
optimize some metrics.

3. Use cases

3.1. Layer 3 Mesh Network

A layer 3 mesh network which is a specific case of known as nested NEMO with very,
very slow inner movements of Mobile Routers relative NEMO. In MFS,
not only mobile routers, but also mobile hosts, fixed nodes (host and
router) are considered. Fixed hosts and routers can be connected to
one another.
Change of attachment will be triggered by node additions and
interference, rather than actual displacement.

The mesh network is self-forming the mobile networks and self-healing. It forms a tree
that is rooted at can also be located in the nearest Exit Router (wire access). The tree
will self-heal should a node fail, a radio link become unavailable
(for a temporary interference), or Internet.
Access routers to provide wireless connectivity are also considered
as a node or a wire access within an MFS. All these nodes may be added
to involved within the network.
MANEMO protocol. Figure 1 shows the abstract topology of mobile
routers. Two exit routers (ER1 and ER2) are identified and each
number indicates a mobile router. In order to deploy a mesh network easily, the inner addressing should
be independent of highlight the wire accesses. The MANEMO protocol should
enable packets transmitted from Mobile Routers visiting
characteristic, we only show the mesh to
enter mobile routers in the Internet via an Exit Router with a topologically correct
address even though topology. We
discuss all the inner mesh addresses may be only unique local
addresses.

3.2. Layer 3 Sensor Network

A Sensor Network is an extreme form possible topologies of a MANET mobile routers in MFS in terms of the amount
of devices and of their highly limited capabilities. Sensors can be
low cost, mass produced devices operating
MANEMO architecture [11]. Each mobile router owns an assigned prefix
from its home agent. The prefix is configured for years on a pair of AAA
batteries. mobile network.
A sensor dust can be spread over mobile router acquires a monitored location,
and from that moment on, topologically correct address (care-of
address) at the sensors are fixed egress interface and operate for tunnels all the
lifetime of their batteries, which are their most critical resource.

Around a Sensor Network, sinks are deployed in order data to collect the
measurements from the sensors and relay its home
agent by using the commands from care-of address.

Although MANET supports Internet connectivity, because of NEMO Basic
Support, the
controllers. Thus, sensors automatically form reachability to its home agent for home registration is
a structure fundamental aspect of MANEMO. Without home registration, it cannot
communicate to forward
unicast packets from the sensors other nodes with its mobile network prefix according
to RFC3963. If the sinks, and to propagate
broadcast packets across binding registration is completed, all the network
traffic from the sinks.

The sensors act as a community, relaying packets for one another; but mobile network is tunneled to the model reaches its limits due in home agent. In
NEMO context, at least one hand exit router for MFS is required. MR1 and
MR3 of Figure 1 can be away from the wireless attach facility and
loose connectivity to the operational cost network. The disconnected MFS can also
occur. Moreover, on the batteries for listening to asynchronous packets from other
sensors and for forwarding, and in MANEMO mailing list, we currently discuss
the other hand to case when each mobile router is connected by the complexity
involved in forming an ad-hoc network over a large area.

In order to establish a routing infrastructure egress interface
and scale to forms a large
geography, Mobile Routers MANET-like network. This case can be deployed to form a mesh and act seen as
default gateways to backhaul and aggregate "mobile
routers forming a mobile ad-hoc network". Except for the sensor data. In that
case, most sensors could be either plain IPv6 hosts or at least be
optimized assigned
prefix to relay over a limited area towards each mobile router, the nearest Mobile
Router.

The Mobile Routers themselves might characteristic of this scenario may
be actually fixed and well-
distributed across same as mobile ad-hoc network.

+-------------------+ Internet (Wired/Wireless)
| | |
| | \|/
ER1 ER2 /|\
| / |
1---2 3 |
|\ / | Wireless Links
4 5---6---7----8--9 |
| \ \ |
10---11 12 13---14 \|/

Figure 1: Example Topology

Figure 2 shows the monitored location, with a few difference of them
equipped communication model between MANET
and MANEMO. A mobile router (MR6) communicates with a backhaul capability to the Infrastructure. They
could also be in fact another mobile and appear, move and disappear, for
instance as a drone passes over the sensor field to sweep a
perimeter.
router (MR14) . The MANEMO protocol must ensure Figure 2-a shows the basic MANET communication
model. MANET protocols maintain local routing information so that
they can communicate directly inside this ad-hoc network. Even if
there are multi-paths between nodes, most of the Exit Route(s) is
found and maintained as quickly as possible.

Finally, a possible flow MANET routing
protocols select the shortest path in sensor networking is default. If many sessions are
in process within the polling of network, the
sensors by an application. congestion at some links can be
obviously observed. The application request is multicast links between MR6 to
all sensors, and the sensors reply MR8 in a synchronized fashion. In
that flow, Figure 2 may
become possible bottlenecks if many nodes are communicating at the command might interfere with itself as it is repeated
over
same time. Figure 2-b, on the radios. Also, other hand, shows the sensor responses might interfere with one
another. The MANEMO protocol should aim at minimizing interference
with itself
communication model. The default communication path between MR6 and could provide extensions
MR14 is through the Internet. Each mobile router transmits packets
to transport and aggregate
sensor data.

3.3. Fleet at sea

In the case of a fleet at sea, exit router even if the MFS destination node is moving together, with maybe
temporary splits and merges. Also, when located nearby.
Thus, packets are traveled over the fleet Internet (through several home
agents if it is at sea, the
communications to the outside can be costly.

In this use case, some ships may have well defined roles (like
admiral ship, communications ships etc...) required) and therefore some
additional engineering maybe required when considering the routing.
For example, it may be desirable that certain specific ships be
identified as preferred Exit Routers (root-MR) for the MANEMO.

As opposed routed to the mesh networking and sensor networking cases, the
fleet at sea involves inner movements within the fleet as demanded by exit router to which the missions. As a result, some part of
destination mobile router belongs. Even if the fleet might split from path length may
increase, the rest but still maintain local connectivity using MANEMO, as well
as connectivity with path over the rest of Internet is often more reliable than the fleet using NEMO. In
particular,
shortest link. Note that it is possible true that the comms ship may act as a Mobile
Home for the fleet aggregation.

3.4. Crowd of Personal Mobile Router

Another use case is a crowd of personal Mobile Routers. In this use
case, people do not know each other but need to forward each others
packets to link between ER1-MR1
and ER2-MR3 become the nearest Exit Router in order bottleneck for all the whole system to
operate for everyone. Also, traffic coming in this situation people may move quite
rapidly relative to one another therefore the density and
out of the crowd MFS. Additional latency may also be observed, but it is a
trade-off of significance.

In this sort several aspects such as latency, congestion, reliability
and costs of unmanaged environment we cannot rely on a traditional
(AAA, trust based) mechanism. Instead, the MANEMO protocol must
enable MRs local routing management (MANET routing protocol). In
MANEMO, it is still possible to obtain maintain the required Capabilities in an Innocuous
fashion. MANEMO has neighboring mobile
routers. End nodes can communicate to enable and optimize the trade-off between
ensuring some reciprocity (TIT for TAT) and maintaining a safe degree
of Anonymity between destination directly along
the peer Mobile Routers.

3.5. Deployable and Mobile networks

A task-group could perform activities in a planned matter in an area
that lacks a capable data communication infrastructure. In such a
case, shortest path (not through the infrastructure would exit routers). Each mobile router
should be embedded in able to decide whether the task-group itself.
The used infrastructure would be heterogeneous; using whatever
wireless or wired technology that is allowed, applicable, affordable
and available.

During their task, elements such as ships, vehicles, airborne
elements and temporally used buildings, tents packets are routed to the exit
router or other setups mostly
have fixed locations, to the destination directly. MANEMO does not identify how
to manage local routing, but elements can relocate in a planned or
unplanned manner. During relocation, the data communication
facilities can be shut down or kept active. Shut down data
communication facilities would be classified as "on primarily goal is to manage the hold" or "on path
to the pause". Data communication facilities that are active during
relocation are classified exit router as "on the move". Networks with a high
degree of stationary elements are called "Deployable networks";
relocation would normally be planned. Networks with default.

(Internet)
+===== HAn =======+
ER1 ER2
|| //
1---2 3 1---2 3
|\ / |\\ //
4 5---6<==7====8--9 4 5==>6---7----8--9
| \ \\ | \ \\
10---11 12 13==>14 10---11 12 13==>14

a) MANET b) MANEMO

Figure 2: Communication Model

When a high degree mobile router changes its point of
mobility are called "Mobile Networks" and planning activities would
be minimal. Deployed Mobile Networks have both ingredients.

Deployable and Mobile networks are being used by military forces, oil
and mineral recovery undertakings and large scale events. They can
also be added to Disaster-Ready municipal networks.

3.6. Disaster-Ready municipal attachment, it must hide
the changes from any nodes located in its mobile network

Several Groups like MetroNet6 [1]. Since
nodes in the US and U-2010 in Europe mobile network are
considering solutions which would enable a quick restoration of
communications after a disaster. This kind moved all together, sets of problem has many
facets, and MANEMO aims at solving implied the connectivity issues to
provide a Disaster-Ready municipal network or a fast deployable mobile network.

A municipal Network is Disaster Ready if the networking operations
routers can move at once in MFS. Nodes can be restored quickly during the normally chaotic phase that
follows an IPv6 node, a disaster (earthquake, flood, tsunami, volcano). Though mobile
host of RFC3775, and a
large part mobile router of the municipal network might be utterly destroyed, the
goal is to leverage whatever infrastructure is left to restore
connectivity as soon as possible.

This requires RFC3963. For instance, in
Figure 3, a municipal network with self-forming, self-healing
characteristics. In addition, this requires the ability to support
the dynamic reintroduction mobile router (MR4) moves its point of additional/replacement materials that
will recombine with attachment. Even
if MR4 moves, the surviving infrastructure in an effort movement has minimum impact to
complete it any nodes including
mobile routers (MR10 and further bolster the available coverage. In other
words MR11) located in the municipal MR4's mobile network.
The mobile network nodes must collaborate with the emergency
Mobile Routers, which will be automatically supported if the mesh
network technology is compatible with that completely unaware of the Mobile Routers.

For movement.
On the MANEMO protocol, this means that Mobile Routers (in trucks,
Personal Mobile Routers, etc...) can be deployed other hand, within most of the disaster
area MANET and restore connectivity in AUTOCONF schemes, the part(s)
change of MR4's attachment effects the city mesh that
are still operational but isolated, and extend the connectivity in neighboring nodes (possibly
the areas that are not covered.

3.7. Various Access Points Discovery (beyond 802.21)

IEEE 802.21 working group has been developing a mechanism to support
optimized handover and interoperability between heterogeneous
networks. The current set entire network). Most of 802.21 standards are not well designed
to support mobile wireless access networks, though the 802.21 Working
Group has not excluded supporting mobile access networks in routing protocols require the
future.

Once Mobile Routers route
re-calculation or route re-discovery (route maintenance) when
topology changes are well deployed in vehicles, personal devices,
etc., occurred. This should be avoided because it is expected that we will begin to see access networks that
are on the move. Within
breaks the current 802.21 standards, this moving
access network is not considered. The 802.21 Information Service
(IS) system cannot provide complete information nature of neighboring
networks to users, because the IS basically deals with static types
of information. Therefore, a user will obtain information NEMO basic support protocol. A detailed
explanation can be found in [11].

+------------------+ +------------------+
ER1 ER2 ER1 ER2
| / | /
1---2 3 ==> 1---2 3
|\ / \ /
|4| 5---6---7----8--9 5---6---7----8--9
| \ \ \ \
10---11 12 13---14 12 13---14
|
Router-4 moves to Router-12 |4|
>|
> 10---11
^^^^^^^

movement transparency

Figure 3: Movement Model

Another aspect of static
neighboring networks from IS and acquire information about possible MANEMO characteristic is that each mobile access networks (Exit Routers) router
can be connected by using MANEMO.

The best access network for users might depend on more than layer 2
and location knowledge. For instance, a passenger in different wireless technology, while a vehicle (i.e.
bus/train) should stick default
MANET assumption is to the access provided by that vehicle while use a stationary passenger located single wireless interface in the station should get access from
a fixed resource. Some of the required information ad-hoc mode
(ex. 802.11b ad-hoc mode). Each mobile router has, at least two
interfaces such as egress and ingress interfaces. For example, MR3
connects to make the
proper decision is available from layer 3 ER2 by 3G (HSDPA), MR3 and above, as well as from
the user himself.

MANEMO should define MR8 are connected by 802.11b,
MR8 and utilize means for discovering MR13 are by 802.11g, and selecting
the best access network for users. so on. as described in Figure 4. Requirements

MANEMO has the following requirements:

R1: The MANEMO protocol must enable the discovery of multihop
topologies at layer

+------------------+
ER1 ER2
| WiMAX / <-3G(HSDPA)
1---2 3 from mere reachability and elaborate links
for IPv6 usage, regardless of the wired or wireless media.

R2:
|\ / <-wifi(802.11b)
4 5---6---7----8--9
| \ \ <-wifi(802.11g)
10---11 12 13---14
wifi(802.11a)

Figure 4: Movement Model

The MANEMO protocol must enable packets transmitted from Mobile
Routers visiting final difference is the MFS to reach routing capability. In MANET, each
router can route the Internet via an optimized
path towards packet received at the nearest Exit Router, manet interface [19]. A
route can receive a packet from a manet interface and back.

R3: MANEMO must enable IP connectivity within the nested NEMO
whether can send the infrastructure is reachable or not.

R4: The MANEMO protocol must enable packets transmitted
packet from Mobile
Routers visiting the MFS same manet interface according to reach the Internet with a
topologically correct address.

R5: The MANEMO protocol should aim at minimizing radio interference
with itself as the control messages get propagated its routing table.
However, in the MFS.

R6: MANEMO protocol must enable inner movements within MFS to occur,
and ensure details of this movement are not propagated beyond NEMO Basic Support model, a mobile router can route
only the
MFS.

R7: An MFS may split to become two separate MFSs, in this case
MANEMO will continue tunneled packet to maintain local connectivity within the
separate MFSs and connectivity between the MFSs will be restored
once a NEMO connection becomes available.

R8: The MANEMO protocol should enable and optimize from its mobile network. Without the trade-off
between ensuring some reciprocity between MFS peers and
maintaining a safe degree of CIA (see Paragraph 3 in
bi- directional tunnel, the
terminology section (Section 2)) properties between mobile router never routes the peer
Mobile Routers.

R9: The MANEMO protocol should enable that Mobile Routers be
deployed non-
tunneled packet according to restore connectivity in parts of an MFS went isolated,
or extend the connectivity in the areas that are not covered.

R10: [1]. The solution MUST not require modifications to any node other
than nodes that participates packet sent from the ingress
interface is always routed to the MFS. It must support fixed
nodes, mobile hosts and mobile routers in the NEMOs that form the
MFS, and ensure backward compatibility with other standards
defined router's home agent by the IETF.

R11: using
IP encapsulation. The MANEMO protocol shall enable multicast communication, for
nodes within the MFS and on the Internet. Translation of MANEMO
multicast signaling and multicast signaling on the Internet shall
take place on incoming packets must always be tunneled from
the Exit Router.

R12: The MANEMO protocol shall optimize mobile router's home agent except for the path packets sent to the Internet
using cross-layer metrics.

5.
mobile node itself.

4. Problem Statement Statements

Radio connectivity and movement have disrupted the concept of a link
as we know it in the wired environment. Specific modes for specific
radios are proposed to restore that concept, which is essential for
IP operations, as single hop (802.11 infrastructure mode) or multihop
(802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified
solution to reconstruct a minimum topological abstraction at layer 3
for the use of NEMO.

The MANEMO problem is problems are already observed in several Working Groups
and some are specified in [15][14].

The MANEMO [17], [20]

1. Sub-optimal route and Redundant tunnel: This issue is possibly related to following on-going work described
in IETF

o Existing Routing Protocols (MANET, OSPF)

o Network Mobility Support (NEMO)

o Mobile Ad-hoc Network Section 2.1, 2.3 and Auto Configuration (AUTOCONF)

o Mobile Ad-hoc Sensor Network (6LOWPAN)

o Mobile Nodes 2.6 of [17] and Multiple Interfaces in IPv6 (Monami6)

The main problems are "Network Loop", "Un-optimized Route", and
"Multiple Appendix B.1, B.2,
B.3, B.4 of [17].

2. No Communication capability without Home Agent Reachability: This
issue is described in Section 2.6 of [17]

3. Exit Router Selection: This problem occurs when a mobile node
obtains multiple Exit Routers toward the Internet. In the
illustrated case, the mobile node should attempt to obtain some
information about each Exit Router in order to more efficiently
utilize them. MANEMO may carry this information about each Exit Routers"
Router and present it to the connected mobile node.

. .

5.1. . . . . . . . . . ..
. .
. The Internet .
. .
.. . . . . . . . . . . .
| |
+-+-+ +-+-+
|AR1| |AR2+--+
+-+-+ +-+-+ |
| +---+ | |
+-----|MR1|----+ |
+-+-+ |
| +-+-+
+--------+MR2|
+---+

Figure 5: Multiple Exit Routers

4. Network Loop Loop: A network loop can occur when multiple mobile
routers are nested and suddenly the Exit Router (root-MR, i.e.
MR1) looses connectivity to the Internet and connects to the
mobile network of a lower hierarchical MR (i.e. MR2 in the figure)
figure). In this case, the loop is observed between MRs. mobile
routers. Each mobile network is designed to have movement
transparency by from the NEMO Basic Support Protocol. Any node
connecting to a mobile network cannot know whether the access
network is a mobile network or not. Moreover, it is impossible
to know whether a connecting mobile router has managed Internet
connectivity or not. The mobile router may loose Internet
Connectivity, temporarily.

Knowing the topology of MFS is highly important to prevent this
network loop issue.

+---+ +---+

Internet Internet
| |
+-+-+ +-+-+
|AR | |AR |
+-+-+ +---+
|
|
+-+-+ +---+
|MR1| --> |MR1+--+ |MR1+->+
+-+-+ +-+-+ |
| | /|\ |
| | |
+-+-+ +-+-+ | \|/
|MR2| |MR2|--+ |MR2|<-+
+---+ +---+

Figure 1: 6: Network Loop

5.2. Un-optimized Route

This is well known issue of Nested NEMO. The problem is described in

Section 2.3 of [13]. The NEMO Working Group suggests not to prevent
support for nested NEMO. [6]. Figure 2 shows a typical example of
nested NEMO. Even if the destination is in the same MFS, the packets
are always traveled through multiple home agents. There are several
proposal in the NEMO Working Group.

+---+ +---+ +---+ +---+
|HA1| |HA2| |HA3| |HA4|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
| | | |
+. . . . . . . . . . . . .+
: :
: The Internet :
: :
+. . . . . . . . . . . . .+
|
+-+-+ The Path From MR1 to MR4
| AR| [MR1->AR->HA1->HA4->HA2->HA1->AR->
+-+-+ MR1->MR2->MR4]
|
+-+-+ The Path From MR3 to MR4
|MR1| [MR3->MR2->MR1->AR->HA1->HA2->HA3->
+-+-+ HA4->HA2->HA1->AR->MR1->MR2->MR4]
|
+---+ +-+-+ +---+
|MR3|----+MR2+----+MR4|
+---+ +---+ +---+

Figure 2: Nested NEMO

Figure 3 shows the another example of un-optimized path. This
redundant path is also occurred in no nested NEMO scenario. In this
example, two mobile routers are not directly connected. Most 4.8 of [20] discussed the
nested solution proposed in NEMO working group cannot solve this
case. MANEMO solution should be able to solve this case, too.

+---+ +---+ +---+ +---+
|HA1| |HA2| |HA1| |HA2|
+-+-+ ++--+ +-+-+ ++--+
| | | |
| | | |
+.+. . . . . . . . ..+.+ +.+. . . . . . . ..+.+
. . . .
. The Internet . . The Internet .
. . . .
+. . . . . . . . . . . + +. . . . .+. . . .. . +
| |
+-+-+ +----R-----+
+---+ AR+---+ | |
| +-+-+ | +-+-+ +-+-+
| | +---+AR1| |AR2+---+
| | | +---+ +---+ |
+-+-+ +-+-+ +-+-+ +-+-+
|MR1| |MR2| |MR1| |MR2|
+-+-+ +-+-+ +-+-+ +-+-+

MR1->AR->HA1->HA2->AR->MR2 MR1->AR1->R->HA1->HA2->R->AR2->MR2

Figure 3: Unoptimized Route

5.3. Multiple Exit Routers

This loop problem occurs when a mobile node obtains multiple Exit Routers
toward the Internet. In the illustrated case,
router is multihomed.

5. Existing Solutions and MANEMO approach

Several approaches can be taken for the mobile node should
attempt to obtain some information about each Exit Router problems listed in order to
more efficiently utilize them. MANEMO may carry this information
about each Exit Router Section 4.
Some analysis can be found in [21].

[MANET Routing Protocol and present it to AUTOCONF] While manet routing protocols
maintain the connected mobile node.

. . . . . . . . . . . ..
. .
. The Internet .
. .
.. . . . . . . . . . . .
| |
| |
+-+-+ +-+-+
|AR1| |AR2+--+
+-+-+ +-+-+ |
| +---+ | |
+-----|MR1|----+ |
+-+-+ |
| +-+-+
+--------+MR2|
+---+

Figure 4: Multiple Exit Routers

6. Approach Rationale local connectivity, the primary goal of MANEMO aims at extending IPv6 Neighbor Discovery [7] is to form
discover an exit router and to maintain an optimized nested NEMO. This section covers the rationale
behind this approach.

6.1. Layer 2 (mesh, spanning tree) based approach

Arguably, an existing layer 2 technology such as a spanning tree of
802.11s could be used path to establish a tree towards the nearest Exit
Router. This falls short when Internet
through the nodes are mobile routers exit router for a
number of reasons:

In a L2 based solution, binding registration and traffic over
the MRs would end up bridging bidirectional tunnel. Only for the
nested routers while this purpose, MANET routing for their own (attached) Mobile
Network Prefixes.

A L3 based solution could span over multiple radio types, such as:
802.16 or 11a for backhaul, 802.11a or 11b/g for edge and 802.11
b/g or 802.15.4 for access. It also could span wired links.

In an L3 solution, you control the broadcast domain and limit the
multicast troubles without snooping. In particular, you segment
the ND broadcast operations.

NEMO operation is better if the MANEMO operation is done in ND at
L3, because NEMO already interfaces with ND. A L2 solution would
require NEMO to understand L2/2.5
protocols have excess functionalities such as like 802.11s flooding messages
for route discovery or 802.21.

There can be value in integration between the NEMO and the MANET
aspects route updates, etc. The primary goal of
the mobility problem. For instance, if the Reverse
Routing Header technique [16] MANET routing protocols is used to solve the pinball routing
problem, then maintain local connectivity.
However, the RRH can local connectivity management should not be compressed dynamically if routes down
the tree (or the DAG) are installed by mandated
to the MANEMO protocol in the
intermediate routers.

And then you get all the IP value that is not necessarily there or
homogeneous at L2, like QoS, SNMP, RSVP, aggregation, etc...

6.2. 802.21 based approach

In some scenarios, the information service approach solution, although MANEMO may be taken.
For example, trains are run on a regular schedule and a system can
preempt the movement of mobile routers on each train. In such a
case, the operator can dynamically update interested in the information of routers
local routing in a train to the information service (IS). future. The mobile node can
retrieve information about NEMO Basic Support protocol
basically requires tunneling the neighboring access networks from IS in
some scenarios. Unless packets to the IS supports dynamic updates of access
routers and provides certain topology of mobile access routers, it Internet. NHDP
[22] is
difficult alternate solution to solve all the problems of MANEMO. For instance, discover neighboring nodes, but it does
not enable us to structure the nested NEMO in an optimal fashion for
reaching the infrastructure.

6.3. MANET based approach

The Mobile Ad-hoc Network Architecture [17] provides an overview of
the MANET problem and scope.

MANEMO
is about designing a specific MANET that is tailored for the
needs of nested NEMO, with a strong focus on finding the way limited to the
outside infrastructure when it only two hop neighbors' information. There is reachable. In that sense, MANEMO
specializes on a specific area of MANET by adding a set of
constraints
case that narrow the problem down.

Arguably, an existing MANET protocol could be used to enable routing
between exit router is more than 2 hops away. The AUTOCONF
working group discusses the Mobile Router within a nested NEMO. But existing MANET
are not optimized address assignment scheme for ad-hoc
networks. However, the following requirements:

Default Route: Because it addressing architecture is used by Mobile Routers to find a way
out and bind to their Home Agent, slightly
different from what the MANEMO NEMO basic support protocol focuses on
building, maintaining and optimizing a default path to the exit of
the nested NEMO. With MANET, the default route is usually an
addition, and expecting.
More details can be found in any case it [11].

[NEMO Route Optimization Scheme] There is just another route, not the focus
of no route optimization
scheme in IETF. Only the protocol.

Prefix Routing: Subnet (prefix) routing analysis document is a secondary concern for
the MANEMO protocol. Such routes are considered when conditions
permit, but might be maintained available in a Least Overhead Routing
Approach (LORA) as opposed [16].

Contrary to an Optimized Routing Approach (ORA)
which is used for the Default Route. Host Routes are not of
concern since existing solutions, MANEMO deals with Mobile Routers. Note that DYMO
and OLSR are capable of the prefix routing.

Group Management: When forming a nested NEMO, the Mobile Routers
need arranges a selection of information that is not present in traditional
MANET approaches. Notions such as group, depth, free bandwidth tree structure
towards the exit, etc... impact the formation of the nested NEMO
and the way it optimizes itself overtime.

On the other hand, existing MANET protocols could be integrated or
adapted for Internet. This tree is the following cases:

On-demand Routing: When a node needs simplest network topology
connecting Mobile Routers within an MFS to discover a single Exit Routers, on-
demand fashion may reduce Router. The
Exit Router is the overhead root of discovery procedure.
Some MANET routing protocols such as AODV and DYMO has the on-
demand mechanism to discover a route towards the destination.

Neighborhood Routing: Because the MANEMO protocol provides only a
minimized view of the local network, it might be missing a short
path to a neighborhood destination over an alternate radio link.
A collaboration with a MANET protocol would improve short-distance
routing. As an example, internal connectivity between NEMOs
within Tree. The packets from MFS are
routed along the local network may improve by Mobile Routers running a
MANEMO routing protocol tree and discovering more optimal routes are routed to the
MNPs reachable within the local network. Mechanisms specific destination. Routing to
MANEMO
multiple home agents should also be developed to ensure this optimisation is
safe.

Global Reachability avoided as much as possible. Basic
required functionalities for a MANET In the MANET working group, MANEMO are:

1. Discovering and Selecting exit routers

2. Forming loop-free Tree by making an
Internet Gateway is introduced to provide Internet connectivity to
MANET. In this case, the gateway of a MANET network is also exit router as a
NEMO Mobile Router. Using NEMO, The gateway registers root

3. Maintaining the MANET
prefix(es) path to a Home Agent, enabling the MANET network to move as
a whole. The Mobile Router can also act as a Mobile exit router

4. Bypassing Home Agents for the
whole MANET, providing Home Agent services such as mobility and
prefix delegation. In particular, the Mobile Home can maintain
connectivity with Mobile IP6/NEMO enabled MANET Nodes that would
stray away traffic from the mobile MANET.

For these reasons, MANET could contribute in optimizing a deployment,
but a specific protocol has to be engineered to match the MFS

The MANEMO
requirements.

6.4. Neighbor Discovery based approach work focus is on a Neighbor Discovery (ND) [7] [5] based
solution that is required to provide multihop reachability while
supporting the inner movements within the nested NEMO. ND provides
the means to discover neighbors and the prefix on a link, which are
pervasive across IPv6 nodes and link types. Mobile IPv6 [8] [6] and NEMO
[1] rely heavily on ND for roaming and Home Link activities.
Considering that NEMO already uses ND for Router Discovery, it makes
sense to extend ND in MANEMO as opposed to providing a second peering
mechanism.

ND has already been extended to expose some layer 3 information, such
as router selection hints [9]. [7]. ND is consistently being improved for
mobility, in particular with Mobile IPv6 [8] [6] and DNA, DNA [23], and for
security with Secure ND [10]. [8]. ND operates on bidirectional links,
whereas this is a restriction from the MANET standpoint, this
condition enables simpler solutions for MANEMO. Neighbor Discovery
is well suited for providing hints for composing a path to the
Internet access router. The hits could include Layer 2
information as well as application layer information, needed for
providing optimal and stable paths to Exit Routers. The Exit Routes connect the MANEMO Fringe Stub MFS to the Internet. Path maintaining
towards an Exit Router is suggested in a nested NEMO tree discovery
protocol [18].

Multicast support could be provided by using the loop-free MANEMO
Tree to forward packets to the Internet. Down-tree forwarding would
use MLD-proxy[19], MLD-proxy [24], either with native MLD [11][12] [9][10] / ICMP packets or
send with the ND extensions to increase efficiency. Multicast
forwarding rules should be validated, mechanisms like RPF-check and
duplicate packet detection [20] would be used to eliminate multicast
looped packets. Forwarding rules on

6. Requirements

MANEMO has the Exit Router is to be worked
out.

The following requirements:

R1: MANEMO work will thus focus on an ND based solution that is
required to provide must enable the discovery of multihop topologies at layer
3 from mere reachability while supporting inner
movements in the nested NEMO.

6.4.1. MANEMO ND and other MANET protocols

The MANEMO ND provided information can be used by other MANET
protocols. Other MANET protocols could be used elaborate links for optimize local
connectivity IPv6 usage,
regardless of the wired or used for other reasons. wireless media.

R2: MANEMO ND may provide IP link and address topology vectors to the must enable packets transmitted from nodes next hop neighbors. Then that topology information at each
next hop neighbor would be propagated visiting the
MFS to reach the Internet via an OLSRv2 [21] / NHDP [22]
symmetric 2-hop neighborhood and Multipoint Relay, or OSPF-MANET [23]
/ [24] MANET Designated Router (most likely Parent optimized path towards the
nearest Exit Router, and Routable
characteristics) who then can flood that topology to other Multipoint
Relays or MANET Designated Routers down to other neighbors. This
also could be accomplished using NEMO/MANEMO Access Routers to back.

R3: MANEMO must enable IP connectivity within the
NEMO Clusterhead using MFS whether
Internet is reachable or not.

R4: MANEMO must enable packets transmitted from nodes visiting the proposed tree discovery protocol [18].
The diameter of
MFS to reach the topology would span Internet with a single ad hoc link. This
would provide an IP layer 3 solution and topologically correct address.

R5: MANEMO should aim at minimizing radio interference with itself
as the topology information
could be placed control messages get propagated in new ND options.

6.4.2. the MFS.

R6: MANEMO ND must enable inner movements within MFS to occur, and AUTOCONF

The use
ensure propagating details of ND for IP link and address topology could also foster this movement is kept at a
discussion with IETF AUTOCONF Working Group to analyze if ND could be
used as defined above minimum.

R7: An MFS may split to support ND stateless autoconfiguration. The
design center for such a solution would be become two separate MFSs, in this case
MANEMO must continue to place maintain local connectivity within the
separate MFSs and connectivity between the split MFSs. MFSs may
merge, in this ND link case inner MFS connectivity optimization must be
restored.

R8: MANEMO should enable and
IP topology enhancement below current MANET routing protocols optimize the trade-off between ensuring
some reciprocity between MFS peers and
could reduce latency for ad hoc links whether within maintaining a MESH or Radio
Network link. ND extensions could assist greatly below MANET routing
protocols to discover neighbors, verify two way communications,
exchange link state information, and provide update information safe degree
of CIA properties between neighbors and ingress/egress point to MANET the peer Mobile Routers.
These extensions could also be applied as enhancements

R9: MANEMO must support ad-hoc operation, for isolated MFSs (R3) and
multi-hop access to the tree
discovery protocol Internet (R2).

R10: MANEMO must not require modifications to any node other than
nodes that would support MANEMO, thus adding these
extensions participates to tree discovery protocol is a suggestion or it could be
its own specification.

7. Related Information

Related Documents can be found the MFS, including HA. It must support
fixed nodes, mobile hosts and mobile routers in the Informative Reference section

Solutions are already proposed at IETF such as [16] MFS, and [18]. The
NEMO Working Group has
ensure backward compatibility with other standards defined by the analysis document [25]
IETF.

R11: MANEMO should enable multicast communication, for nodes within
the nested NEMO
issue.

8. MFS and on the Internet.

R12: MANEMO must optimize the path to the Internet using cross-layer
metrics.

R13: MANEMO may provide direct peer to peer reachability for nearby
nodes.

7. IANA considerations

This document does not require any IANA action.

8. Security Considerations

This document is a problem statement and does not create any security
threat. It discusses the concepts of Capability, Innocuousness and
Anonymity in a nested NEMO.

10.

9. Acknowledgments

We would like to thank all the people who have provided comments on
this draft, and also co-authors of earlier documents in which authors
of this present document have been engaged. As such, we would like
to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham
Soliman, Carlos Jesus Bernardos Cano and many others.

11.

10. References

11.1.

10.1. Normative reference

[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.

[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.

[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-06 (work in progress),
November 2006.

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

[6] Ernst, T., "Network Mobility Support Goals and Requirements",
draft-ietf-nemo-requirements-06 (work in progress),
November 2006.

[7] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[8]

[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.

[9]

[7] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005.

[10]

[8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

[11]

[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.

[12]

[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.

11.2.

10.2. Informative Reference

[13] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-03

[11] Wakikawa, R., "MANEMO Topology and Addressing Architecture",
draft-wakikawa-manemoarch-00 (work in progress), September 2006.

[14] Clausen, T., Baccelli, E., July 2007.

[12] Perkins, C. and R. Wakikawa, "NEMO Route
Optimisation Problem Statement",
draft-clausen-nemo-ro-problem-statement-00 I. Chakeres, "Dynamic MANET On-demand (DYMO)
Routing", draft-ietf-manet-dymo-10 (work in progress),
October 2004.

[15] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-06
July 2007.

[13] Clausen, T., "The Optimized Link State Routing Protocol version
2", draft-ietf-manet-olsrv2-03 (work in progress),
June 2006.

[16] March 2007.

[14] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-06
draft-thubert-nemo-reverse-routing-header-07 (work in
progress), February 2007.

[15] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-06 (work in progress), July 2007.

[16] Ng, C., "Network Mobility Route Optimization Solution Space
Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in
progress), September 2006.

[17] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
progress), September 2006.

[18] Clausen, T., "NEMO Route Optimisation Problem Statement",
draft-clausen-nemo-ro-problem-statement-01 (work in progress),
March 2007.

[19] Chakeres, I., "Mobile Ad hoc Network Architecture",
draft-chakeres-manet-arch-01 (work in progress), October 2006.

[18] Thubert, P., "Nested Nemo Tree Discovery",
draft-thubert-tree-discovery-04 (work in progress),
November 2006.

[19] Janneteau,

[20] Ng, C., "IPv6 Multicast for Mobile Networks with MLD-
Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work "Analysis of Multihoming in
progress), April 2004.

[20] Macker, J., "Simplified Multicast Forwarding for MANET",
draft-ietf-manet-smf-03 Network Mobility Support",
draft-ietf-nemo-multihoming-issues-07 (work in progress), October 2006.
February 2007.

[21] Clausen, Boot, T., "The Optimized Link-State Routing Protocol version
2", draft-ietf-manet-olsrv2-02 "Analysis of MANET and NEMO",
draft-boot-manet-nemo-analysis-01 (work in progress),
June 2006. 2007.

[22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-00
draft-ietf-manet-nhdp-04 (work in progress), June 2006. July 2007.

[23] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS
Flooding", draft-ogier-manet-ospf-extension-08 (work Kempf, J., "Detecting Network Attachment in
progress), October 2006.

[24] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile
Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-06 (work in progress), January
June 2007.

[25] Ng,

[24] Janneteau, C., "Network Mobility Route Optimization Solution Space
Analysis", draft-ietf-nemo-ro-space-analysis-03 "IPv6 Multicast for Mobile Networks with MLD-
Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in
progress), September 2006. April 2004.

Appendix A. Change Log From Previous Version

o Initial Documentation Removed Use-Case Scenarios

o Updated the Section4: use the references to existing documents

o Removed the Approach Rationale

Authors' Addresses

Ryuji Wakikawa
Department of Environmental Information, Keio University and WIDE
5322 Endo Fujisawa
Fujisawa, Kanagawa
252-8520
JAPAN
Japan

Phone: +81-466-49-1100
Fax: +81-466-49-1395
Email: ryuji@sfc.wide.ad.jp
URI: http://www.wakikawa.org/

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

Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com

Teco Boot
Infinity Networks B.V.
Elperstraat 4
Schoonloo 9443TL
Netherlands

Phone: +31 592 50 12 66

Email: teco@inf-net.nl
Jim Bound
Hewlett-Packard
PO BOX 570
Hollis, NH 03049
USA

Phone: +603 465 3130
Email: jim.bound@hp.com

McCarthy Ben
Lancaster University
Computing Department, Lancaster University.
InfoLab 21, South Drive
Lancaster, Lancashire LA1 4WA
UK

Phone: +44-1524-510-383
Fax: +44-1524-510-492
Email: b.mccarthy@lancaster.ac.uk
URI: http://www.network-mobility.org/

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