No Working Group R. Wakikawa
Internet-Draft Keio University
Expires: August 9, 2007 P. Thubert
Cisco
T. Boot
Infinity Networks
J. Bound
HP
B. McCarthy
Lancaster University
February 5, 2007
MANEMO Problem Statement
draft-wakikawa-manemo-problem-statement-00
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wakikawa, et al. Expires August 9, 2007 [Page 1]
Internet-Draft MANEMO Problem Statement February 2007
Abstract
This document outlines the fundamental problems and approach
rationale of MANEMO. When mobile nodes converge at the edge of the
Internet using wireless interfaces, they can form a network in an ad-
hoc fashion and are able to provide Internet connectivity to one
another. This type of network is called a MANEMO Fringe Stub (MFS).
Several issues exist 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 in this context, network loops
naturally occur. NEMO forces the packets to always travel through
the home agent, which in turn causes an un-optimized path that can
become a considerable problem when mobile routers form a nested
topology. Multicast support introduces emphasized inefficiency.
Different types of routers are able to provide Internet connectivity
in the MFS, including both mobile routers and fixed access routers.
Any node requiring Internet connectivity has to select the best exit
router toward the Internet, therefore it is necessary for mobile
nodes to maintain a local topology in the MFS and to utilise any
available connectivity with a degree of Intelligence.
Wakikawa, et al. Expires August 9, 2007 [Page 2]
Internet-Draft MANEMO Problem Statement February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Layer 3 Mesh Network . . . . . . . . . . . . . . . . . . . 9
3.2. Layer 3 Sensor Network . . . . . . . . . . . . . . . . . . 9
3.3. Fleet at sea . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Crowd of Personal Mobile Router . . . . . . . . . . . . . 10
3.5. Deployable and Mobile networks . . . . . . . . . . . . . . 11
3.6. Disaster-Ready municipal network . . . . . . . . . . . . . 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 . . . . . . . . . . . . 22
6.4.1. MANEMO ND and other MANET protocols . . . . . . . . . 23
6.4.2. MANEMO ND and AUTOCONF . . . . . . . . . . . . . . . . 23
7. Related Information . . . . . . . . . . . . . . . . . . . . . 25
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative reference . . . . . . . . . . . . . . . . . . . 28
11.2. Informative Reference . . . . . . . . . . . . . . . . . . 29
Appendix A. Change Log From Previous Version . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Wakikawa, et al. Expires August 9, 2007 [Page 3]
Internet-Draft MANEMO Problem Statement February 2007
1. Introduction
With routers and access points now being priced as a commodity, a
cloud of nodes 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 within a MFS are wireless metropolitan and local
area network protocols (WiMAX, WLAN, 802.20, etc), short distance
wireless technology (bluetooth, irDA, UWB), and radio mesh networks
(ex. 802.11s). As the MFS extends to the consumer market and into
the homes, it's ease of use should become comparable to that of
existing electrical appliances 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 the
same time will need to offer excellent service availability.
In particular, NEMO basic support [1] could be used to provide global
reachability for a mobile access network within the MFS. However,
when Mobile Nodes attach randomly 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 a need for additional information to be made
available to Mobile Nodes to help them select an interface and an
attachment router over that interface in order to reach the Internet
(possibly indirectly) in a fashion avoiding network loops. The aim
of MANEMO is to enable this to happen in the MFS through the design
of a specific MANET, tailored for the needs of nested NEMO that can
form an optimized acyclic graph directed to the to the outside
infrastructure and the Internet when 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 of the intermediate routers
from the selected Exit Router down to that Mobile Router.
Finally, Internet connectivity in mobile scenarios can be costly,
limited or unavailable, therefore there is a need to enable local
routing between the Mobile Routers within a portion of the MFS. This
form of local routing is useful for route optimization between Mobile
Routers that are communicating directly in a portion of the MFS.
This type of local communication is especially an efficiency
improvement for multicast, as MANEMO multicast traffic could be
distributed in the MFS without the overhead of nested tunnels and
Wakikawa, et al. Expires August 9, 2007 [Page 4]
Internet-Draft MANEMO Problem Statement February 2007
pseudo-broadcasting.
Wakikawa, et al. Expires August 9, 2007 [Page 5]
Internet-Draft MANEMO Problem Statement February 2007
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 of vertices.
That is, each edge can be followed from one vertex to another
vertex.
Directed Acyclic Graph (DAG) Directed graph with no path that starts
and ends at the same vertex - in other words, loopless.
Capability, Innocuousness and Anonymity (CIA) Concepts which might
replace the traditional AAA model in some circumstances 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 to itself.
Anonymity: Anonymity ensures that peers are unable to identify
one another. This concept might contradict that of rating
peers which can be useful for peer to peer policing (tit for
tat).
Exit Router The Exit Router is a router which provides Internet
connectivity 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.
Wakikawa, et al. Expires August 9, 2007 [Page 6]
Internet-Draft MANEMO Problem Statement February 2007
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. MANEMO
enables some internal connectivity within the nested NEMO whether
the infrastructure 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) 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 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 one another. Many disjunctive MFS can be
connected to the Internet. An MFS can also be floating, which
means the cloud is not connected to the Internet.
MANEMO Link A MANEMO Link is a MANEMO enabled Mobile Router
interface and the data link layer transmission medium connected to
it. Via the link, other nodes can be reached, called the 1st hop
neighbors.
MANEMO Path A MANEMO Path is a network path between a Mobile Router
and the root of the MANEMO Tree, the Exit Router. For Local
Communication, an up-tree and down-tree path provides connectivity
within a MANEMO tree.
MANEMO Tree A MANEMO Tree is the simplest network topology
connecting Mobile Routers within a MFS to a single Exit Router.
The Exit Router is the root of the MANEMO Tree. In case of a
floating MFS, a Mobile Router shall be elected 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 is a network configuration where one or
more mobile routers are connected in nested formation. The
detailed issues can be found in [13] and [14].
Wakikawa, et al. Expires August 9, 2007 [Page 7]
Internet-Draft MANEMO Problem Statement February 2007
Self Optimizing A Self-Optimizing network is a self-forming, self-
healing network that adapts its topology dynamically in order to
optimize some metrics.
Wakikawa, et al. Expires August 9, 2007 [Page 8]
Internet-Draft MANEMO Problem Statement February 2007
3. Use cases
3.1. Layer 3 Mesh Network
A layer 3 mesh network is a specific case of nested NEMO with very,
very slow inner movements of Mobile Routers relative to one another.
Change of attachment will be triggered by node additions and
interference, rather than actual displacement.
The mesh network is self-forming and self-healing. It forms a tree
that is rooted at 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 a node or a wire access be added
to the network.
In order to deploy a mesh network easily, the inner addressing should
be independent of the wire accesses. The MANEMO protocol should
enable packets transmitted from Mobile Routers visiting the mesh to
enter the Internet via an Exit Router with a topologically correct
address even though the inner mesh addresses may be only unique local
addresses.
3.2. Layer 3 Sensor Network
A Sensor Network is an extreme form of a MANET in terms of the amount
of devices and of their highly limited capabilities. Sensors can be
low cost, mass produced devices operating for years on a pair of AAA
batteries. A sensor dust can be spread over a monitored location,
and from that moment on, the sensors are fixed and operate for the
lifetime of their batteries, which are their most critical resource.
Around a Sensor Network, sinks are deployed in order to collect the
measurements from the sensors and relay the commands from the
controllers. Thus, sensors automatically form a structure to forward
unicast packets from the sensors to the sinks, and to propagate
broadcast packets across the network from the sinks.
The sensors act as a community, relaying packets for one another; but
the model reaches its limits due in one hand to the operational cost
on the batteries for listening to asynchronous packets from other
sensors and for forwarding, and in the other hand to the complexity
involved in forming an ad-hoc network over a large area.
In order to establish a routing infrastructure and scale to a large
geography, Mobile Routers can be deployed to form a mesh and act as
default gateways to backhaul and aggregate the sensor data. In that
case, most sensors could be either plain IPv6 hosts or at least be
optimized to relay over a limited area towards the nearest Mobile
Wakikawa, et al. Expires August 9, 2007 [Page 9]
Internet-Draft MANEMO Problem Statement February 2007
Router.
The Mobile Routers themselves might be actually fixed and well-
distributed across the monitored location, with a few of them
equipped with a backhaul capability to the Infrastructure. They
could also be in fact mobile and appear, move and disappear, for
instance as a drone passes over the sensor field to sweep a
perimeter. The MANEMO protocol must ensure that the Exit Route(s) is
found and maintained as quickly as possible.
Finally, a possible flow in sensor networking is the polling of the
sensors by an application. The application request is multicast to
all sensors, and the sensors reply in a synchronized fashion. In
that flow, the command might interfere with itself as it is repeated
over the radios. Also, the sensor responses might interfere with one
another. The MANEMO protocol should aim at minimizing interference
with itself and could provide extensions to transport and aggregate
sensor data.
3.3. Fleet at sea
In the case of a fleet at sea, the MFS is moving together, with maybe
temporary splits and merges. Also, when the fleet 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...) 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 to the mesh networking and sensor networking cases, the
fleet at sea involves inner movements within the fleet as demanded by
the missions. As a result, some part of the fleet might split from
the rest but still maintain local connectivity using MANEMO, as well
as connectivity with the rest of the fleet using NEMO. In
particular, it is possible 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 the nearest Exit Router in order for the whole system to
operate for everyone. Also, in this situation people may move quite
rapidly relative to one another therefore the density of the crowd
may be of significance.
Wakikawa, et al. Expires August 9, 2007 [Page 10]
Internet-Draft MANEMO Problem Statement February 2007
In this sort of unmanaged environment we cannot rely on a traditional
(AAA, trust based) mechanism. Instead, the MANEMO protocol must
enable MRs to obtain the required Capabilities in an Innocuous
fashion. MANEMO has to enable and optimize the trade-off between
ensuring some reciprocity (TIT for TAT) and maintaining a safe degree
of Anonymity between 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, the infrastructure would be embedded in 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 or other setups mostly
have fixed locations, 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 the hold" or "on
the pause". Data communication facilities that are active during
relocation are classified as "on the move". Networks with a high
degree of stationary elements are called "Deployable networks";
relocation would normally be planned. Networks with a high degree 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 network
Several Groups like MetroNet6 in the US and U-2010 in Europe are
considering solutions which would enable a quick restoration of
communications after a disaster. This kind 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
can be restored quickly during the normally chaotic phase that
follows a disaster (earthquake, flood, tsunami, volcano). Though a
large part of the municipal network might be utterly destroyed, the
goal is to leverage whatever infrastructure is left to restore
connectivity as soon as possible.
Wakikawa, et al. Expires August 9, 2007 [Page 11]
Internet-Draft MANEMO Problem Statement February 2007
This requires a municipal network with self-forming, self-healing
characteristics. In addition, this requires the ability to support
the dynamic reintroduction of additional/replacement materials that
will recombine with the surviving infrastructure in an effort to
complete it and further bolster the available coverage. In other
words the municipal network must collaborate with the emergency
Mobile Routers, which will be automatically supported if the mesh
network technology is compatible with that of the Mobile Routers.
For the MANEMO protocol, this means that Mobile Routers (in trucks,
Personal Mobile Routers, etc...) can be deployed within the disaster
area and restore connectivity in the part(s) of the city mesh that
are still operational but isolated, and extend the connectivity in
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 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 the
future.
Once Mobile Routers are well deployed in vehicles, personal devices,
etc., it is expected that we will begin to see access networks that
are on the move. Within the current 802.21 standards, this moving
access network is not considered. The 802.21 Information Service
(IS) system cannot provide complete information of neighboring
networks to users, because the IS basically deals with static types
of information. Therefore, a user will obtain information of static
neighboring networks from IS and acquire information about possible
mobile access networks (Exit Routers) by using MANEMO.
The best access network for users might depend on more than layer 2
and location knowledge. For instance, a passenger in a vehicle (i.e.
bus/train) should stick to the access provided by that vehicle while
a stationary passenger located in the station should get access from
a fixed resource. Some of the required information to make the
proper decision is available from layer 3 and above, as well as from
the user himself.
MANEMO should define and utilize means for discovering and selecting
the best access network for users.
Wakikawa, et al. Expires August 9, 2007 [Page 12]
Internet-Draft MANEMO Problem Statement February 2007
4. Requirements
MANEMO has the following requirements:
R1: The MANEMO protocol must enable the discovery of multihop
topologies at layer 3 from mere reachability and elaborate links
for IPv6 usage, regardless of the wired or wireless media.
R2: The MANEMO protocol must enable packets transmitted from Mobile
Routers visiting the MFS to reach the Internet via an optimized
path towards the nearest Exit Router, and back.
R3: MANEMO must enable IP connectivity within the nested NEMO
whether the infrastructure is reachable or not.
R4: The MANEMO protocol must enable packets transmitted from Mobile
Routers visiting the MFS 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 in the MFS.
R6: MANEMO protocol must enable inner movements within MFS to occur,
and ensure details of this movement are not propagated beyond the
MFS.
R7: An MFS may split to become two separate MFSs, in this case
MANEMO will continue 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 the trade-off
between ensuring some reciprocity between MFS peers and
maintaining a safe degree of CIA (see Paragraph 3 in the
terminology section (Section 2)) properties between the peer
Mobile Routers.
R9: The MANEMO protocol should enable that Mobile Routers be
deployed to restore connectivity in parts of an MFS went isolated,
or extend the connectivity in the areas that are not covered.
R10: The solution MUST not require modifications to any node other
than nodes that participates 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 by the IETF.
Wakikawa, et al. Expires August 9, 2007 [Page 13]
Internet-Draft MANEMO Problem Statement February 2007
R11: 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 the Exit Router.
R12: The MANEMO protocol shall optimize the path to the Internet
using cross-layer metrics.
Wakikawa, et al. Expires August 9, 2007 [Page 14]
Internet-Draft MANEMO Problem Statement February 2007
5. Problem Statement
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 already observed in several Working Groups and
some are specified in [15][14].
The MANEMO is possibly related to 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 Multiple Interfaces in IPv6 (Monami6)
The main problems are "Network Loop", "Un-optimized Route", and
"Multiple Exit Routers" .
5.1. Network 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 lower MR (i.e.
MR2 in the figure)
In this case, the loop is observed between MRs. Each mobile network
is designed to have movement transparency by 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.
Wakikawa, et al. Expires August 9, 2007 [Page 15]
Internet-Draft MANEMO Problem Statement February 2007
+---+ +---+
|AR | |AR |
+-+-+ +---+
|
|
+-+-+ +---+
|MR1| --> |MR1+--+
+-+-+ +-+-+ |
| | |
| | |
+-+-+ +-+-+ |
|MR2| |MR2|--+
+---+ +---+
Figure 1: 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.
Wakikawa, et al. Expires August 9, 2007 [Page 16]
Internet-Draft MANEMO Problem Statement February 2007
+---+ +---+ +---+ +---+
|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 of the
nested solution proposed in NEMO working group cannot solve this
case. MANEMO solution should be able to solve this case, too.
Wakikawa, et al. Expires August 9, 2007 [Page 17]
Internet-Draft MANEMO Problem Statement February 2007
+---+ +---+ +---+ +---+
|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 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 Router and present it to the connected mobile node.
Wakikawa, et al. Expires August 9, 2007 [Page 18]
Internet-Draft MANEMO Problem Statement February 2007
. . . . . . . . . . . ..
. .
. The Internet .
. .
.. . . . . . . . . . . .
| |
| |
+-+-+ +-+-+
|AR1| |AR2+--+
+-+-+ +-+-+ |
| +---+ | |
+-----|MR1|----+ |
+-+-+ |
| +-+-+
+--------+MR2|
+---+
Figure 4: Multiple Exit Routers
Wakikawa, et al. Expires August 9, 2007 [Page 19]
Internet-Draft MANEMO Problem Statement February 2007
6. Approach Rationale
MANEMO aims at extending IPv6 Neighbor Discovery [7] to form and
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 to establish a tree towards the nearest Exit
Router. This falls short when the nodes are mobile routers for a
number of reasons:
In a L2 based solution, the MRs would end up bridging for the
nested routers while 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 such as like 802.11s
or 802.21.
There can be value in integration between the NEMO and the MANET
aspects of the mobility problem. For instance, if the Reverse
Routing Header technique [16] is used to solve the pinball routing
problem, then the RRH can be compressed dynamically if routes down
the tree (or the DAG) are installed by 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 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 the information of routers
in a train to the information service (IS). The mobile node can
retrieve information about the neighboring access networks from IS in
Wakikawa, et al. Expires August 9, 2007 [Page 20]
Internet-Draft MANEMO Problem Statement February 2007
some scenarios. Unless the IS supports dynamic updates of access
routers and provides certain topology of mobile access routers, it is
difficult to solve all the problems of MANEMO. For instance, 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 to the
outside infrastructure when it is reachable. In that sense, MANEMO
specializes on a specific area of MANET by adding a set of
constraints that narrow the problem down.
Arguably, an existing MANET protocol could be used to enable routing
between the Mobile Router within a nested NEMO. But existing MANET
are not optimized for the following requirements:
Default Route: Because it is used by Mobile Routers to find a way
out and bind to their Home Agent, the MANEMO 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 in any case it is just another route, not the focus
of the protocol.
Prefix Routing: Subnet (prefix) routing is a secondary concern for
the MANEMO protocol. Such routes are considered when conditions
permit, but might be maintained in a Least Overhead Routing
Approach (LORA) as opposed to an Optimized Routing Approach (ORA)
which is used for the Default Route. Host Routes are not of
concern since 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 a selection of information that is not present in traditional
MANET approaches. Notions such as group, depth, free bandwidth
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 the following cases:
Wakikawa, et al. Expires August 9, 2007 [Page 21]
Internet-Draft MANEMO Problem Statement February 2007
On-demand Routing: When a node needs to discover Exit Routers, on-
demand fashion may reduce the overhead 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 the local network may improve by Mobile Routers running a
MANEMO routing protocol and discovering more optimal routes to the
MNPs reachable within the local network. Mechanisms specific to
MANEMO should also be developed to ensure this optimisation is
safe.
Global Reachability for a MANET In the MANET working group, an
Internet Gateway is introduced to provide Internet connectivity to
MANET. In this case, the gateway of a MANET network is also a
NEMO Mobile Router. Using NEMO, The gateway registers the MANET
prefix(es) to a Home Agent, enabling the MANET network to move as
a whole. The Mobile Router can also act as a Mobile Home 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 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 MANEMO
requirements.
6.4. Neighbor Discovery based approach
Neighbor Discovery (ND) [7] provides the means to discover neighbors
and the prefix on a link, which are pervasive across IPv6 nodes and
link types. Mobile IPv6 [8] 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]. ND is consistently being improved for
mobility, in particular with Mobile IPv6 [8] and DNA, and for
security with Secure ND [10]. 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
Wakikawa, et al. Expires August 9, 2007 [Page 22]
Internet-Draft MANEMO Problem Statement February 2007
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 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], either with native MLD [11][12] / 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 the Exit Router is to be worked
out.
The MANEMO work will thus focus on an ND based solution that is
required to provide multihop 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 for optimize local
connectivity or used for other reasons.
MANEMO ND may provide IP link and address topology vectors to the
nodes next hop neighbors. Then that topology information at each
next hop neighbor would be propagated to an OLSRv2 [21] / NHDP [22]
symmetric 2-hop neighborhood and Multipoint Relay, or OSPF-MANET [23]
/ [24] MANET Designated Router (most likely Parent 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 the
NEMO Clusterhead using the proposed tree discovery protocol [18].
The diameter of the topology would span a single ad hoc link. This
would provide an IP layer 3 solution and the topology information
could be placed in new ND options.
6.4.2. MANEMO ND and AUTOCONF
The use of ND for IP link and address topology could also foster a
discussion with IETF AUTOCONF Working Group to analyze if ND could be
used as defined above to support ND stateless autoconfiguration. The
design center for such a solution would be to place this ND link and
IP topology enhancement below current MANET routing protocols and
could reduce latency for ad hoc links whether within a MESH or Radio
Network link. ND extensions could assist greatly below MANET routing
Wakikawa, et al. Expires August 9, 2007 [Page 23]
Internet-Draft MANEMO Problem Statement February 2007
protocols to discover neighbors, verify two way communications,
exchange link state information, and provide update information
between neighbors and ingress/egress point to MANET Mobile Routers.
These extensions could also be applied as enhancements to the tree
discovery protocol that would support MANEMO, thus adding these
extensions to tree discovery protocol is a suggestion or it could be
its own specification.
Wakikawa, et al. Expires August 9, 2007 [Page 24]
Internet-Draft MANEMO Problem Statement February 2007
7. Related Information
Related Documents can be found in the Informative Reference section
Solutions are already proposed at IETF such as [16] and [18]. The
NEMO Working Group has the analysis document [25] for the nested NEMO
issue.
Wakikawa, et al. Expires August 9, 2007 [Page 25]
Internet-Draft MANEMO Problem Statement February 2007
8. IANA considerations
This document does not require any IANA action.
Wakikawa, et al. Expires August 9, 2007 [Page 26]
Internet-Draft MANEMO Problem Statement February 2007
9. 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.
Wakikawa, et al. Expires August 9, 2007 [Page 27]
Internet-Draft MANEMO Problem Statement February 2007
10. 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. References
11.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] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[9] Draves, R. and D. Thaler, "Default Router Preferences and More-
Specific Routes", RFC 4191, November 2005.
[10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
Wakikawa, et al. Expires August 9, 2007 [Page 28]
Internet-Draft MANEMO Problem Statement February 2007
[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
11.2. Informative Reference
[13] Ng, C., "Network Mobility Route Optimization Problem
Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
progress), September 2006.
[14] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route
Optimisation Problem Statement",
draft-clausen-nemo-ro-problem-statement-00 (work in progress),
October 2004.
[15] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-06 (work in progress),
June 2006.
[16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
its application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-06 (work in
progress), September 2006.
[17] 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, C., "IPv6 Multicast for Mobile Networks with MLD-
Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in
progress), April 2004.
[20] Macker, J., "Simplified Multicast Forwarding for MANET",
draft-ietf-manet-smf-03 (work in progress), October 2006.
[21] Clausen, T., "The Optimized Link-State Routing Protocol version
2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006.
[22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
draft-ietf-manet-nhdp-00 (work in progress), June 2006.
[23] Spagnolo, P. and R. Ogier, "MANET Extension of OSPF using CDS
Flooding", draft-ogier-manet-ospf-extension-08 (work in
progress), October 2006.
[24] Roy, A. and M. Chandra, "Extensions to OSPF to Support Mobile
Wakikawa, et al. Expires August 9, 2007 [Page 29]
Internet-Draft MANEMO Problem Statement February 2007
Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in
progress), January 2007.
[25] Ng, C., "Network Mobility Route Optimization Solution Space
Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in
progress), September 2006.
Wakikawa, et al. Expires August 9, 2007 [Page 30]
Internet-Draft MANEMO Problem Statement February 2007
Appendix A. Change Log From Previous Version
o Initial Documentation
Authors' Addresses
Ryuji Wakikawa
Keio University and WIDE
5322 Endo Fujisawa Kanagawa
252-8520
JAPAN
Email: ryuji@sfc.wide.ad.jp
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
Wakikawa, et al. Expires August 9, 2007 [Page 31]
Internet-Draft MANEMO Problem Statement February 2007
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/
Wakikawa, et al. Expires August 9, 2007 [Page 32]
Internet-Draft MANEMO Problem Statement February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Wakikawa, et al. Expires August 9, 2007 [Page 33]