< draft-clausen-nemo-ro-problem-statement-00.txt		draft-clausen-nemo-ro-problem-statement-01.txt >
	INTERNET-DRAFT Thomas Clausen
	IETF NEMO Working Group Emmanuel Baccelli		(MA)NEMO E. Baccelli
	Expiration: 15 April 2005 LIX, Ecole Polytechnique, France		Internet-Draft INRIA
	Ryuji Wakikawa		Expires: September 6, 2007 T. Clausen
	Keio University/WIDE		LIX, Ecole Polytechnique, France
	15 October 2004		R. Wakikawa
			Keio University, WIDE
			March 5, 2007
	NEMO Route Optimisation Problem Statement		NEMO Route Optimisation Problem Statement
	draft-clausen-nemo-ro-problem-statement-00.txt		draft-clausen-nemo-ro-problem-statement-01
	Status of this Memo		Status of this Memo
	This document is a submission to the Network Mobility Working Group		By submitting this Internet-Draft, each author represents that any
	of the Internet Engineering Task Force (IETF). Comments should be		applicable patent or other IPR claims of which he or she is aware
	submitted to the nemo@ietf.org mailing list.		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.
	Distribution of this memo is unlimited.
	By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,
	or will be disclosed, and any of which I become aware will be
	disclosed, in accordance with RFC 3668.
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that
	groups may also distribute working documents as Internet-Drafts.		other groups may also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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.
	Abstract		This Internet-Draft will expire on September 6, 2007.
	The NEMO working group has developed a protocol suite, extending the		Copyright Notice
	notion of edge-mobility on the Internet to include that of network
	mobility. This implies that a set of nodes, along with their mobile
	router, change their point of attachment and that traffic to these
	nodes is tunneled to be delivered through their new point of
	attachment. This mechanism is transparent to applications in that
	existing traffic to a node is being encapsulated and tunneled,
	regardless of where the network containing the destination node is
	attached.
	The NEMO specification is not limited to a single level of mobile		Copyright (C) The IETF Trust (2007).
	networks, attaching to the stationary Internet. Rather, arbitrary
	levels of nested mobile networks are supported, employing for each
	level of nesting the same encapsulation and tunneling mechanisms.
	With arbitrarily deep nested mobile networks, the overhead incurred		Abstract
	through tunneling and encapsulation of data traffic can, however,
	become large. As a consequence, a number of different proposals
	exist, which aim at performing "route optimization" for nested mobile
	networks.
	This document aims at describing the different scenarios in which		The NEMO basic support specification is not limited to a single level
	route-optimization is desired, as well as the different proposed		of mobile networks attaching to the stationary Internet. Rather,
	solutions for achieving route-optimization in nested mobile networks.		arbitrary levels of nested mobile networks are supported, employing
			for each level of nesting the same attachment, encapsulation and
			tunnelling mechanisms. With arbitrarily deep nested mobile networks,
			paths taken by data traffic can be extremely sub-optimal both inside
			the nested topology through successive mobile routers, and outside
			the nested topology, through successive Home Agents over the
			Internet. Moreover, the overhead incurred through tunnelling and
			encapsulation of data traffic can become prohibitively large. This
			document analyses the scenarios in which these problems are
			particularly acute.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5
	2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Internet - Nested NEMO Communication . . . . . . . . . . . 5
	2.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Intra Nested NEMO Communication . . . . . . . . . . . . . 6
	2.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. RFC3963 Loops . . . . . . . . . . . . . . . . . . . . . . 7
	3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. NEMO-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Lack of Nested Topology State Information . . . . . . . . 8
	3.1.1. Route Optimization Mechanisms Within Nested NEMO . . . . . . 9		4.2. Goals of Route Optimization for Nested NEMO networks . . . 9
	3.1.2. Ad-hoc Network of Mobile Routers . . . . . . . . . . . . . . 9		4.3. Solution Guidelines . . . . . . . . . . . . . . . . . . . 9
	3.2. Internet-to-NEMO . . . . . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	3.2.1. Route Optimization Mechanisms Initiated by MR or MNN . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	3.2.2. Route Optimization Initiated by a Non-Mobile Router . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
	9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10. Copyright . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The NEMO protocol suite extends Mobile IP in enabling a set of nodes,		The NEMO basic support specification [1] extends the notion of edge-
	along with their mobile router, to change their point of attachment		mobility on the Internet to include that of network mobility. This
	to the Internet. NEMO enables the traffic to these nodes to be tun-		implies that a set of nodes, along with their mobile router, change
	neled for delivery through their new point of attachment. The use of		their point of attachment and that traffic to these nodes is
	tunneling makes this mechanism transparent to applications, wherever		tunnelled to be delivered through their new point of attachment.
	the new point of attachement, even in case of several layers of		This mechanism is transparent to applications in that existing
	nested mobility (i.e. mobile nodes, or mobile routers, indirectly		traffic to a node is being encapsulated and tunnelled, regardless of
	accessing the Internet through other mobile routers).		where the network containing the destination node is attached.
	However, this approach is not without a certain cost: with arbitrar-		The NEMO basic support specification is furthermore not limited to a
	ily deep nested mobile networks, the overhead due to tunneling, dog-		single level of mobile networks attaching to the stationary Internet.
	leg routing and encapsulation of data traffic can become large. A		Rather, arbitrary levels of nested mobile networks are supported,
	number of different solutions have been proposed in order to optimize		employing for each level of nesting the same transparent mechanisms
	this routing in some of these cases.		relying on attachment, encapsulation and tunnelling.
	A review of some of these solutions is provided in this document, as		However, with arbitrarily deep nested mobile networks, paths taken by
	well as the discussion of which cases and to what extent route opti-		data traffic can become extremely sub-optimal both (i) inside the
	mization is desireable with NEMO.		nested topology through successive mobile routers, and (ii) outside
			the nested topology, through successive Home Agents over the
			Internet. Moreover, the overhead incurred through tunnelling and
			encapsulation of data traffic can become prohibitively large.
	1.1. Terminology		This document describes cases where problems due to sub-optimal data
			traffic paths and encapsulation overhead are acute, providing a
			discussion of which cases and to what extent route optimisation is
			desirable with NEMO.
			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 RFC2119 [5].		document are to be interpreted as described in RFC2119 [5].
	It is assumed that readers are familiar with NEMO terminology as		It is moreover assumed that readers are familiar with NEMO
	described and employed in [1] and [8].		terminology as described and employed in [1] and [2].
	1.2. Applicability
	This document aims at discussing scenarios where route optimization
	is desirable in a NEMO environment, and what level of route optimiza-
	tion is desired in those cases. A review of some existing solutions
	and ideas is thereby provided.
	2. Scenarios
	At least two distinct scenarios exist, where route optimization is		3. Deployment Scenarios
	desireable. Those are, respectively, when a node in a NEMO network
	wishes to communicate with a node in another NEMO network which is
	part of the same nesting, and when a node from the Internet wishes to
	communicate with a node in a nested NEMO network.
	While the scenarios may have commonalities, their possible solution-		Two categories of scenarios exist, where route optimisation is
	space differs and they are therefore described seperately below.		desirable. Those are, respectively: (i) when a host from the
			Internet wishes to communicate with a host in a nested NEMO, and (ii)
			when a host in a nested NEMO wishes to communicate with a host in
			another nested NEMO which is part of the same nested NEMO topology.
			Some of these issues are also elaborated in [4].
	2.1. NEMO-to-NEMO		3.1. Internet - Nested NEMO Communication
	In this scenario, a number of NEMO networks are nested to one		In this category of scenario, a number of NEMO networks are nested to
	another, and nodes in the different NEMO networks are communicating		one another, and a host in the Internet wishes to communicate with a
	with one another. For the purpose of this scenario description, refer		host in one of the NEMO networks. For the purpose of describing this
	to the schematics below:		scenario, the example depicted in Fig. 1 below is considered.
	---------- ---------- ----------		---------- ---------- ---------- ----------
	| | | | | |		| | | | | | | |
	| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet		| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Host 1 |
	| | | | | | |		| | | | | | | | |
	---------- ---------- ---------- |		---------- ---------- ---------- | ----------
	| ----------		| ----------
	---------- | | |		---------- | | |
	| | |----| HA 2 |		| | |----| HA 2 |
	| HA 1 |---------| | |		| HA 1 |---------| | |
	| | | ----------		| | | ----------
	---------- |		---------- |
	----------		----------
	| |		| |
	| HA 3 |		| HA 3 |
	| |		| |
	----------		----------
	Figure 1: Nested NEMO networks -- NEMO-to-NEMO communication		Figure 1: Nested NEMO networks -- Internet-to-NEMO communication
	We assume that each box labeled "NEMO x" refers to a Mobile Router		We assume that each box labelled "NEMO x" refers to a Mobile Router
	(MR), running the NEMO protocol, as well as the nodes attached to		(MR), running the NEMO protocol, as well as the hosts attached to
	that mobile router. We further assume, that each line indicates a		that mobile router. We further assume, that each line indicates a
	direct connection between routers -- i.e. the mobile router in "NEMO		direct connection between routers -- i.e. the mobile router in "NEMO
	1" has a direct connection to the mobile router in "NEMO 2". Each box		1" has a direct connection to the mobile router in "NEMO 2". Each
	labeled "HA x" refers to the Home Agent for the NEMO network x --		box labelled "HA x" refers to the Home Agent for the NEMO network x
	i.e. that HA 1 is the Home Agent for the mobile network NEMO 1.		-- i.e. that HA 1 is the Home Agent for the mobile network NEMO 1.
	If a node from NEMO 3 wishes to communicate with a node from "NEMO		The host labelled "Host 1" wishes to communicate with a host in NEMO
	1", then the data traffic would first be sent to the Home Agent of		1. Data traffic will first be routed through HA 1 the Home Agent of
	NEMO 1 -- i.e. to HA 1. At HA 1, a binding would exist, identifying		NEMO 1. At HA 1, a binding would exist, identifying NEMO 1 as being
	NEMO 1 as being attached to the network of NEMO 2. Thus, the traffic		attached to the network of NEMO 2. Thus, the traffic would be
	would be encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA		encapsulated, and sent to the HA of NEMO 2, i.e. HA 2. At HA 2, a
	2, a binding would exist, identifying that, indeed, NEMO 2 is		binding would exist, identifying that, indeed, NEMO 2 is attached to
	attached to the network of NEMO 3. Another encapsulation would		the network of NEMO 3. Another encapsulation would ensure, and the
	ensure, and the traffic sent to HA 3. At HA 3, a binding would		traffic sent to HA 3. At HA 3, a binding would identify the point of
	identify the point of attachment of NEMO 3 to the internet, and the		attachment of NEMO 3 to the internet, and the data traffic would be
	data traffic would be encapsulated one final time prior to being		encapsulated one final time prior to being delivered to NEMO 3 --
	delivered to NEMO 3 -- where decapsulation and handoff to NEMO 2,		where decapsulation and handoff to NEMO 2, then NEMO 1 occurs.
	then NEMO 1 occurs.
	In this scenario, short path between NEMO 1 and NEMO 3, without		This simple example scenario therefore involves communication with
	transversing the Internet and HA1-3, exists, however is not used in		(i) triple encapsulation of the data, and (ii) its transmission via 3
	the current NEMO specification.		arbitrary locations across the Internet. More generally, if instead
			of a depth 3 the nested NEMO structure had a depth N, the
			communication would involve worst case N levels of encapsulation of
			the data, and its transmission via N arbitrary locations across the
			Internet. This is thus very sub-optimal communication across the
			Internet ([3].
	More generally, assume a set of NEMO networks forming a connected		3.2. Intra Nested NEMO Communication
	network via their mobile routers without transversing the Internet.
	For communication between nodes in these NEMO networks, a solution
	should exist, which provides routes between the nodes without
	transversing the Internet and without incuring excessive nested
	encapsulations.
	2.2. Internet-to-NEMO		In this category of scenario, a number of NEMO networks are nested to
			one another, and hosts in the different nested NEMOs are
			communicating with one another. For the purpose of describing this
			scenario, the example depicted in Fig. 2 below is considered.
	In this scenario, a number of NEMO networks are nested to one		---------- ---------- ----------
	another, and a node in the Internet wishes to communicate to a node		| | | | | |
	in one of the NEMO networks. For the purpose of this scenario		| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet
	description, refer to the schematics below:		| | | | | | |
			---------- ---------- ---------- |
			| ----------
			---------- | | |
			| | |----| HA 2 |
			| HA 1 |---------| | |
			| | | ----------
			---------- |
			----------
			| |
			| HA 3 |
			| |
			----------
	---------- ---------- ---------- ----------		Fig. 2: Nested NEMO networks -- NEMO-to-NEMO communication
	| | | | | | | |
	| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Node 1 |
	| | | | | | | | |
	---------- ---------- ---------- | ----------
	| ----------
	---------- | | |
	| | |----| HA 2 |
	| HA 1 |---------| | |
	| | | ----------
	---------- |
	----------
	| |
	| HA 3 |
	| |
	----------
	Figure 2: Nested NEMO networks -- Internet-to-NEMO communication		If a host from NEMO 3 wishes to communicate with a host from NEMO 1,
			then the data traffic would first be sent out the nested NEMO
			network, over the Internet to HA 1. The data traffic would then be
			encapsulated and tunnelled to HA 2, which will in turn add another
			layer of encapsulation and tunnel the traffic to HA3 which will do
			the same before the data returns to our nested NEMO network.
			Successive decapsulation and transmission via NEMO 3, NEMO 2 and NEMO
			1 will then happen before data is delivered to the destination.
	The node labeled "Node 1" wishes to communicate with a node in NEMO		Again, this simple example scenario involves communication with (i)
	1. Similarly to the previous scenario, this will happen through con-		triple encapsulation of the data, and (ii) its transmission via 3
	necting to HA 1, then encapsulation and tunneling data to HA 2 and		arbitrary locations across the Internet. And again, more generally,
	HA3 before the data arrives at the edge of our nested NEMO network.		if instead of a depth 3 the nested NEMO structure had a depth N, the
			communication would involve N levels of encapsulation of the data,
			and its transmission via N arbitrary locations across the Internet.
			This is therefore very sub-optimal communication across the Internet,
			as communication inside the nested NEMO network should be sufficient.
	Only then can decapsulation and transmission via NEMO 3, NEMO 2 and		3.3. RFC3963 Loops
	NEMO 1 happen.
	In this scenario, while no direct link exists between Node 1 and the		[1] allows for NEMO mobile routers to nest to one another, however
	node in NEMO 1, triple encapsulation and transmission via HA1-3		does not stipulate how to form the links of the nest. In particular,
	occurs.		[1] allows for, as is illustrated in the following Fig. 3, NEMO 1 to
			select NEMO 2 as its point of attachment, with NEMO 2 selecting NEMO
			3 as point of attachment and NEMO 3 selecting NEMO 1 - thereby
			forming a loop. Absent other mechanisms, this loop will persist,
			potentially disconnecting both NEMO 1, NEMO 2 and NEMO 3 from the
			wider network, from the Internet, and - if traffic between NEMO nodes
			is tunnelled through HAs, also from each other. [1] does not provide
			functionality allowing to detect this loop: a MR cannot know whether
			it connects to a mobile network or a general IPv6 network.
	More generally, a path between a node in the Internet and the edge of		---------- ----------
	the nested NEMO networks exists, which does not necessarilly involve		| |--| |
	any of the Home Agents for the NEMO networks. For such communication,		| NEMO 1 | | NEMO 2 |
	a solution should exist which avoids nested encapsulations (i.e.		| | | |
	allows data to be encapsulated only once, in order to arrive at the		---------- ----------
	edge of the nested NEMO networks), and which does not force a path		| |
	which involves all the Home Agents of the nested NEMO networks on the		----------
	path to the destination.		| |
			| NEMO 3 |
			| |
			----------
	In addition, nested encapsulation brings a limitation to the number		Fig. 3: Loop in Nested NEMO networks
	of nested levels, due to MTU size. For example, the current NEMO
	basic support specification does not allow a level higher than 40 in
	nesting in NEMO (with usual MTU = 1500 bytes), due to the size of the
	40 IPv6 headers, i.e. 40 bytes x 40 > MTU. In this case IP fragmen-
	tation does not help, since the total size of IPv6 headers exceeds
	the MTU. Thus, the avoidance of nested encapsulations also eliminates
	the limitation on the level of nesting in NEMO.
	3. Solutions		4. Problem Statement
	Common for the scenarios from the previous section is, that the		Encapsulation and tunnelling specified by NEMO basic support [1] are
	encapsulation and tunneling is due to the facts that:		governed by the following principles:
	- the node which originates data traffic does not know where the		1. A router which forwards data traffic does not know where the
	destination node is located and therefore assumes that the		destination is located and therefore assumes that it is at its
	node is at its Home Network;		Home Network;
	- no router knows the full path to the destination, which in		2. A Home Agent does not know if a NEMO is directly or indirectly
	particular means that:		bound to the Internet, which in particular means that:
	- no router knows the topology of the nested NEMO network(s).		3. No router knows the topology of the nested NEMO network(s).
	As a concequence, each logical hop (from source to Home Agent of des-		While these principles are functional, they have the consequences
	tination, or from Home Agent to Home Agent of the nested NEMO net-		that are described in the following.
	works) adds layers of encapsulation, until the point of attachment
	between the Internet and the NEMO edge, the Access Router (AR) is
	reached.
	Concequently, if the source node, or any intermediate node, had addi-		4.1. Lack of Nested Topology State Information
	tional information about the network topology, more beneficial
	tunnels could be created, and less encapsulation would be required.
	For example if, in figure 2 above, Node 1 knew directly that the		The lack of state information about the nested NEMO topology and its
	gateway from the Internet to "the network where nodes from NEMO 1 are		point(s) of attachment to the Internet causes routing to involve
	attached" was the Access Router of NEMO 3, and if the mobile router		logical hops (from source to Home Agent of destination, or from Home
	in NEMO 3 knew the topology of the nested NEMO network, a tunnel		Agent to Home Agent), each of those adding a layer of encapsulation
	could be directly created from Node 1 to NEMO 3, with assurance that		and a detour across the Internet, until a point of attachment between
	the mobile router in NEMO 3 would be able to route data packets cor-		the Internet and the nested NEMO network is reached.
	rectly to the destination.
	3.1. NEMO-to-NEMO		This lack causes extreme data paths sub-optimality and extreme data
			encapsulation overhead in cases where the nested topology is of depth
			greater than 2, as depicted in Section 3.2 and Section 3.1.
	The NEMO-to-NEMO problem, as described in section 2.1, is one of how		The following items summarise the problems incurring from lack of
	to avoid transversing the Internet in order to communicate between		nested topology state information:
	two nodes which are part of the same nested NEMO network. More gener-
	ally, this can be expressed as "how traffic is routed within the NEMO
	network".
	NEMO basic support [1] specifies that traffic be routed via Home		Internet Route Suboptimality - where traffic from the internet
	Agents, indicating an assumption of limited depth of nested networks		transverses more than one HA, incurring both route sub-optimality
	and traffic patterns being predominantly traffic of the Internet-to-		and nested encapsulation;
	NEMO type. Each mobile router in a NEMO network knows only of its
	attachments, i.e. its access router and the nodes within its own
	mobile network. A mobile router in NEMO does not know about any nest-
	ings, i.e. it does not know the topology of the nested NEMO network
	-- and as such, can only provide routes to the Home Agents on the
	Internet.
	In order to avoid the scenario described in section 2.1, where data		Intra-NEMO Route Suboptimality - where traffic between hosts in the
	packets for delivery within the nested NEMO network are routed		nested NEMO network is forced through the Internet gateway and
	through the Internet and the nested networks Home Agents, when a more		subsequently through one or more HAs, incurring both route sub-
	localized aproach would have been possible, additional state can be		optimality and nested encapsulation;
	maintained in the nested NEMO networks. A number of approaches for
	maintaining state in mobile routers and/or Home Agents of mobile net-
	works have been discussed, including [3], [4], [9], [10], [11], [12],
	[13], in which techniques such as route caching are discussed. These
	techniques can be deployed in Home Agents, in routers, specifically
	designated as aggregation points for NEMO tunnels, as well as within
	the mobile routers in order to optimize routes within a nested NEMO
	network. This is detailed in section 3.1.1.
	Essentially, however, the issue of route optimization within a nested		Intra-NEMO loops - where, due to unfortunate selection of which MR
	NEMO network is one of routing: maintaining state in each mobile		is attaching to which MR, loops occur.
	router such that an intelligent forwarding decision can be made.
	I.e., if the destination can be detected to be "local" to the nest of
	NEMO networks, a route to the destination can be constructed directly
	through the NEMO mobile routers without passing through the Home
	Agents. Alternatively, if the destination is not local, data are
	routed to the Home Agent, where basic NEMO tunneling and encapsula-
	tion take effect. Deploying a routing protocol for maintaining suffi-
	cient state in the nodes in the nested NEMO network is detailed in
	section 3.1.2.
	3.1.1. Route Optimization Mechanisms Within Nested NEMO		4.2. Goals of Route Optimization for Nested NEMO networks
	Some approaches have been proposed to tackle the problem of route		The goal of route optimisation for nested NEMO is to alleviate the
	optimization inside nested NEMO networks. For instance, Nested NEMO		problems regarding (i) Internet route sub-optimality, (ii) Intra-NEMO
	Tree Discovery [4] offers a mechanism that aims at avoiding routing		route sub-optimality, and (iii) Intra-NEMO loops. Additional
	loops by organizing and maintaining a tree structure within the net-		information about the nested topology must be available to Mobile
	work of nested NEMOs, the root being the Access Router or the Mobile		Routers and/or Home agents, which:
	Router directly connected to the Access Router (the Top Level Mobile
	Router).
	Source routing is also proposed to be used in this environment.		o may serve to allow NEMO MRs to detect and alleviate loops or to
	Approaches like RRH [12] use the recording of the sequences of tra-		prevent such from occurring in the first place. Specifically,
	versed Mobile Routers on the way out of the nested NEMO network (to		this allows a NEMO MR to ensure that a loop-free path to the
	the Internet, say, to bind) in order to forward traffic efficiently		Internet Gateway exists;
	in the nested NEMO network.
	On the other hand, approaches like ORC (Optimized Route Cache Proto-		o may serve to establish and maintain an intra-NEMO routing mesh,
	col [3]) could be adapted to serve the purpose of insuring some level		allowing to bypass the Internet Gateway and HAs for intra-NEMO
	of optimized routing inside nested NEMO networks. Some router, say		communications;
	the top level mobile router, could be configured to play a role simi-
	lar to a correspondent router, organizing the forwarding of packets
	inside the nested NEMO network. This special router could be dynami-
	cally discovered inside the nested NEMO network.
	A more general form of this mechanism would be to have each MR in the		o may serve to bypass dog-leg routing in communications from sources
	nested NEMO network possess this extended information about the		on the Internet to a mobile node in the nested NEMO network.
	nested NEMO network. This does then, de-facto, become a situation
	where each MR knows the entire topology of the nested NEMO network,
	and will be able to act in the capacity of router for such traffic.
	This generalized mechanism is described in more details in section
	3.1.2.
	3.1.2. Ad-hoc Network of Mobile Routers		4.3. Solution Guidelines
	A NEMO network consists of a mobile router, to which a set of nodes		A solution to the NEMO Route Optimisation problem will:
	are (statically) attached. The mobile router communicates with (i.e.
	has direct links with) other mobile routers, and possibly with the
	Internet at large. As such, a NEMO network is not much different from
	any other network. What makes NEMO networks different from other net-
	works is, that they may change their point of attachment at will --
	i.e. the topology formed by NEMO mobile routers is dynamic.
	Thus, in order to provide routes between any two nodes in the nested		o provide a mechanism whereby each MR has sufficient topological
	NEMO network, a mechanism must be in place which ensures that the		awareness such that it may select the router(s) to which it
	dynamic topology of the nested NEMO network can be accurately tracked		attaches such that routing loops are avoided;
	and used for routing table calculations.
	The IETF MANET working group has been developing routing protocols		o provide a mechanism whereby each MR has sufficient topological
	for dynamic ad-hoc networks, such as OLSR [2] and AODV [6] (both		awareness such that it may select a suitable path towards the
	RFC), with the characteristics that the developed protocols should be		Internet Gateway for communication towards the Internet and - in
	light-weight, able to react to rapid topology changes and limit the		particular - towards its HA;
	signalling overhead. An approach to route optimization within the
	NEMO-to-NEMO scenario could therefore be to consider the mobile
	routers of the nested NEMO networks as nodes in an ad-hoc network,
	and run an ad-hoc routing protocol to ensure that each mobile router
	would be able to determine if data could be locally (i.e. within the
	nested NEMO network) delivered, or had to be tunneled back to the
	Home Agent.
	OLSR [2], for example, provides light-weight OSPF-like [7] routing		o provide a mechanism whereby each Internet Gateway has sufficient
	functionality. This includes efficient maintenance of the topology		topological awareness such that it may select a suitable path
	spanned by the links between the mobile routers in the face of net-		towards each MR in the nested NEMO network for which it is
	work dynamics, as well as the ability for a mobile router to adver-		providing Internet access;
	tize associated nodes which do not run the OLSR routing protocol
	(e.g. nodes associated to a mobile router, which are not themself
	mobile routers). It is also possible for Mobile Network Nodes to
	obtain global connectivity, as described in [16].
	Employing a protocol such as OLSR among the mobile routers in a		o provide a mechanism whereby each MR has sufficient topological
	nested NEMO network would yield the ability for any mobile router to		awareness such that it may select a suitable path towards another
	determine if a destination can be reached through a path local to the		MR within the NEMO without transversing the Internet Gateway;
	nested NEMO network, or if forwarding to the Home Agent is required.
	Additionally, this would also ease the Internet-to-NEMO scenario. In
	order to deliver an IP datagram to a node in the nested NEMO network,
	only a path to the access router between the nested NEMO network and
	the Internet would be required: once an IP datagram arrives in the
	nested NEMO network, the routing tables in the mobile routers, as
	provided by OLSR, would allow direct routing to the destination.
	Thus, there would no longer be a requirement to do nested encapsula-
	tion on each logical hop (i.e. each transversal of a Home Agent) in
	order to be able to decapsulate and correctly forward IP datagrams in
	the nested NEMO network.
	Thus even if no route optimizations are performed in the Internet-to-		o provide a mechanism whereby each MR has sufficient topological
	NEMO scenario, an overhead reduction can still be achieved through		awareness such that it may provide suitable binding updates with
	much lower encapsulation requirements.		its HA. A particular case of this is if the MR can provide
			binding updates such that multiple encapsulations and sub-optimal
			routes on the Internet can be avoided when a MR is connected to
			the Internet Gateway through multiple intermediate MRs in the NEMO
			nest.
	3.2. Internet-to-NEMO		Mechanisms developed for maintaining and using such information must
			address the distributed, multi-hop nature of nested NEMO networks,
			and be able to follow topology and connectivity changes by updating
			state information in Mobile Routers and/or Home Agents accordingly.
	The goal here is, again, to avoid unnecessary encapsulation and dog-		Solutions must achieve their task while being conservative in their
	leg routing. Indeed, it is desirable to avoid letting the level of		network resource consumption and while avoiding prohibitively long
	nested mobility on the edges of the network dictating the number of		delays.
	Home Agents (and therefore the amount of encapsulation) the packets
	have to go through. There should be a way to limit the level of tun-
	neling to only one encapsulation IP in IP, and at the same time, min-
	imize the traffic relayed by Home Agents.
	Existing solution to route optimization problems in NEMO therefore		5. Security Considerations
	aim at, basically, minimizing the required amount of tunneling in
	various nested mobility cases. They can be categorized as follows:
	- route optimization initiated by Mobile Routers (MR) or Mobile		This document does currently not specify security considerations.
	Network Nodes (MNN);
	- route optimization initiated by intermediate non-mobile		6. IANA Considerations
	routers on the path to Corresponding Nodes.
	The following sub-sections briefly review these solutions.		This document does currently not specify IANA considerations.
	3.2.1. Route Optimization Mechanisms Initiated by MR or MNN		7. References
	In case of nested mobility (i.e. a mobile router attaches to another		[1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	mobile router, or a visiting mobile node attaches to a mobile		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	router), several encapsulations will occur on top of each other, and		2005.
	a sub-optimal path will be used to reach the destination, going
	through each and every Home Agent. In order to slim this down, sev-
	eral nested tunnel optimizations have been discussed.
	The HMIP-like mechanisms suggested in [15] or the TLMR (Top Level		[2] Ernst, T. and H-Y. Lach, "Network Mobility Support Terminology",
	Mobile Router [11]) approach use one or more Mobile Routers chosen		draft-ietf-nemo-terminology-06 (work in progress), 2006.
	for their location (closest to the Access Router) to act as proxy for
	Mobile IP, and/or act as Home Agents for other mobile nodes inside
	the attached mobile networks, like proposed in [14]. Instead of
	adding another layer encapsulation, those TLMR switch between ingress
	and egress tunnels and can reduce the amount of binding.
	Similarily, ARO (Access Router Option [13]) proposes nested tunnel		[3] NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
	optimizations based on the registration of the top level Access		Route Optimization Solution Space Analysis",
	Router of any nested NEMO to the Home Agent in order to bypass the		draft-ietf-nemo-ro-space-analysis-03 (work in progress), 2006.
	HAs of all the MR on the way to the Access Router.
	On the other hand, source routing approaches like RRH (Reverse		[4] NG, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility
	Routing Header [12]) or Path Control Header [9] use loose source		Route Optimization Problem Statement",
	routing in order to avoid IP encapsulation. However, source routing		draft-ietf-nemo-ro-problem-statement-03 (work in progress),
	is not always desirable, and might not be widely accepted.		2006.
	3.2.2. Route Optimization Initiated by a Non-Mobile Router		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
			Levels", RFC 2119, 1997.
	Some approaches such as ORC (Optimized Route Cache Protocol [3]) or		Authors' Addresses
	other proposals using so called Anchor Routers or Correspondent side
	routers (see [10] for further references), advocate the adding of new
	functionalities in some routers that are ideally chosen to be opti-
	mally placed with respect to traffic flows between ASs. Those routers
	intercept and terminate the tunneling on behalf of the Correspondent
	Node, therefore optimizing the route from then on. However, this is
	not easy to deploy, and the optimization is partial.
	4. Acknowledgements		Emmanuel Baccelli
			INRIA
	The authors would like to thank Hitachi Labs Europe for their support.		Phone: +33 1 69 33 55 11
			Email: Emmanuel.Baccelli@inria.fr
	5. Authors' Addresses		Thomas Heide Clausen
			LIX, Ecole Polytechnique, France
	Thomas Heide Clausen,		Phone: +33 6 6058 9349
	Project PCRI
	Pole Commun de Recherche en Informatique du plateau de Saclay,
	CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
	Ecole polytechnique,
	Laboratoire d'informatique,
	91128 Palaiseau Cedex, France
	Phone: +33 1 69 33 40 73,
	Email: T.Clausen@computer.org		Email: T.Clausen@computer.org
			URI: http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
	Emmanuel Baccelli
	HITACHI Labs Europe/ Project PCRI,
	Pole Commun de Recherche en Informatique du plateau de Saclay,
	CNRS, Ecole Polytechnique, INRIA, Universite Paris Sud,
	Ecole polytechnique,
	Laboratoire d'informatique,
	91128 Palaiseau Cedex, France
	Phone: +33 1 69 33 40 73,
	Email: Emmanuel.Baccelli@inria.fr
	Ryuji Wakikawa		Ryuji Wakikawa
	Keio University and WIDE		Keio University, WIDE
	5322 Endo Fujisawa Kanagawa
	252 JAPAN
	Phone: +81-466-49-1394
	EMail: ryuji@sfc.wide.ad.jp
	Fax: +81-466-49-1395
	6. References
	[1] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo
	Basic Support Protocol (work in progress). Internet Draft (draft-
	ietf-nemo-basic-support-02), Internet Engineering Task Force,
	December 2003.
	[2] T. Clausen, P. Jacquet, Optimized Link State Routing Protocol.
	Request for Comments (Experimental) 3626, October 2003.
	[3] R. Wakikawa, M. Watari. Optimized Route Cache Protocol (ORC) (work
	in progress). Internet Draft (draft-wakikawa-nemo-orc-00.txt),
	Internet Engineering Task Force, July 2004.
	[4] P. Thubert, N. Montavont. Nested Nemo Tree Discovery (work in
	progress). Internet Draft (draft-thubert-tree-discovery-00.txt),
	Internet Engineering Task Force, May 2004.
	[5] S. Bradner. Key words for use in RFCs to Indicate Requirement Lev-
	els. Request for Comments (Best Current Practice) 2119, Internet
	Engineering Task Force, March 1997.
	[6] C. Perkins, E. Belding-Royer, S. Das. Ad hoc On-Demand Distance Vec-
	tor (AODV) Routing, Request for Comments (Experimental) 3561, July
	2003
	[7] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[8] T. Ernst, H-Y. Lach. Network Mobility Support Terminology (work in
	progress). Internet Draft (draft-ietf-nemo-terminology-01), Inter-
	net Engineering Task Force, February 2004.
	[9] Jongkeun Na et al. Route Optimization Scheme based on Path Control
	Header (work in progress). Internet Draft (draft-na-nemo-path-con-
	trol-header-00), Internet Engineering Task Force, April 2004.
	[10] P. Thubert et al. Taxonomy of Route Optimization models in the Nemo
	Context (work in progress). Internet Draft (draft-thubert-nemo-ro-
	taxonomy-02), Internet Engineering Task Force, February 2004.
	[11] H. Kang et al. Route Optimization for Mobile Network by Using Bi-
	directional Between Home Agent and Top Level Mobile Router (work in
	progress). Internet Draft (draft-hkang-nemo-ro-tlmr-00.txt), Inter-
	net Engineering Task Force, June 2003.
	[12] P. Thubert et al. IPv6 Reverse Routing Header and its application
	to Mobile Networks (work in progress). Internet Draft (draft-thu-
	bert-nemo-reverse-routing-header-05), Internet Engineering Task
	Force, June 2004.
	[13] C. Ng et al. Securing Nested Tunnels Optimization with Access
	Router Option (work in progress). Internet Draft (draft-ng-nemo-
	access-router-option-01), Internet Engineering Task Force, July
	2004.
	[14] E. Perera et al. Extended Network Mobility Support (work in		Phone: +81-466-49-1394
	progress). Internet Draft (draft-perera-nemo-extended-00.txt),		Email: Ryuji@sfc.wide.ad.jp
	Internet Engineering Task Force, July 2003.
	[15] H. Ohnishi et al. HMIP based Route Optimization Method in a Mobile		Full Copyright Statement
	Network (work in progress). Internet Draft (draft-ohnishi-nemo-ro-
	hmip-00.txt), Internet Engineering Task Force, April 2003.
	[16] R. Wakikawa et al. Global Connectivity for IPv6 Mobile Ad Hoc Net-		Copyright (C) The IETF Trust (2007).
	works (work in progress). Internet Draft (draft-wakikawa-manet-
	globalv6-03.txt), Internet Engineering Task Force, October 2003.
	7. Changes		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 is the initial version of this specification.		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.
	8. IANA Considerations		Intellectual Property
	This document does currently not specify IANA considerations.		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.
	9. Security Considerations		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.
	This document does not specify any security considerations.		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.
	10. Copyright		Acknowledgment
	Copyright (C) The Internet Society (2004). 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		Funding for the RFC Editor function is provided by the IETF
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		Administrative Support Activity (IASA).
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
	MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
	OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
End of changes. 91 change blocks.
	481 lines changed or deleted		333 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/