< draft-wakikawa-manemo-problem-statement-00.txt		draft-wakikawa-manemo-problem-statement-01.txt >
	No Working Group R. Wakikawa		No Working Group R. Wakikawa
	Internet-Draft Keio University		Internet-Draft Keio University
	Expires: August 9, 2007 P. Thubert		Expires: January 10, 2008 P. Thubert
	Cisco		Cisco
	T. Boot		T. Boot
	Infinity Networks		Infinity Networks
	J. Bound		J. Bound
	HP		HP
	B. McCarthy		B. McCarthy
	Lancaster University		Lancaster University
	February 5, 2007		July 9, 2007
	MANEMO Problem Statement		Problem Statement and Requirements for MANEMO
	draft-wakikawa-manemo-problem-statement-00		draft-wakikawa-manemo-problem-statement-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 9, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document outlines the fundamental problems and approach		The NEMO Basic Support protocol has well-known issues when multiple
	rationale of MANEMO. When mobile nodes converge at the edge of the		mobile routers are connected to each other in a nested fashion.
	Internet using wireless interfaces, they can form a network in an ad-		These issues have been already analyzed in the NEMO Working Group.
	hoc fashion and are able to provide Internet connectivity to one		However, solutions are not yet considered and discussed in the IETF.
	another. This type of network is called a MANEMO Fringe Stub (MFS).		MANEMO (MANET for NEMO) is an approach to resolve these issues.
	Several issues exist in the MFS such as network loop, un-optimized		Although most of issues are relevant to what the MANET working group
	path and multiple exit routers to the Internet. While fixed routers		is chartered to deliver, a different approach may be required. This
	provide connectivity constantly, mobile routers can experience		document identifies the problems which MANEMO will solve and provides
	intermittent connectivity to the Internet due to their movement.		the MANEMO requirements.
	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.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	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		3. MANEMO Characteristic . . . . . . . . . . . . . . . . . . . . 6
	5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 15		4. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Network Loop . . . . . . . . . . . . . . . . . . . . . . . 15
	5.2. Un-optimized Route . . . . . . . . . . . . . . . . . . . . 16
	5.3. Multiple Exit Routers . . . . . . . . . . . . . . . . . . 18
	6. Approach Rationale . . . . . . . . . . . . . . . . . . . . . . 20		5. Existing Solutions and MANEMO approach . . . . . . . . . . . . 12
	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		6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26		7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 27		8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative reference . . . . . . . . . . . . . . . . . . . 28		10.1. Normative reference . . . . . . . . . . . . . . . . . . . 18
	11.2. Informative Reference . . . . . . . . . . . . . . . . . . 29		10.2. Informative Reference . . . . . . . . . . . . . . . . . . 19
	Appendix A. Change Log From Previous Version . . . . . . . . . . 31		Appendix A. Change Log From Previous Version . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 33		Intellectual Property and Copyright Statements . . . . . . . . . . 23
	1. Introduction		1. Introduction
	With routers and access points now being priced as a commodity, a		Mobile Ad-hoc Network mechanisms have been standardized for local
	cloud of nodes connected by wireless technology is being created at		communication when wireless nodes are connected in an ad-hoc fashion.
	the edge of the Internet. This cloud is called a MANEMO Fringe Stub		Several routing protocols were already standardized within the MANET
	(MFS) in this document. The definition of all the terms used in this		working group and almost ready for deployment. The AUTOCONF working
	document can be found in Section 2. Examples of these wireless		group has been recently formed to standardize the IP address
	technologies used within a MFS are wireless metropolitan and local		configuration (both local address and global address). On the other
	area network protocols (WiMAX, WLAN, 802.20, etc), short distance		hand, the NEMO working group has standardized the NEMO Basic Support
	wireless technology (bluetooth, irDA, UWB), and radio mesh networks		Protocol [1] for global mobility of networks to support network
	(ex. 802.11s). As the MFS extends to the consumer market and into		movement transparency. The MANET/AUTOCONF and the NEMO working
	the homes, it's ease of use should become comparable to that of		groups discuss their solutions separately without the consideration
	existing electrical appliances and extension cords, i.e. highly user		of integrating them. In the NEMO Working Group, the well-known
	friendly with little or no user interaction required. As a result,		issues caused by nested NEMO are addressed. Some of them are very
	networking in the MFS will be highly unmanaged and ad-hoc, but at the		similar to what the MANET/AUTOCONF working groups deal with as a
	same time will need to offer excellent service availability.		problem space. However, the NEMO Basic Support protocol requires
			always connected Home Agent reachability and network movement
			transparency in relation to a mobile network. These multiple effort
			creates some contradiction between MANET/AUTOCONF and NEMO. We
			discuss this contradiction briefly in this document and also in [11].
	In particular, NEMO basic support [1] could be used to provide global		In addition to that, the MANET protocols (DYMO [12] and OLSR [13])
	reachability for a mobile access network within the MFS. However,		may solve many of the upcoming problems introduced by new
	when Mobile Nodes attach randomly to one another in this model (to		technologies, but implementing all functionalities of the MANET
	form what is termed a nested NEMO) the overall structure can become		routing protocols may not be always desired for some specific issues.
	highly suboptimal and loops can also possibly occur.		As the 6lowpan Working Group works on how to apply MANET protocols to
			LoWPANs (ex. RSN mailing list: Routing Sensor Network), it may be
			required to determine the possibility of either extending or
			downsizing the existing MANET/ AUTOCONF solutions for the nested NEMO
			problems for a sensor network. Since the nested NEMO problems are
			minor issues caused only within the NEMO Basic Support model, it may
			be time to look at a light-weight approach for the issues within the
			IETF.
	Therefore, there is a need for additional information to be made		Solutions for MANEMO have already been proposed within the IETF such
	available to Mobile Nodes to help them select an interface and an		as [14] and [15]. The NEMO Working Group has the analysis document
	attachment router over that interface in order to reach the Internet		[16] for the nested NEMO issue. MANEMO is possibly related to the
	(possibly indirectly) in a fashion avoiding network loops. The aim		following on- going work in IETF.
	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		o Existing Routing Protocols (MANET, OSPF)
	route(s) towards the Internet and be globally reachable using NEMO.
	MANEMO may also be required to install backward routes towards		o Network Mobility Support (NEMO)
	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,		o Mobile Ad-hoc Network and Auto Configuration (AUTOCONF)
	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		o Mobile Ad-hoc Sensor Network (6LOWPAN)
	improvement for multicast, as MANEMO multicast traffic could be		o Mobile Nodes and Multiple Interfaces in IPv6 (Monami6)
	distributed in the MFS without the overhead of nested tunnels and
	pseudo-broadcasting.
	2. Terminology		2. Terminology
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [2]		document are to be interpreted as described in RFC 2119 [2]
	Readers are expected to be familiar with all the terms defined in the		Readers are expected to be familiar with all the terms defined in the
	RFC3753 [3] and the NEMO Terminology draft [4]		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.
	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		MANEMO Fringe Stub (MFS) The MANEMO Fringe Stub is a cloud of Mobile
	Routers connected by wireless or wired links. Any type of link		Routers connected by wireless or wired links. Any type of link
	supporting IPv6 connectivity can be used, including partly meshed		supporting IPv6 connectivity can be used, including partly meshed
	wireless topologies. An MFS is a stub at the edge of the		wireless topologies. An MFS is a stub at the edge of the
	Internet, interconnecting various types of devices which discover		Internet, interconnecting various types of devices which discover
	each other and form a network in an ad-hoc fashion to provide		each other and form a network in an ad-hoc fashion to provide
	Internet connectivity to one another. Many disjunctive MFS can be		global connectivity to one another. Many disjunctive MFS can be
	connected to the Internet. An MFS can also be floating, which		connected to the Internet. An MFS can also be floating, which
	means the cloud is not connected to the Internet.		means the cloud is not connected to the Internet.
	MANEMO Link A MANEMO Link is a MANEMO enabled Mobile Router		Exit Router The Exit Router is a router which provides connectivity
	interface and the data link layer transmission medium connected to		to the Internet and acts as a layer-3 sink for the MFS. The Exit
	it. Via the link, other nodes can be reached, called the 1st hop		Router can be a fixed Access Router supporting MANEMO or a mobile
	neighbors.		router (root-MR) connected directly to the Internet. Multiple
			Exit Routers may be available in an MFS.
	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		MANEMO MANET for NEMO. MANEMO provides the necessary additions to
	access the Internet. Example Wireless Nodes are a Mobile Node		existing protocols (IPv6, ND, NEMO), for nested Mobile Routers to
	(Mobile Host or Mobile Router) and a normal IPv6 node [5] with a		find the most suited exit towards the Internet. MANEMO enables
	wireless link.		some internal connectivity within the nested NEMO whether the
			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.
	Nested NEMO The Nested NEMO is a network configuration where one or		Nested NEMO The Nested NEMO is a network configuration where one or
	more mobile routers are connected in nested formation. The		more mobile routers are connected in a nested formation. The
	detailed issues can be found in [13] and [14].		detailed issues can be found in [17] and [18].
	Self Optimizing A Self-Optimizing network is a self-forming, self-
	healing network that adapts its topology dynamically in order to
	optimize some metrics.
	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
	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.
	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.
	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		3. MANEMO Characteristic
	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,		Before discussing the detail of MANEMO problems, we highlight the
	etc., it is expected that we will begin to see access networks that		characteristics of MANEMO Fringe Stub (MFS) by comparing it with a
	are on the move. Within the current 802.21 standards, this moving		traditional ad-hoc network (MANET) in this section.
	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		Mobile routers of RFC3963 are the core nodes of an MFS. A mobile
	and location knowledge. For instance, a passenger in a vehicle (i.e.		network served by a mobile router is seen as a normal IPv6 network.
	bus/train) should stick to the access provided by that vehicle while		It is possible for a mobile router to connect to another mobile
	a stationary passenger located in the station should get access from		router's mobile network. As a result, mobile routers are connected
	a fixed resource. Some of the required information to make the		and form a nested topology which is known as nested NEMO. In MFS,
	proper decision is available from layer 3 and above, as well as from		not only mobile routers, but also mobile hosts, fixed nodes (host and
	the user himself.		router) are considered. Fixed hosts and routers can be connected to
			one of the mobile networks and can also be located in the Internet.
			Access routers to provide wireless connectivity are also considered
			as a node within an MFS. All these nodes may be involved within the
			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 highlight the MANEMO
			characteristic, we only show the mobile routers in the topology. We
			discuss all the possible topologies of mobile routers in MFS in the
			MANEMO architecture [11]. Each mobile router owns an assigned prefix
			from its home agent. The prefix is configured for a mobile network.
			A mobile router acquires a topologically correct address (care-of
			address) at the egress interface and tunnels all the data to its home
			agent by using the care-of address.
	MANEMO should define and utilize means for discovering and selecting		Although MANET supports Internet connectivity, because of NEMO Basic
	the best access network for users.		Support, the reachability to its home agent for home registration is
			a fundamental aspect of MANEMO. Without home registration, it cannot
			communicate to other nodes with its mobile network prefix according
			to RFC3963. If the binding registration is completed, all the
			traffic from the mobile network is tunneled to the home agent. In
			NEMO context, at least one 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 network. The disconnected MFS can also
			occur. Moreover, on the MANEMO mailing list, we currently discuss
			the case when each mobile router is connected by the egress interface
			and forms a MANET-like network. This case can be seen as "mobile
			routers forming a mobile ad-hoc network". Except for the assigned
			prefix to each mobile router, the characteristic of this scenario may
			be same as mobile ad-hoc network.
	4. Requirements		+-------------------+ Internet (Wired/Wireless)
			| | |
			| | \|/
			ER1 ER2 /|\
			| / |
			1---2 3 |
			|\ / | Wireless Links
			4 5---6---7----8--9 |
			| \ \ |
			10---11 12 13---14 \|/
	MANEMO has the following requirements:		Figure 1: Example Topology
	R1: The MANEMO protocol must enable the discovery of multihop		Figure 2 shows the difference of communication model between MANET
	topologies at layer 3 from mere reachability and elaborate links		and MANEMO. A mobile router (MR6) communicates with another mobile
	for IPv6 usage, regardless of the wired or wireless media.		router (MR14) . The 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 MANET routing
			protocols select the shortest path in default. If many sessions are
			in process within the network, the congestion at some links can be
			obviously observed. The links between MR6 to MR8 in Figure 2 may
			become possible bottlenecks if many nodes are communicating at the
			same time. Figure 2-b, on the other hand, shows the MANEMO
			communication model. The default communication path between MR6 and
			MR14 is through the Internet. Each mobile router transmits packets
			to the exit router even if the destination node is located nearby.
			Thus, packets are traveled over the Internet (through several home
			agents if it is required) and routed to the exit router to which the
			destination mobile router belongs. Even if the path length may
			increase, the path over the Internet is often more reliable than the
			shortest link. Note that it is true that the link between ER1-MR1
			and ER2-MR3 become the bottleneck for all the traffic coming in and
			out of the MFS. Additional latency may also be observed, but it is a
			trade-off of several aspects such as latency, congestion, reliability
			and costs of local routing management (MANET routing protocol). In
			MANEMO, it is still possible to maintain the neighboring mobile
			routers. End nodes can communicate to the destination directly along
			the shortest path (not through the exit routers). Each mobile router
			should be able to decide whether the packets are routed to the exit
			router or to the destination directly. MANEMO does not identify how
			to manage local routing, but the primarily goal is to manage the path
			to the exit router as a default.
	R2: The MANEMO protocol must enable packets transmitted from Mobile		(Internet)
	Routers visiting the MFS to reach the Internet via an optimized		+===== HAn =======+
	path towards the nearest Exit Router, and back.		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
	R3: MANEMO must enable IP connectivity within the nested NEMO		a) MANET b) MANEMO
	whether the infrastructure is reachable or not.
	R4: The MANEMO protocol must enable packets transmitted from Mobile		Figure 2: Communication Model
	Routers visiting the MFS to reach the Internet with a
	topologically correct address.
	R5: The MANEMO protocol should aim at minimizing radio interference		When a mobile router changes its point of attachment, it must hide
	with itself as the control messages get propagated in the MFS.		the changes from any nodes located in its mobile network [1]. Since
			nodes in the mobile network are moved all together, sets of mobile
			routers can move at once in MFS. Nodes can be an IPv6 node, a mobile
			host of RFC3775, and a mobile router of RFC3963. For instance, in
			Figure 3, a mobile router (MR4) moves its point of attachment. Even
			if MR4 moves, the movement has minimum impact to any nodes including
			mobile routers (MR10 and MR11) located in the MR4's mobile network.
			The mobile network nodes must be completely unaware of the movement.
			On the other hand, within most of the MANET and AUTOCONF schemes, the
			change of MR4's attachment effects the neighboring nodes (possibly
			the entire network). Most of the routing protocols require the route
			re-calculation or route re-discovery (route maintenance) when
			topology changes are occurred. This should be avoided because it
			breaks the nature of the NEMO basic support protocol. A detailed
			explanation can be found in [11].
	R6: MANEMO protocol must enable inner movements within MFS to occur,		+------------------+ +------------------+
	and ensure details of this movement are not propagated beyond the		ER1 ER2 ER1 ER2
	MFS.		| / | /
			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
			^^^^^^^
	R7: An MFS may split to become two separate MFSs, in this case		movement transparency
	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		Figure 3: Movement Model
	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		Another aspect of MANEMO characteristic is that each mobile router
	deployed to restore connectivity in parts of an MFS went isolated,		can be connected by different wireless technology, while a default
	or extend the connectivity in the areas that are not covered.		MANET assumption is to use a single wireless interface in 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 ER2 by 3G (HSDPA), MR3 and MR8 are connected by 802.11b,
			MR8 and MR13 are by 802.11g, and so on. as described in Figure 4.
	R10: The solution MUST not require modifications to any node other		+------------------+
	than nodes that participates to the MFS. It must support fixed		ER1 ER2
	nodes, mobile hosts and mobile routers in the NEMOs that form the		| WiMAX / <-3G(HSDPA)
	MFS, and ensure backward compatibility with other standards		1---2 3
	defined by the IETF.		|\ / <-wifi(802.11b)
			4 5---6---7----8--9
			| \ \ <-wifi(802.11g)
			10---11 12 13---14
			wifi(802.11a)
	R11: The MANEMO protocol shall enable multicast communication, for		Figure 4: Movement Model
	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		The final difference is the routing capability. In MANET, each
	using cross-layer metrics.		router can route the packet received at the manet interface [19]. A
			route can receive a packet from a manet interface and can send the
			packet from the same manet interface according to its routing table.
			However, in the NEMO Basic Support model, a mobile router can route
			only the tunneled packet to and from its mobile network. Without the
			bi- directional tunnel, the mobile router never routes the non-
			tunneled packet according to [1]. The packet sent from the ingress
			interface is always routed to the mobile router's home agent by using
			IP encapsulation. The incoming packets must always be tunneled from
			the mobile router's home agent except for the packets sent to the
			mobile node itself.
	5. Problem Statement		4. Problem Statements
	Radio connectivity and movement have disrupted the concept of a link		Radio connectivity and movement have disrupted the concept of a link
	as we know it in the wired environment. Specific modes for specific		as we know it in the wired environment. Specific modes for specific
	radios are proposed to restore that concept, which is essential for		radios are proposed to restore that concept, which is essential for
	IP operations, as single hop (802.11 infrastructure mode) or multihop		IP operations, as single hop (802.11 infrastructure mode) or multihop
	(802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified		(802.11S, 802.15.5, 802.16J). MANEMO aims a proposing a unified
	solution to reconstruct a minimum topological abstraction at layer 3		solution to reconstruct a minimum topological abstraction at layer 3
	for the use of NEMO.		for the use of NEMO.
	The MANEMO problem is already observed in several Working Groups and		The MANEMO problems are already observed in several Working Groups
	some are specified in [15][14].		and some are specified in [17], [20]
	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.
	+---+ +---+
	|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.
	+---+ +---+ +---+ +---+
	|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.
	+---+ +---+ +---+ +---+
	|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		1. Sub-optimal route and Redundant tunnel: This issue is described
			in Section 2.1, 2.3 and 2.6 of [17] and in Appendix B.1, B.2,
			B.3, B.4 of [17].
	5.3. Multiple Exit Routers		2. No Communication capability without Home Agent Reachability: This
			issue is described in Section 2.6 of [17]
	This problem occurs when a mobile node obtains multiple Exit Routers		3. Exit Router Selection: This problem occurs when a mobile node
	toward the Internet. In the illustrated case, the mobile node should		obtains multiple Exit Routers toward the Internet. In the
	attempt to obtain some information about each Exit Router in order to		illustrated case, the mobile node should attempt to obtain some
	more efficiently utilize them. MANEMO may carry this information		information about each Exit Router in order to more efficiently
	about each Exit Router and present it to the connected mobile node.		utilize them. MANEMO may carry this information about each Exit
			Router and present it to the connected mobile node.
	. . . . . . . . . . . ..		. . . . . . . . . . . ..
	. .		. .
	. The Internet .		. The Internet .
	. .		. .
	.. . . . . . . . . . . .		.. . . . . . . . . . . .
	| |		| |
	| |
	+-+-+ +-+-+		+-+-+ +-+-+
	|AR1| |AR2+--+		|AR1| |AR2+--+
	+-+-+ +-+-+ |		+-+-+ +-+-+ |
	| +---+ | |		| +---+ | |
	+-----|MR1|----+ |		+-----|MR1|----+ |
	+-+-+ |		+-+-+ |
	| +-+-+		| +-+-+
	+--------+MR2|		+--------+MR2|
	+---+		+---+
	Figure 4: Multiple Exit Routers		Figure 5: Multiple Exit Routers
	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		4. Network Loop: A network loop can occur when multiple mobile
	L3, because NEMO already interfaces with ND. A L2 solution would		routers are nested and suddenly the Exit Router (root-MR, i.e.
	require NEMO to understand L2/2.5 protocols such as like 802.11s		MR1) looses connectivity to the Internet and connects to the
	or 802.21.		mobile network of a lower hierarchical MR (i.e. MR2 in the
			figure). In this case, the loop is observed between mobile
			routers. Each mobile network is designed to have movement
			transparency 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.
	There can be value in integration between the NEMO and the MANET		Internet Internet
	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		|AR | |AR |
	the tree (or the DAG) are installed by the MANEMO protocol in the		+-+-+ +---+
	intermediate routers.		|
			+-+-+ +---+
			|MR1| --> |MR1+->+
			+-+-+ +-+-+ |
			| /|\ |
			| | |
			+-+-+ +-+-+ \|/
			|MR2| |MR2|<-+
			+---+ +---+
	And then you get all the IP value that is not necessarily there or		Figure 6: Network Loop
	homogeneous at L2, like QoS, SNMP, RSVP, aggregation, etc...
	6.2. 802.21 based approach		Section 4.8 of [20] discussed the loop problem when a mobile
			router is multihomed.
	In some scenarios, the information service approach may be taken.		5. Existing Solutions and MANEMO approach
	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
	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		Several approaches can be taken for the problems listed in Section 4.
			Some analysis can be found in [21].
	The Mobile Ad-hoc Network Architecture [17] provides an overview of		[MANET Routing Protocol and AUTOCONF] While manet routing protocols
	the MANET problem and scope.		maintain the local connectivity, the primary goal of MANEMO is to
			discover an exit router and to maintain the path to the Internet
			through the exit router for binding registration and traffic over
			the bidirectional tunnel. Only for this purpose, MANET routing
			protocols have excess functionalities such as flooding messages
			for route discovery or route updates, etc. The primary goal of
			the MANET routing protocols is to maintain local connectivity.
			However, the local connectivity management should not be mandated
			to the MANEMO solution, although MANEMO may be interested in the
			local routing in the future. The NEMO Basic Support protocol
			basically requires tunneling the packets to the Internet. NHDP
			[22] is alternate solution to discover neighboring nodes, but it
			is limited to only two hop neighbors' information. There is a
			case that an exit router is more than 2 hops away. The AUTOCONF
			working group discusses the address assignment scheme for ad-hoc
			networks. However, the addressing architecture is slightly
			different from what the NEMO basic support protocol is expecting.
			More details can be found in [11].
	MANEMO is about designing a specific MANET that is tailored for the		[NEMO Route Optimization Scheme] There is no route optimization
	needs of nested NEMO, with a strong focus on finding the way to the		scheme in IETF. Only the analysis document is available in [16].
	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		Contrary to the existing solutions, MANEMO arranges a tree structure
	between the Mobile Router within a nested NEMO. But existing MANET		towards the Internet. This tree is the simplest network topology
	are not optimized for the following requirements:		connecting Mobile Routers within an MFS to a single Exit Router. The
			Exit Router is the root of the MANEMO Tree. The packets from MFS are
			routed along the tree and are routed to the destination. Routing to
			multiple home agents should be avoided as much as possible. Basic
			required functionalities for MANEMO are:
	Default Route: Because it is used by Mobile Routers to find a way		1. Discovering and Selecting exit routers
	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		2. Forming loop-free Tree by making an exit router as a root
	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		3. Maintaining the path to the exit router
	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		4. Bypassing Home Agents for the traffic from MFS
	adapted for the following cases:
	On-demand Routing: When a node needs to discover Exit Routers, on-		The MANEMO work focus is on a Neighbor Discovery (ND) [5] based
	demand fashion may reduce the overhead of discovery procedure.		solution that is required to provide multihop reachability while
	Some MANET routing protocols such as AODV and DYMO has the on-		supporting the inner movements within the nested NEMO. ND provides
	demand mechanism to discover a route towards the destination.		the means to discover neighbors and the prefix on a link, which are
			pervasive across IPv6 nodes and link types. Mobile IPv6 [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.
	Neighborhood Routing: Because the MANEMO protocol provides only a		ND has already been extended to expose some layer 3 information, such
	minimized view of the local network, it might be missing a short		as router selection hints [7]. ND is consistently being improved for
	path to a neighborhood destination over an alternate radio link.		mobility, in particular with Mobile IPv6 [6] and DNA [23], and for
	A collaboration with a MANET protocol would improve short-distance		security with Secure ND [8]. ND operates on bidirectional links,
	routing. As an example, internal connectivity between NEMOs		whereas this is a restriction from the MANET standpoint, this
	within the local network may improve by Mobile Routers running a		condition enables simpler solutions for MANEMO. Neighbor Discovery
	MANEMO routing protocol and discovering more optimal routes to the		is well suited for providing hints for composing a path to the
	MNPs reachable within the local network. Mechanisms specific to		Internet access router. The Exit Routes connect MFS to the Internet.
	MANEMO should also be developed to ensure this optimisation is
	safe.
	Global Reachability for a MANET In the MANET working group, an		Multicast support could be provided by using the loop-free MANEMO
	Internet Gateway is introduced to provide Internet connectivity to		Tree to forward packets to the Internet. Down-tree forwarding would
	MANET. In this case, the gateway of a MANET network is also a		use MLD-proxy [24], either with native MLD [9][10] / ICMP packets or
	NEMO Mobile Router. Using NEMO, The gateway registers the MANET		send with the ND extensions to increase efficiency.
	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,		6. Requirements
	but a specific protocol has to be engineered to match the MANEMO
	requirements.
	6.4. Neighbor Discovery based approach		MANEMO has the following requirements:
	Neighbor Discovery (ND) [7] provides the means to discover neighbors		R1: MANEMO must enable the discovery of multihop topologies at layer
	and the prefix on a link, which are pervasive across IPv6 nodes and		3 from mere reachability and elaborate links for IPv6 usage,
	link types. Mobile IPv6 [8] and NEMO [1] rely heavily on ND for		regardless of the wired or wireless media.
	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		R2: MANEMO must enable packets transmitted from nodes visiting the
	as router selection hints [9]. ND is consistently being improved for		MFS to reach the Internet via an optimized path towards the
	mobility, in particular with Mobile IPv6 [8] and DNA, and for		nearest Exit Router, and back.
	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		R3: MANEMO must enable IP connectivity within the MFS whether
	path to the Internet access router. The hits could include Layer 2		Internet is reachable or not.
	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		R4: MANEMO must enable packets transmitted from nodes visiting the
	Tree to forward packets to the Internet. Down-tree forwarding would		MFS to reach the Internet with a topologically correct address.
	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		R5: MANEMO should aim at minimizing radio interference with itself
	required to provide multihop reachability while supporting inner		as the control messages get propagated in the MFS.
	movements in the nested NEMO.
	6.4.1. MANEMO ND and other MANET protocols		R6: MANEMO must enable inner movements within MFS to occur, and
			ensure propagating details of this movement is kept at a minimum.
	The MANEMO ND provided information can be used by other MANET		R7: An MFS may split to become two separate MFSs, in this case
	protocols. Other MANET protocols could be used for optimize local		MANEMO must continue to maintain local connectivity within the
	connectivity or used for other reasons.		separate MFSs and connectivity between the split MFSs. MFSs may
			merge, in this case inner MFS connectivity optimization must be
			restored.
	MANEMO ND may provide IP link and address topology vectors to the		R8: MANEMO should enable and optimize the trade-off between ensuring
	nodes next hop neighbors. Then that topology information at each		some reciprocity between MFS peers and maintaining a safe degree
	next hop neighbor would be propagated to an OLSRv2 [21] / NHDP [22]		of CIA properties between the peer Mobile Routers.
	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		R9: MANEMO must support ad-hoc operation, for isolated MFSs (R3) and
			multi-hop access to the Internet (R2).
	The use of ND for IP link and address topology could also foster a		R10: MANEMO must not require modifications to any node other than
	discussion with IETF AUTOCONF Working Group to analyze if ND could be		nodes that participates to the MFS, including HA. It must support
	used as defined above to support ND stateless autoconfiguration. The		fixed nodes, mobile hosts and mobile routers in the MFS, and
	design center for such a solution would be to place this ND link and		ensure backward compatibility with other standards defined by the
	IP topology enhancement below current MANET routing protocols and		IETF.
	could reduce latency for ad hoc links whether within 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
	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.
	7. Related Information		R11: MANEMO should enable multicast communication, for nodes within
			the MFS and on the Internet.
	Related Documents can be found in the Informative Reference section		R12: MANEMO must optimize the path to the Internet using cross-layer
			metrics.
	Solutions are already proposed at IETF such as [16] and [18]. The		R13: MANEMO may provide direct peer to peer reachability for nearby
	NEMO Working Group has the analysis document [25] for the nested NEMO		nodes.
	issue.
	8. IANA considerations		7. IANA considerations
	This document does not require any IANA action.		This document does not require any IANA action.
	9. Security Considerations		8. Security Considerations
	This document is a problem statement and does not create any security		This document is a problem statement and does not create any security
	threat. It discusses the concepts of Capability, Innocuousness and		threat. It discusses the concepts of Capability, Innocuousness and
	Anonymity in a nested NEMO.		Anonymity in a nested NEMO.
	10. Acknowledgments		9. Acknowledgments
	We would like to thank all the people who have provided comments on		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		this draft, and also co-authors of earlier documents in which authors
	of this present document have been engaged. As such, we would like		of this present document have been engaged. As such, we would like
	to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham		to thank Niko A. Fikouras, Yoshihiro Ohba, Emmanuel Baccelli, Hesham
	Soliman, Carlos Jesus Bernardos Cano and many others.		Soliman, Carlos Jesus Bernardos Cano and many others.
	11. References		10. References
	11.1. Normative reference		10.1. Normative reference
	[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,		[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	January 2005.		January 2005.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[3] Manner, J. and M. Kojo, "Mobility Related Terminology",		[3] Manner, J. and M. Kojo, "Mobility Related Terminology",
	RFC 3753, June 2004.		RFC 3753, June 2004.
	[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-06 (work in progress),		draft-ietf-nemo-terminology-06 (work in progress),
	November 2006.		November 2006.
	[5] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[5] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
	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.		for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[8] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in		[6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[9] Draves, R. and D. Thaler, "Default Router Preferences and More-		[7] Draves, R. and D. Thaler, "Default Router Preferences and More-
	Specific Routes", RFC 4191, November 2005.		Specific Routes", RFC 4191, November 2005.
	[10] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[8] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener		[9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
	Discovery (MLD) for IPv6", RFC 2710, October 1999.		Discovery (MLD) for IPv6", RFC 2710, October 1999.
	[12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2		[10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2
	(MLDv2) for IPv6", RFC 3810, June 2004.		(MLDv2) for IPv6", RFC 3810, June 2004.
	11.2. Informative Reference		10.2. Informative Reference
	[13] Ng, C., "Network Mobility Route Optimization Problem		[11] Wakikawa, R., "MANEMO Topology and Addressing Architecture",
	Statement", draft-ietf-nemo-ro-problem-statement-03 (work in		draft-wakikawa-manemoarch-00 (work in progress), July 2007.
	progress), September 2006.
	[14] Clausen, T., Baccelli, E., and R. Wakikawa, "NEMO Route		[12] Perkins, C. and I. Chakeres, "Dynamic MANET On-demand (DYMO)
	Optimisation Problem Statement",		Routing", draft-ietf-manet-dymo-10 (work in progress),
	draft-clausen-nemo-ro-problem-statement-00 (work in progress),		July 2007.
	October 2004.
	[15] Ng, C., "Analysis of Multihoming in Network Mobility Support",		[13] Clausen, T., "The Optimized Link State Routing Protocol version
	draft-ietf-nemo-multihoming-issues-06 (work in progress),		2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007.
	June 2006.
	[16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and		[14] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
	its application to Mobile Networks",		its application to Mobile Networks",
	draft-thubert-nemo-reverse-routing-header-06 (work in		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.		progress), September 2006.
	[17] Chakeres, I., "Mobile Ad hoc Network Architecture",		[17] Ng, C., "Network Mobility Route Optimization Problem
	draft-chakeres-manet-arch-01 (work in progress), October 2006.		Statement", draft-ietf-nemo-ro-problem-statement-03 (work in
			progress), September 2006.
	[18] Thubert, P., "Nested Nemo Tree Discovery",		[18] Clausen, T., "NEMO Route Optimisation Problem Statement",
	draft-thubert-tree-discovery-04 (work in progress),		draft-clausen-nemo-ro-problem-statement-01 (work in progress),
	November 2006.		March 2007.
	[19] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD-		[19] Chakeres, I., "Mobile Ad hoc Network Architecture",
	Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in		draft-chakeres-manet-arch-01 (work in progress), October 2006.
	progress), April 2004.
	[20] Macker, J., "Simplified Multicast Forwarding for MANET",		[20] Ng, C., "Analysis of Multihoming in Network Mobility Support",
	draft-ietf-manet-smf-03 (work in progress), October 2006.		draft-ietf-nemo-multihoming-issues-07 (work in progress),
			February 2007.
	[21] Clausen, T., "The Optimized Link-State Routing Protocol version		[21] Boot, T., "Analysis of MANET and NEMO",
	2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006.		draft-boot-manet-nemo-analysis-01 (work in progress),
			June 2007.
	[22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",		[22] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)",
	draft-ietf-manet-nhdp-00 (work in progress), June 2006.		draft-ietf-manet-nhdp-04 (work in progress), July 2007.
	[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		[23] Kempf, J., "Detecting Network Attachment in IPv6 Networks
	Ad Hoc Networking", draft-chandra-ospf-manet-ext-04 (work in		(DNAv6)", draft-ietf-dna-protocol-06 (work in progress),
	progress), January 2007.		June 2007.
	[25] Ng, C., "Network Mobility Route Optimization Solution Space		[24] Janneteau, C., "IPv6 Multicast for Mobile Networks with MLD-
	Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in		Proxy", draft-janneteau-nemo-multicast-mldproxy-00 (work in
	progress), September 2006.		progress), April 2004.
	Appendix A. Change Log From Previous Version		Appendix A. Change Log From Previous Version
	o Initial Documentation		o Removed Use-Case Scenarios
			o Updated the Section4: use the references to existing documents
			o Removed the Approach Rationale
	Authors' Addresses		Authors' Addresses
	Ryuji Wakikawa		Ryuji Wakikawa
	Keio University and WIDE		Department of Environmental Information, Keio University
	5322 Endo Fujisawa Kanagawa		5322 Endo
			Fujisawa, Kanagawa
	252-8520		252-8520
	JAPAN		Japan
			Phone: +81-466-49-1100
			Fax: +81-466-49-1395
	Email: ryuji@sfc.wide.ad.jp		Email: ryuji@sfc.wide.ad.jp
			URI: http://www.wakikawa.org/
	Pascal Thubert		Pascal Thubert
	Cisco Systems		Cisco Systems
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue de Roumanille		400, Avenue de Roumanille
	Batiment T3		Batiment T3
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	Phone: +33 4 97 23 26 34		Phone: +33 4 97 23 26 34
	Email: pthubert@cisco.com		Email: pthubert@cisco.com
	Teco Boot		Teco Boot
	Infinity Networks B.V.		Infinity Networks B.V.
	Elperstraat 4		Elperstraat 4
	Schoonloo 9443TL		Schoonloo 9443TL
	Netherlands		Netherlands
	Phone: +31 592 50 12 66
	Email: teco@inf-net.nl		Email: teco@inf-net.nl
	Jim Bound		Jim Bound
	Hewlett-Packard		Hewlett-Packard
	PO BOX 570		PO BOX 570
	Hollis, NH 03049		Hollis, NH 03049
	USA		USA
	Phone: +603 465 3130		Phone: +603 465 3130
	Email: jim.bound@hp.com		Email: jim.bound@hp.com
	McCarthy Ben		McCarthy Ben
	Lancaster University		Lancaster University
	Computing Department, Lancaster University.		Computing Department, Lancaster University.
	InfoLab 21, South Drive		InfoLab 21, South Drive
	Lancaster, Lancashire LA1 4WA		Lancaster, Lancashire LA1 4WA
	UK		UK
	Phone: +44-1524-510-383		Phone: +44-1524-510-383
	Fax: +44-1524-510-492		Fax: +44-1524-510-492
	Email: b.mccarthy@lancaster.ac.uk		Email: b.mccarthy@lancaster.ac.uk
End of changes. 118 change blocks.
	758 lines changed or deleted		433 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/