< draft-thubert-nemo-ro-taxonomy-02.txt		draft-thubert-nemo-ro-taxonomy-03.txt >
	Network Working Group P. Thubert		NEMO Working Group C. Ng
	Internet-Draft M. Molteni		Internet-Draft Panasonic Singapore Labs
	Expires: August 15, 2004 Cisco Systems		Expires: April 25, 2005 P. Thubert
	C. Ng		Cisco Systems
	Panasonic Singapore Labs
	H. Ohnishi		H. Ohnishi
	NTT		NTT
	E. Paik		E. Paik
	Seoul National Univ.		KT
	February 15, 2004		October 25, 2004
	Taxonomy of Route Optimization models in the Nemo Context		Taxonomy of Route Optimization models in the NEMO Context
	draft-thubert-nemo-ro-taxonomy-02		draft-thubert-nemo-ro-taxonomy-03
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is subject to all provisions
	all provisions of Section 10 of RFC2026.		of section 3 of RFC 3667. By submitting this Internet-Draft, each
			author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
			RFC 3668.
	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 http://		The list of current Internet-Drafts can be accessed at
	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 15, 2004.		This Internet-Draft will expire on April 25, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	NEMO enables Mobile Networks by extending Mobile IP to support Mobile		With current Network Mobility (NEMO) Basic Support, all
	Routers. This memo documents how the MIPv6 concept of Route		communications to and from mobile network nodes must go through the
	Optimization can to be adapted for NEMO to optimize traffic routing		MR-HA tunnel when the mobile network is away. This results in
	between nodes in a mobile network and their correspodnet nodes.		increased length of packet route and increased packet delay. To
	Different route optimizations schemes are discussed, including:		overcome these limitations, one might have to turn to route
			optimization (RO) for NEMO. This memo documents various types of
			route optimization in NEMO, and explores the benefits and tradeoffs
			in different aspects of NEMO route optimization.
	1. route optimization with corresponding nodes initiated bu mobile		Table of Contents
	routers on behalf of the mobile network nodes;
	2. a visiting mobile node performing MIPv6 RO over the NEMO base		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	protocol;		2. Problem Statement of NEMO Route Optimization . . . . . . . . . 4
			2.1 Sub-Optimality with NEMO Basic Support . . . . . . . . . . 4
			2.2 Nesting of Mobile Networks . . . . . . . . . . . . . . . . 5
			2.3 MIPv6 Host in Mobile Networks . . . . . . . . . . . . . . 7
			2.4 Communications within a Mobile Networks . . . . . . . . . 7
			3. Solution Space of NEMO Route Optimization . . . . . . . . . . 8
			3.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . . . 9
			3.2 Infrastructure Optimization . . . . . . . . . . . . . . . 10
			3.3 Nested Tunnels Optimization . . . . . . . . . . . . . . . 11
			3.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . . . 12
			3.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . . . 13
			4. Analysis of Solution Space . . . . . . . . . . . . . . . . . . 14
			4.1 General Considerations of RO Solution . . . . . . . . . . 14
			4.1.1 Additional Signaling Overhead . . . . . . . . . . . . 14
			4.1.2 Increased Protocol Complexity . . . . . . . . . . . . 15
			4.1.3 Mobility Awareness . . . . . . . . . . . . . . . . . . 15
			4.1.4 New Functionalities . . . . . . . . . . . . . . . . . 15
			4.1.5 Other Considerations . . . . . . . . . . . . . . . . . 17
			4.2 Specific Types of RO Solution . . . . . . . . . . . . . . 17
			4.2.1 MR-to-CN Optimization . . . . . . . . . . . . . . . . 17
			4.2.2 Infrastructure Optimization . . . . . . . . . . . . . 19
			4.2.3 Nested Tunnels Optimization . . . . . . . . . . . . . 20
			4.2.4 MIPv6-over-NEMO Optimization . . . . . . . . . . . . . 21
			4.2.5 Intra-NEMO Optimization . . . . . . . . . . . . . . . 23
			5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
			6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
			7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
			A. Proposed Route Optimizations . . . . . . . . . . . . . . . . . 29
			A.1 MR-to-CN Optimizations . . . . . . . . . . . . . . . . . . 29
			A.2 Infrastructure Optimizations . . . . . . . . . . . . . . . 29
			A.3 Nested Tunnel Optimizations . . . . . . . . . . . . . . . 30
			A.4 MIPv6-over-NEMO Optimizations . . . . . . . . . . . . . . 32
			A.5 Intra-NEMO Optimizations . . . . . . . . . . . . . . . . . 33
			Intellectual Property and Copyright Statements . . . . . . . . 34
	3. performing RO over the routing infrastructure involving		1. Introduction
	optimizing the route between two routers situated near to each
	end point, instead of end-to-end; and
	4. minimizing the number of tunnels required when there is multiple		With current Network Mobility (NEMO) Basic Support [1], all
	levels of nesting.		communications to and from nodes in a mobile network must go through
			the bi-directional tunnel established between the mobile router (MR)
			and its home agent (HA) when the mobile network is away. Although
			such an arrangement allows mobile network nodes (MNNs) to reach and
			be reached by any node on the Internet, there are associated
			limitations which might be unacceptable for certain applications. To
			substantially ameliorate these limitations, one might have to turn to
			route optimization (RO) for NEMO. Here, we use the term "route
			optimization" to loosely refer to any approach that optimize the
			route taken by packets sent between a mobile network node and
			correspondent node (CN).
	Table of Contents		This document aims to explore limitations inherent in NEMO Basic
			Support, and analyze the possible approaches to route optimization
			with NEMO. It is expected for readers to be familiar with general
			terminologies related to mobility in [2] and [3], and NEMO related
			terms defined in [4]. In addition, it is beneficial to keep in mind
			the design requirements of NEMO [5]. A point to note is that since
			this document discusses aspects of route optimization, the readers
			may assume that a mobile network or a mobile host is away when they
			are mentioned throughout this document, unless it is explicitly
			specified that they are at home.
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		It is the objective of this document to address the need for a route
	2. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		optimization analysis in the NEMO Working Group. To quote the
	3. MIPv6 Route Optimization over NEMO . . . . . . . . . . . . . . 4		charter of the NEMO Working group:
	4. Optimization within the infrastructure . . . . . . . . . . . . 4
	4.1 Route Optimization within a ISP network . . . . . . . . . . . 5
	4.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 6
	4.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . . . 7
	5. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 8
	5.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 8
	5.2 Route Optimization inside the Nested Mobile Network . . . . . 12
	6. General Considerations . . . . . . . . . . . . . . . . . . . . 12
	6.1 Securing the protocol in nested tunnels optimization . . . . . 12
	6.2 Recursive complexity in route optimization . . . . . . . . . . 12
	6.3 Mobile Access router selection . . . . . . . . . . . . . . . . 13
	6.4 Mobility transparency and RO . . . . . . . . . . . . . . . . . 14
	6.5 Multihoming Considerations . . . . . . . . . . . . . . . . . . 15
	7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . 19
	1. Introduction		"... The WG will work on: ... ... [an] informational document
			which specifies a detailed problem statement for route
			optimization and looks at various approaches to solving this
			problem. This document will look into the issues and tradeoffs
			involved in making the network's movement visible to some nodes,
			by optionally making them "NEMO aware". The interaction between
			route optimization and IP routing will also be described in this
			document. Furthermore, security considerations for the various
			approaches will also be considered. ..."
	This document assumes the reader is familiar with Mobile IPv6 defined		To such end, this document first describes the problem of route
	in [1], with the concept of Mobile Router (MR) and with the Nemo		optimization in NEMO in Section 2. Next, we explore into various
	terminology defined in [2].		possible approaches to solving the problem of route optimization in
			Section 3. Following this, Section 4 discusses various issues that a
			route optimization solution might face. Finally, Section 5 concludes
			this memo. In addition, we attempt to list various proposed
			solutions for route optimization in Appendix A, and classify them
			according to the solution space described in Section 3.
	From the discussions on the mailing list, it appears that the common		2. Problem Statement of NEMO Route Optimization
	current understanding of the problem space of Route Optimization
	(RO), in the Nemo context, is still limited.
	This draft attempts to clarify the state of the discussion and		In essence, the problem of route optimization in NEMO is to eliminate
	propose a taxonomy of the various aspects of the problem. We will		limitations, or sub-optimality, introduced by the bi-directional
	look at different possible types of route optimizations related to		tunnel between a mobile router and its home agent (also known as the
	mobile network.		MR-HA tunnel). In the following sub-sections, we will describe the
			effects of sub-optimal routing with NEMO-Basic Support, and how they
			get amplified with nesting of mobile networks. We will also look
			into the nesting of a Mobile IPv6 (MIPv6) host in a mobile network.
			In addition, we will explore the impact of MR-HA tunnel on
			communications between two mobile network nodes (MNNs) on different
			links of the same mobile network.
	Firstly, the Mobile Router can initiate route optimization with		Readers might be interested to note the availability of [6] which
	corresponding nodes (CN) on behalf of the mobile network nodes (MNN).		also discusses the problem statement of NEMO route optimization.
	Secondly, we consider the feasibility of having a visiting mobile		2.1 Sub-Optimality with NEMO Basic Support
	node (VMN) performing MIPv6 RO over the NEMO base protocol.
	Thirdly, we explore the prospect of performing RO over the routing		With NEMO Basic Support, all packets sent between a mobile network
	infrastructure. This involves optimizing the route between two		node and its correspondent node are forwarded through the MR-HA
	routers situated near to each end point.		tunnel. This results in a sub-optimal routing, also known as
			"dog-leg routing", with NEMO Basic Support. This sub-optimality has
			the following undesirable effects:
	Lastly, route optimizations involving nested mobile networks are		o Longer route leading to increased delay
	explored. This involves minimizing the number of tunnels required
	when there is multiple levels of nesting.
	2. MR-to-CN		Because a packet must transit from a mobile network to the home
			agent then to the correspondent node, the transit time of the
			packet is always higher than if the packet were to go straight
			from the mobile network to the correspondent node. In the best
			case, where the correspondent node resides near the home agent,
			the increase in packet delay is minimal. In the worst case, where
			both the mobile network and the correspondent node are located at
			a point furthest away from the home agent on the Internet, the
			increase in delay is tremendous. Applications such as real-time
			multimedia streaming may not be able to tolerate such increase in
			packet delay.
	This section covers the case where the Route Optimization is		o Increased packets overhead
	performed between the MR and the correspondent nodes which mobile
	network nodes (MNNs) are communicating with. This scenario is useful
	when a lot of MNNs in a mobile network is communicating with a few
	corresponding nodes. In such cases the MR only needs to send one
	binding update (BU) to optimized the route between CN and a few MNNs.
	A major issue with this form of optimization is that the end-to-end		The encapsulation of packets in the MR-HA tunnel results in
	principle of the MIPv6 Reverse Routability (RR) test is broken. The		increased packet size due to addition of an outer packet. This
	RR test is meant to ensure the care-of address (CoA) and the home		reduces the bandwidth efficiency, as IPv6 header can be quite
	address (HoA) are collocated. With a mobile network, when the MR		substantial (at least 40 bytes).
	performs RO on behalf of the MNNs, the CoA in BU will be the MR's
	CoA. Thus, a MNN is reachable via the CoA, but not at the CoA.
	Some tricks may be performed on the fly by the MRs but it seems that		o Increased processing delay
	a clean MR-to-CN optimization for Nemo will impact the CN function.
	Once we modify the CN behavior, we need to introduce a negotiation		The encapsulation of packets in the MR-HA tunnel also results in
	from the start of the RR test to determine the protocol. In		increased processing delay at the points of encapsulation and
	particular, the Mobile Node and the CN must decide whether checking		decapsulation.
	the collocation is possible, and if not, whether a CN is willing to
	accept the risk. If not, the optimization may be limited to
	triangular routing MR->CN->HA->MR.
	This is a major evolution from [1], since MIPv6 has no such		o Increased chances of packet fragmentation
	negotiation capability at this time.
	3. MIPv6 Route Optimization over NEMO		The increased in packet size due to packet encapsulation may
			increase the chances of the packet being fragmented along the
			MR-HA tunnel. This can occur if there is no prior path MTU
			discovery conducted, or if the MTU discovery mechanism did not
			take into account the encapsulation of packets. Packets
			fragmentation will result in a further increase in packet delays,
			and further reduction of bandwidth efficiency.
	MIPv6 mobile nodes can move everywhere. If the user brings mobile		2.2 Nesting of Mobile Networks
	nodes (e.g. MIP VoIP terminal) into the vehicle that supports NEMO
	function, packets destined to the mobile node will have to be routed
	not only to its home agent but also the home agent of the mobile
	router. This pattern resembles Nested NEMO case which is described in
	later section. This solution is needed to use both MIPv6 and NEMO
	technologies efficiently.
	When a Mobile Node visits a Mobile Network, the best Route		With nesting of mobile networks, the use of NEMO Basic Support
	Optimization is obtained if the path in the Infrastructure is the		further amplifies the sub-optimality of routing. We call this the
	same as if the Mobile Network was attached at the attachment point of		amplification effect of nesting, where the (undesirable) effects of
	the Mobile Router (i.e., there is not additional Tunneling that is		sub-optimal routing with NEMO Basic Support is amplified with each
	linked to NEMO).		level of nesting of mobile networks. This is best illustrated by an
			example shown in Figure 1.
	A possible approach to this is to extend the solution for nested		HAofMR1
	mobile network optimization to include VMN as well. In this case,		+-----------|---------+
	the VMN is treated as though it is an MR. This type of solution will		HAofMR2 --| Internet |---CN
	most likely require some extensions for a MIPv6 VMN and CN.		+---------------|-----+
			/ Access Router
			HAofMR3 |
			====?========
			MR1
			|
			====?===========?===========?===
			MR5 MR2 MR6
			| | |
			==|======= ===?====== ======|==
			LFN2 MR3 LFN3
			|
			==|=========?==
			LFN1 MR4
			|
			=========
	4. Optimization within the infrastructure		Figure 1: An example of nested Mobile Network
	This section elaborates on cases where the Route Optimization is		Using NEMO Basic Support, the flow of packets between a Local Fixed
	performed within the Routing Infrastructure. This model is useful		Node LFN1 and a correspondent node CN would need to go through three
	when an ISP wants to control the route optimization procedures and		separate tunnels, illustrated in Figure 2 below.
	does not desire to add any functions to the CN or the MR in order to
	achieve route optimizations between CN and LFN.
	In this model, both the LFN behind the MR and the Correspondent can		----------.
	be MIP agnostic. The drawback is the introduction of Mobile Routes in		--------/ /----------.
	specific Routers, causing additional signaling and load to the		-------/ | | /-------
	Routing Fabric.		CN ------( - - | - - - | - - - | - - - | - - (------- LFN
			HAofMR3-------\ | | \-------MR3
			HAofMR2--------\ \----------MR2
			HAofMR1---------MR1
	The general idea is that there is a correspondent-side router (C-side		Figure 2: Nesting of Bi-Directional Tunnels
	Router) in the infrastructure that is located "closer" to the CN than
	the HA of the MR. This C-side Router can terminate MIP on behalf of
	the CN.
	Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent		This leads to the following problems:
	# n #
	o # n # # :== Tunnel
	o # n # o :== Optimized
	o # n # n :== Non-Optimized
	o # n #
	################################## n #
	C-Side oooooooooooooooooooooooooooooooo Mobile
	Router ################################ Router
	|
	====Mobile Network=======
	Optimization in the Infrastructure		o 'Pinball' routing
	This optimization is only valid when the path via the C-side Router		Both inbound and outbound packets will flow via the HAs of all the
	is shorter than the path via the Home Agent.		MRs on their path within the NEMO, with increased latency, less
			resilience and more bandwidth usage. To illustrate this effect,
			Figure 3 below shows the route taken by a packet sent from LFN1 to
			CN:
	The Optimization can take place independently for the 2 directions of		+--> HAofMR3 ---------------------+
	the traffic:		| |
			+----------------- HAofMR2 <--+ |
			| |
			+---------------+ |
			| V
			HAofMR1 <------+ CN
			|
			|
			LFN1 --> MR3 --> MR2 --> MR1
	Egress		Figure 3: 'Pinball' Routing
	The MR locates the C-side Router, establishes a tunnel with that		For more illustration of the pinball routing, see [7].
	Router and sets a route to the Correspondent Node via the C-side
	Router over the Tunnel. After this, traffic to the Correspondent
	Node does not flow through the Home Agent anymore.
	Ingress		o Increased Packet Size
	The C-side Router is on the way of the traffic from the		An extra IPv6 header is added per level of nesting to all the
	Correspondent Node to the Home Agent. Also, it is aware of the MR		packets. The header compression suggested in [8] cannot be
	and the mobile network behind the MR and establishes the		applied because both the source and destination (the intermediate
	appropriate tunnel and route. After this, it is able to reroute		MR and its HA), are different hop to hop.
	traffic to the mobile network over the tunnel to the MR.
	4.1 Route Optimization within a ISP network		2.3 MIPv6 Host in Mobile Networks
	This form of Route Optimization provides local savings for an ISP.		When a MIPv6 mobile node joins a mobile network, it becomes a
	This idea was described in Ohnishi's Mobile Border Gateway draft. The		visiting mobile node (VMN) of the mobile network. Packets sent to
	goal is to locate the closest (BGP) gateway for a Correspondent that		and from the visiting mobile node will have to be routed not only to
	is located outside of the domain, and tunnel between the MR and that		the home agent of the visiting mobile node, but also to the home
	gateway as opposed to the Home Agent for that specific Correspondent.		agent of the mobile router in the mobile network. This suffers the
			same amplification effect of nested mobile router mentioned in
			Section 2.2.
	4.2 Correspondent Router		In addition, although Mobile IPv6 [2] allows a mobile host to perform
			route optimization with its correspondent node to avoid tunneling
			with its home agent, the "optimized" route is no longer optimized
			when the mobile host is attached to a mobile network. This is
			because the route between the mobile host and its correspondent node
			is subjected to the sub-optimality introduced by the MR-HA tunnel.
			Interested readers may refer to [7] for examples of how the routes
			will appear with nesting of MIPv6 hosts in mobile networks.
	A globally better optimization is obtained if the tunnel from the MR		2.4 Communications within a Mobile Networks
	is terminated closer to the destination on the Correspondent side.
	This is the role of a Correspondent Router (CR).
	+-------------------+ # :== Tunnel		The reliance on the MR-HA tunnel has its implications on MNNs in a
	| Autonomous System | o :== Optimized		nested mobile network communicating with each other. Let us consider
	| ----------------- | n :== Non-Optimized		the previous example illustrated in Figure 1. Suppose LFN1 and LFN2
	| |		are communicating with each other. With NEMO Basic Support, a packet
	| |		sent from LFN1 to LFN2 will follow the path of: LFN1 -> MR3 -> MR2 ->
	| Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent		MR1 -> HAofMR1 -> HAofMR2 -> HAofMR3 -> HAofMR5 -> HAofMR1 -> MR1 ->
	| | # n #		MR5 -> LFN2. A round-about trip indeed where the direct path would
	| o | # n #		be LFN1 -> MR3 -> MR2 -> MR5 -> LFN2.
	| o | # n #
	| o | # n #
	| o | # n #
	| o | # n #
	| #################################### ?
	| CR oooooooooooooooooooooooooooooooooooooo Mobile
	| #################################### Router
	| | |
	+-------------------+ ===========Mobile Network========
	Correspondent Router		The consequences of increase packet delay and packet size have been
			discussed in previous sub-sections. Here, there is an additional
			effect that is undesirable: should MR1 loses its connection to the
			global Internet, LFN1 and LFN2 can no longer communicates with each
			other, even though the direct path from LFN1 to LFN2 is unaffected!
	The MR locates the CR for a given Correspondent and establishes a		3. Solution Space of NEMO Route Optimization
	Tunnel to the CR for that destination and its prefix(es). Then, the
	CR establishes the Tunnel back to the MR and the Mobile Routes to the
	MR's Mobile Networks via that Tunnel.
	A key point is that the CR must be on the interception path of the		To address the problems discussed in Section 2, one can incorporate
	traffic from the Correspondent to the Mobile Networks in order to		route optimization into NEMO. This is also known as the NEMO
	reroute the traffic over the appropriate Tunnel. This can be achieved		Extended Support. Although a standardized NEMO Extended Support has
	in several fashions:		yet materialize, one can expect it to show some of the following
			benefits:
	Redistribution		o Shorter Delay
	There's a limited Number of CRs that cover an Autonomous System.		Route optimization involves the selection and utilization of a
	They redistribute the Mobile Routes on the fly, or within rate and		shorter (or faster) route to be taken for traffic between a mobile
	amount limits. Garbage Collection is done at appropriate time to		network node and correspondent node. Hence a major benefit of
	limit the perturbation on the Routing.		route optimization should be shorter delay experiences by the data
			traffic between the two end nodes. This may possibly in turn
			leads to better overall Quality of Services characteristics, such
			as reduced jitter and packet loss.
	Default Router		o Reduced Consumption of Overall Network Resources
	The CR is a Default Router for the Correspondent, or for the whole		Through the selection of a shorter route, the total link
	AS of the Correspondent (it's a border gateway). In this case,		utilization for all links used by traffic between the two end
	redistribution is not needed.		nodes should be much lower than that used if route optimization is
			not carried out. This would result in a lighter network load with
			reduced congestion.
	Core Routers		o Less Susceptibility to Link Failure
	The Core Routers for the network of the Correspondent are all CRs.		An optimized route would conceivably utilize a lesser number of
	If the path from the correspondent to the Home Agent does not pass		links between the two end nodes. Hence, the probability of
	via a CR, then it's not worth optimizing. If it is, then the CRs		connectivity loss due to a single point of failure at a link
	are on the way. Again, redistribution is not needed.		should be lower as compared to the longer non-optimized route.
	4.3 Distributed Anchor Routers		o Greater Data Efficiency
	Taking the idea of a correspondent router a step further, it is		Depending on the actual solution for NEMO Extended Support, the
	possible to have a distributed set of anchor routers across the		data packets exchanged between the two end nodes may not require
	Internet. Outgoing packets sent from a mobile network will be		as many levels of encapsulation as required by NEMO Basic Support.
	tunneled to one of the nearest anchor router (instead of to the home		This would mean less packet overheads, and higher data efficiency.
	agent of the mobile router). This M-Side (Mobile Network Side)
	anchor router will decapsulate the packet, inspect the destination,
	and tunnel the packet to another anchor router situated near the CN
	(C-Side Anchor Router). From there, the packet will be decapsulated
	and forwarded to the CN.
	Correspondent nnnnnnnnnnnnnnnnnnnnnnn Home Agent		There are multiple proposals for providing various forms of route
	o # n #		optimizations for NEMO (see Appendix A). In the following
	o # n # # :== Tunnel		sub-sections, we describe the solution space of route optimization by
	o # n # o :== Optimized		listing different types of approach to route optimization. Readers
	o # n # n :== Non-Optimized		might be interested to take note of a route optimization model
	o # n #		described in [9] which describes route optimization model based on
	C-Side ################## M-Side ###### n #		the variations of tunnel end-points.
	Anchor oooooooooooooooooo Anchor oooo Mobile
	Router ################## Router #### Router
	|
	====Mobile Network=======
	Optimization in the Infrastructure		3.1 MR-to-CN Optimization
	The C-Side Anchor Router will be subjected to the same condition as		o Binding Update with Network Prefix
	listed in the previous sub-section if packets sent from the CN to the
	mobile network are to be route-optimized too. Otherwise, the
	solution will only partially optimize routing to a triangular routing
	(i.e. packet sent by CN will still go through the home agent of the
	mobile network).
	The anchor router share many similarities with the concept of		A straight-forward approach to route optimization is in NEMO is
	Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)		for the mobile router to attempt route optimization with
	[9]. In fact, it can be combined with HMIPv6 whereby each M-Side		correspondent node. This can be viewed as a logical extension to
	anchor router is also an MAP, and the MR obtains a regional		NEMO Basic Support, where the mobile router would send binding
	care-of-address from the MAP.		updates to the correspondent node containing one or more Mobile
			Network Prefix option. The correspondent node having received the
			binding update, can then set up a bi-directional tunnel with the
			mobile router at the current care-of address of the mobile router,
			and inject a route to its routing table so that packets destined
			for addresses in the mobile network prefix will be routed through
			the bi-directional tunnel.
	5. Nested Mobile Network		This approach is particularly useful when a lot of MNNs in a
			mobile network is communicating with a few corresponding nodes.
			In such cases, a single binding update can optimize the routes of
			many flows between the correspondent node and the MNNs.
	5.1 Nested Tunnels Optimization		o MR as a Proxy
	This section covers the case where one mobile network is within		A somewhat similar approach is for the mobile router to act as a
	another mobile network. For example, a user brings a Personal Area		"proxy" for the MNNs in its mobile network. In this case, The MR
	Network (PAN) consisting of some IP devices to a train which is also		uses standard MIPv6 route optimization procedure to bind the
	using NEMO technology. In another example, a car which conatins a		address of a MNN to its care-of address. This has the advantage
	mobile network moves into the ferry which has another mobile network.		of keeping the implementations of MNNs and correspondent nodes
	This configuration of mobile networks within another mobile network		unchanged, and can be done by having the mobile router to perform
	is called nested Mobile Networks.		the following steps:
	Let us illustrate the problem by an example. In this example, the		* determining when to perform RO (eg. by the flow packet count)
	nested Mobile Network has a tree topology. In the tree each node is a
	basic Mobile Network, represented by its MR.
	+---------------------+		* sending CoTI and HoTI on behalf of the MNN
	| Internet |---CN
	+---------------|-----+
	/ Access Router
	MR3_HA |
	======?======
	MR1
	|
	====?=============?==============?===
	MR5 MR2 MR6
	| | |
	=========== ===?========= =============
	MR3
	|
	==|=========?== Net3
	LFN1 MR4
	|
	=========
	An example nested Mobile Network		* receiving CoT (trivial, since it is addressed to the MR)
	This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3)		* intercepting the HoT (which requires inspection of the packets
	inside the tree, represented by its mobile router MR3. The path to		addressed to the MNN)
	the Top Level Mobile Router (TLMR) MR1 and then the Internet is:
	MR3 -> MR2 -> MR1 -> Internet		* sending the BU and receiving the BA on behalf of MNN
	Consider the case where a LFN belonging to Net3 sends a packet to a		* inserting the Home Address Option in packets sent by the MNN
	Correspondent Node (CN) in the Internet, and the CN replies back.
	With no Nested Tunnels Optimization, we would have three		* removing the type 2 routing header in packets sent to the MNN
	bi-directional nested tunnels, as described in [3] and illustrated in
	the following drawings:
	-----------.		* adjusting various ICMP packets to account for the modification
	--------/ /-----------.		it performs
	-------/ | | /-----------
	CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN
	MR3_HA -------\ | | \----------- MR3
	MR2_HA --------\ \----------- MR2
	MR1_HA ----------- MR1
	No Nested Tunnels Optimization		3.2 Infrastructure Optimization
	Such a solution introduces the following problems:		There are two known approaches to achieve infrastructure
			optimization. The first approach involves the introduction of an
			entity known as a correspondent-side router (C-side Router), or
			sometimes known simply as a correspondent router (CR) within the
			routing infrastructure. As long as the correspondent router is
			located "closer" to the correspondent node than the home agent of the
			mobile router, the route between MNN and the correspondent node can
			be said to have optimized. This is illustrated in Figure 4.
	"Pinball" routing		************************** HAofMR
			* #*#
			* #*# +---------------------+
			CN #*# | LEGEND |
			o #*# +---------------------+
			o ############### #*# | #: Tunnel |
			CR ooooooooooooooo MR | *: NEMO Basic route |
			############### | | o: Optimized route |
			MNN +---------------------+
	Both inbound and outbound packets will flow via the HAs of all the		Figure 4: Infrastructure Optimization
	MRs on their path within the NEMO, with increased latency, less
	resilience and more bandwidth usage. To illustrate this effect,
	the figure below shows the route taken by a packet sent from LFN
	to CN:
	+--> HAofMR1 ---------------------+		This form of optimization can take place independently for the 2
	| |		directions of the traffic:
	+----------------- HAofMR2 <--+ |
	| |
	+---------------+ |
	| V
	HAofMR3 <------+ CN
	|
	|
	LFN --> MR1 --> MR2 --> MR3
	'Pinball' Routing		o From MNN to CN
	Packet size		The mobile router locates the correspondent router, establishes a
			tunnel with that correspondent router and sets a route to the
			correspondent node via the correspondent router over the tunnel.
			After this, traffic to the correspondent node does not flow
			through the home agent anymore.
	An extra IPv6 header is added per level of nesting to all the		o From CN to MNN
	packets. The header compression suggested in [4] cannot be applied
	because both the source and destination (the intermediate MR and
	its HA), are different hop to hop.
	On the other hand, with a Nested Tunnel Optimization, we would have		The correspondent router is on the path of the traffic from the
	at most one bi-directional tunnel outside the Mobile Network, that		correspondent node to the home agent. In addition, it has an
	may depend on the traffic flow:		established tunnel with the current care-of address of the mobile
			router and is aware of the mobile network prefix(es) managed by
			the mobile router. The correspondent router can thus intercept
			packets going to the mobile network, and forward them to the
			mobile router over the established tunnel.
	__- --_		The advantage of this approach is that no additional functionality is
	Tunnel---------------------------- MR1 ( Mobile ) MR3		required for the correspondent node and mobile network nodes.
	CN ----------( - - - - - - - - - - ( - - - - )--------- LFN
	Endpoint---------------------------- MR1 ( Network ) MR3
	--___---
	Nested Tunnels Optimization		The second approach is to have optimizations carried out fully in
			infrastructure. One example is to make use of mobile anchor points
			(MAP) in HMIPv6 [10] to optimize routes between themselves. Another
			example is to make use of the global HAHA protocol [11]. In this
			case, proxy home agents are distributed in the infrastructure and
			mobile routers bind to the closest proxy. The proxy performs, in
			turn, a primary binding with a real home agent for that mobile
			router. Then, the proxy might establish secondary bindings with
			other home agents or proxies in the infrastructure, in order to
			improve the end-to-end path. In this case, the proxies discover each
			other, establish a tunnel and exchange the relevant mobile network
			prefix information in the form of explicit prefix routes. There is
			no need for return routability test or its like since the security is
			built in the infrastructure, one way or an other, and the proxies
			belong to the infrastructure.
	The end-point of such a Tunnel on the Mobile side may either be MR1		3.3 Nested Tunnels Optimization
	or MR3, depending on the solution. In the case of a Mobile Node
	visiting Net3, that Mobile Node may also be the end-point.
	The potential approaches for avoiding the nesting of tunnels include:		Nested tunnels optimization is targeted at nested mobile networks,
			where there will be multiple levels of MR-HA tunnels with NEMO Basic
			Support. Such a solution will seek to minimize the number of
			tunnels, possibly by collapsing the amount of tunnels required
			through dome form of signaling between the mobile routers and home
			agents. This ameliorate the amplification effect of tunnel nesting,
			and at best, the performance of a nested mobile network will be the
			same as though there were no nesting of mobile networks.
	Mobile Aggregation		There have been various proposals on nested tunnels optimization, and
			we can model them according to:
	This model applies to a category of problems were the Mobile		o Sending Information of Upstream Mobile Routers
	Networks share a same administration and consistently move
	together (e.g. a fleet at sea). In this model, there is a cascade
	of Home Agents.
	The main Home Agent is fixed in the infrastructure, and advertises		This involves sending information on upstream mobile router(s) to
	an aggregated view of all the Mobile Networks. This aggregation is		the home agent of a nested mobile router, thereby enabling the
	actually divided over a number of Mobile Routers, the TLMRs. The		home agent to forward tunneled packets directly to the nested
	TLMRs subdivide some of their address space to the other Mobile		mobile router via the upstream mobile router(s), skipping the home
	Routers forming their fleet, for which they are Home Agent.		agents of upstream mobile router(s). This usually involves the
			use of a routing header to route packets through the upstream
			mobile router(s).
	As Home Agents, the TLMRs terminate MIP Tunnels from the inside of		The information of upstream mobile router (for simplicity, we
	the Mobile Network. As Mobile Router, they also terminate their		refer to it as "upstream information") may contain information on
	home Tunnels. As routers, they forward packets between the 2		the entire chain of upstream mobile routers, or it may only
	tunnels.		contain information on the immediate parent mobile router. For
			the former, the home agent can build a multihop routing header
			from a single transmission of the information. For the latter,
			each upstream mobile router may have to send binding update to the
			home agent of the nested mobile router, thereby enabling the home
			agent of the nested mobile router to build a multihop routing
			header recursively.
	Surrogate		o Prefix Delegation
	The TLMR acts as a proxy in the MIP registration, in a fashion of		An alternative approach to nested tunnels optimization is to use
	MIPv4 Foreign Agent or HMIP MAP (see [9]). For instance, the TLMR		prefix delegation. Here, each mobile router in a nested mobile
	maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and		network is delegated a mobile network prefix from the access
	switches packets between the two.		router using DHCP Prefix Delegation [12]. Each mobile router also
			autoconfigures its care-of address from this delegated prefix. In
			this way, the care-of addresses of each mobile router are all from
			an aggregatable address space starting from the access router.
			This may be used to eliminate any nesting of tunnels. It may also
			be used to achieve MIPv6-over-NEMO optimization (see Section 3.4)
			if MIPv6 hosts autoconfigure their care-of addresses from the
			prefix as well.
	Internal Routing and gateway		o Mobile Aggregation
	This item can be approached from a MANET standpoint. This was		This model applies to a category of problems where the mobile
	already done for DSR (see [10]) and AODV (see [11] and [8]) From a		networks share a same administration and consistently move
	Nemo standpoint, a full MANET is not necessary since the goal is		together (e.g. a fleet at sea). In this model, there is a
	to find a way to the infrastructure, as opposed to any-to-any		cascade of home agents. The main home agent is fixed in the
	connectivity.		infrastructure, and advertises an aggregated view of all the
			mobile networks. This aggregation is actually divided over a
			number of mobile routers, the root-MRs. The root-MRs subdivide
			some of their address space to the other mobile routers forming
			their fleet, for which they are home agent. As home agents, the
			root-MRs terminate tunnels from the inside of the mobile network.
			As mobile router, they also terminate their home tunnels. As
			routers, they forward packets between the 2 tunnels.
	RRH		3.4 MIPv6-over-NEMO Optimization
	The Reverse Routing Header (RRH) approach avoids the multiple		MIPv6-over-NEMO optimization involves providing optimization for a
	encapsulation of the traffic but maintains the home tunnel of the		visiting mobile node within a mobile network. There are two aspects
	first MR on the egress path. It is described in details in [5].		to MIPv6-over-NEMO optimization:
	The first MR on the way out (egress direction) encapsulates the
	packet over its reverse tunnel, using a form of Record Route
	header, the RRH.
	The next MRs simply swap their CoA and the source of the packet,		o Nested Tunnels
	saving the original source in the RRH. The HA transforms the RRH
	in a Routing Header to perform a Source Routing across the nested
	Mobile Network, along the ingress path to the target MR.
	Access Router Option		This aims to reduce the amplification effect of nested tunnels due
			to the nesting of the tunnel between the visiting mobile node and
			its home agent within the tunnel between the mobile router of the
			mobile network and the home agent of the mobile router.
	The Access Router Option (ARO) approach [6] is somewhat similar to		This is very similar to "Nested Tunnels Optimization" described in
	the RRH in that only the home tunnel of the first MR in the egress		Section 3.3. Thus, a possible approach is to extend the solution
	path is maintained. This is done by having MR to send an ARO in		for nested tunnels optimization to visiting mobile node as well.
	Binding Update to inform its HA the address of its access router.
	Using this information, HA can build a Routing Header to
	source-route a packet to the target MR within in a nested mobile
	network. Details can be found in [6].
	Prefix delegation approach		o MIPv6 Route Optimization
	The prefix delegation approach [7] is somewhat to HMIPv6 what Nemo		This aims to remove the sub-optimality of a MR-HA tunnel from the
	is to MIPv6. The Access Router of the nested structure is both a		MIPv6 route optimization established between a visiting mobile
	Nemo Home Agent and a DHCP-PD server, for an aggregation that it		node and correspondent node. One approach is to simply extend the
	owns and advertises to the Infrastructure. When visiting the		solution for nested tunnels optimization to correspondent node.
	nested structure, each MR is delegated a mobile network prefix		Another (arguably "evil") approach is for the mobile router to
	from the AR using DHCP-Prefix Delegation. The MR registers this		"play some trick" to the MIPv6 route optimization, such as
	delegated MNP to the AR that is acting as a Nemo Home Agent. The		altering messages exchanged during the return routability
	MR also autoconfigures an address from the delegated MNP and uses		procedure between the visiting mobile node and correspondent node,
	it as a CareOf to register its own MNPs to its own Home Agent		so that packets sent from correspondent node to the visiting
	using Nemo basic support. It is possible for a MR to protect its		mobile node will be routed to the care-of address of the mobile
	own MNPs while advertising in the clear the local MNP for other		router once route optimization is established (see Section 3.1:
	MRs to roam in. This allows a strict privacy of visited and		"MR as a Proxy"). Alternatively, the mobile router can perform
	visitors, and enables some specific policies in each Mobile		return routability procedure on behalf of the visiting mobile
	Router. Details can be found in [7].		node. This would most likely require some signaling protocol
			between the visiting mobile node and the mobile router, but may be
			able to keep the functionality of the correspondent node
			unchanged.
	5.2 Route Optimization inside the Nested Mobile Network		3.5 Intra-NEMO Optimization
	Although optimization within a mobile network is not within the		A route optimization solution may seek to improve the communications
	charter of the NEMO working group, it might be insightful to discuss		between two mobile network nodes within a nested mobile network. An
	such optimizations.		example will be the optimization of packets route taken between LFN1
			and LFN2 of Figure 1.
	The expectation is that the mobile routes installed by NEMO can		One may be able to extend a well-designed solution for MR-to-CN
	cohabit with a MANET support that would perform the RO inside the		optimization to provide Intra-NEMO optimization, where, for example
	Nested Mobile Network. In other words, MIP redistributes its prefixes		in Figure 1, LFN1 is treated as a correspondent node in the view of
	locally to a MANET and the MR-HA tunnel is bypassed.		MR5, and LFN2 is treated as a correspondent node in the view of MR3.
	6. General Considerations		Another possibility is for the infrastructure optimization technique
			to be applied here. Using the same example of communication between
			LFN1 and LFN2, MR3 may treat MR5 as a correspondent router for LFN2,
			and MR5 treats MR3 as a correspondent router for LFN1.
	6.1 Securing the protocol in nested tunnels optimization		4. Analysis of Solution Space
	These approaches are generally difficult to secure unless all the		In this section, we present an analysis of the solution space.
	Mobile Routers and Visiting Mobile Node belong to a same		First, we discuss the general issues that will be faced by a NEMO
	administrative domain and share predefined Security Associations.		Extended Support solution in Section 4.1. Then, we explore deeper
			into specific types of route optimization solutions in Section 4.2.
	Even if an intermediate MR is 'trusted', this does not prove it is		4.1 General Considerations of RO Solution
	able to provide the necessary bandwidth, and may not provide a good
	service. Eventually, a MR that is capable of securing (IPSec) its
	traffic may select a Mobile Access Router based on quality of service
	heuristics as opposed as trust.
	The problem is global to the whole Mobile Network in the case of a		Although route optimization, or NEMO Extended Support, can bring
	MANET-based solution. For an RRH-based solution, the threat comes		benefits as described in previous section, it does so with some
	from on-axis MRs in the nested Mobile Network but is mostly limited		tradeoffs. The actual type and degree of tradeoffs depend greatly on
	to denial of service. This is detailed in [5]. The approach taken is		the solution; however, in general, one would expect the costs
	to limit the threat to Black Hole and Grey Hole by using IPSec.		described in the following sub-sections to be incurred.
	6.2 Recursive complexity in route optimization		4.1.1 Additional Signaling Overhead
	A number of drafts and publications suggest -or can be extended to- a		The nodes involved in performing route optimization would be expected
	model where the Home Agent and any arbitrary Correspondent would		to exchange additional signaling information in order to establish
	actually get individual binding from the chain of nested Mobile		route optimization. The cost of such signaling may be high,
	Routers, and form a routing header appropriately.		depending on the actual solution. Such a cost may scale to
			unacceptable height when the number of mobile network nodes and/or
			correspondent nodes is increased.
	An intermediate MR would keep track of all the pending communications		This signaling overhead is often in the form of binding update sent
	between hosts in its subtree of Mobile Networks and their CNs, and a		to home agents or correspondent nodes. One issue that may impact
	binding message to each CN each time it changes its point of		route optimization solution is known as the phenomenon of "Binding
	attachment.		Update Storm". This occurs when a change in point of attachment of
			the mobile networks is accompanied with a sudden burst of binding
			update messages being generated, resulting in temporary congestion,
			packet delays or even packet lost.
	If this was done, then each CN, by receiving all the binding messages		There has been argument that binding update storm may not be as
	and processing them recursively, could infer a partial topology of		significant as it seems. For instance, consider a mobile network
	the nested Mobile Network, sufficient to build a multi-hop routing		where mobile network nodes is receiving x video stream at 25 packets
	header for packets sent to nodes inside the nested Mobile Network.		per seconds. On the average, the mobile network is handling a total
			traffic of 25*x packets per second. Assuming one binding update has
			to be sent for each video stream server, a change in point of
			attachment would result in at most 6*x signaling messages (if we
			include the return routability procedure messages and a binding
			acknowledgment). Thus the signaling overhead is small compared to
			the normal data traffic that the mobile network is handling, and
			hence the effect of binding update storm is small. On the other
			hand, if the normal data rate is small, the effect of binding update
			storm may have a greater impact. From this discussion, it appears
			that the significance of binding update storm may depend on the
			application type (eg. high or low data rate, tolerance on packets
			delay, etc).
	However, this extension has a cost:		It is also possible to further moderate the effect of Binding Update
			Storm by having some sort of "exponential back-off" mechanism in
			place for the sending of binding updates. Such a scheme aims to
			spread the burst of binding update transmissions over a longer period
			of time, thereby reducing possibility of congestion and packet drops.
	1. Binding Update storm		4.1.2 Increased Protocol Complexity
	when one MR changes its point of attachment, it needs to send a		Some nodes will be required to have additional functionalities in
	BU to all the CNs of each node behind him. When the Mobile		order to incorporate NEMO Extended Support. This increases the node
	Network is nested, the number of nodes and relative CNs can be		complexity. It may not be feasible to implement new functionalities
	huge, leading to congestions and drops.		on legacy nodes. If such nodes are mobile, this may prove to be a
			significant cost due to the limited memory resources such devices
			usually have.
	2. Protocol Hacks		Coupled with the increased in protocol complexity, nodes that are
			involved in the establishment and maintenance of route optimization
			will have to bear increased processing load. If such nodes are
			mobile, this may prove to be a significant cost due to the limited
			power and processing resources such devices usually have.
	Also, in order to send the BUs, the MR has to keep track of all		4.1.3 Mobility Awareness
	the traffic it forwards to maintain his list of CNs. In case of
	IPSec tunneled traffic, that CN information may not be available.
	3. CN operation		One advantage of NEMO Basic Support is that the correspondent nodes
			and mobile network nodes need not be aware of the actual location and
			mobility of the mobile network. With route optimization, it might be
			necessary to reveal the current care-of address and any change of
			point of attachment of the mobile router to other nodes, such as the
			mobile network nodes or correspondent node. This may mean a tradeoff
			between location privacy and route optimization. In MIPv6, the
			mobile node can decide whether or not to perform route optimization
			with a given correspondent node. Thus, the mobile node is in control
			of whether to trade location privacy for an optimized route. It will
			be desirable that such control is also available in a route optimized
			solution of NEMO should the solution contain the same tradeoff.
			However, for solutions where route optimization decision is made by
			mobile router, it will be difficult for mobile network nodes to
			control the decision of having this tradeoff.
	The computation burden of the CN becomes heavy, because it has to		4.1.4 New Functionalities
	analyze each BU in a recursive fashion in order to infer nested
	Mobile Network topology required to build a multi hop routing
	header.
	4. Missing BU		All route optimization approaches require some sort of new
			functionalities be implemented on some nodes. In general, it is
			desirable to keep the number of nodes that require new
			functionalities to be kept as small as possible. This allows for
			easier adoption of the solution, and also creates less impact on the
			existing infrastructure.
	If a CN doesn't receive the full set of PSBU sent by the MR, it		In addition, if route optimization solution requires new
	will not be able to infer the full path to a node inside the		functionalities on the part of some other nodes other than nodes
	nested Mobile Network. The RH will be incomplete and the packet		within the mobile network, a mechanism for other nodes (such as
	may or may not be delivered.		mobile router) to detect if support for the new functionalities are
			available should also be provided. Furthermore, it is desirable for
			there to be a graceful fall back procedure the required
			functionalities are unavailable.
	5. Obsolete BU		Possible nodes that are required to be changed includes:
	If the Binding messages are sent asynchronously by each MR, then,		o Local Fixed Nodes
	when the relative position of MRs and/or the TLMR point of
	attachment change rapidly, the image of Mobile Network that the
	CN maintains is highly unstable. If only one BU in the chain is
	obsolete due to the movement of an intermediate MR, the
	connectivity may be lost.
	6.3 Mobile Access router selection		It is generally undesirable to affect local fixed nodes. However,
			some approaches require mobile network nodes to implement new
			functionalities to enjoy benefits of route optimizations.
	In some case, nested Mobile Networks attaches to visiting network		o Visiting Mobile Nodes
	with multiples mobile access router that are gateways to the global
	internet. These RO methods may cover the function in which how the MR
	in the nested Mobile Network choose the one of the mobile access
	routers. This function is not explicitly described in current
	methods and needs to be discussed.
	6.4 Mobility transparency and RO		Visiting mobile nodes in general should already have implemented
			MIPv6 functionalities, and since MIPv6 is a relatively new
			standard, there is still a considerable window to allow mobile
			devices to implement new functionalities.
	[cwng's interpretation of Mobility Transparency in RO]		o Mobile Routers
	It is desirable in mobility-related protocols that the mobility of a		It is expected for mobile routers to implement new functionalities
	mobile node is transparent to other entities and other layers in the		in order to enable route optimizations.
	mobile node. The Basic NEMO support achieve this mobility
	transparency of the mobile network to the MNNs by a MR-HA tunnel so
	that MNNs need not be aware of the MR's change in point of
	attachment.
	Such a feature is, as mentioned, desirable. However, when route		o Access Routers
	optimizations, end-to-end principle, and other factors come into
	consideration, achieving mobility transparency may not be practical.
	For instance, to achieve nested tunnel optimizations, the mobility of		Some approaches require access routers, or nodes in the access
	the top-level MR is often exposed to other entities, such as the HA		network to implement some new functionalities. A clear example
	of a nested MR. In the case of MR performing BU for MNNs, it might		will be prefix delegation approach.
	be necessary to pass mobility information of the MR to CN (and even
	MNN) in order not to break the end-to-end principle. For the
	scenario of optimization using infrastructure, the mobility
	information might be necessarily exposed to correspondent routers or
	MAP.
	Thus, one should bear in mind when designing RO solution that a		o Home Agents
	sacrifice might be necessary when weighing conflicting factors such
	as mobility transparency, optimization level, and end-to-end
	integrity.
	[Hosik's interpretation of Mobility Transparency in RO]		Although it is likely that vendors and operators would not mind
			having new functionalities in home agents, few route optimizations
			approaches would impact the home agents.
	In the case of extended support of NEMO such as nested NEMO, mobility		o Correspondent Nodes
	transparency is desirable but that is not mandatory for the
	efficiency of the route optimization. For example, the notebook and
	PDA inside a vehicle can access to the Internet through the mobile
	router of the vehicle. In that case, if the movement of the vehicle
	affects to the notebook or the PDA, they can perform individual
	binding update operation to the correspondent node or its home agent
	but that can cause location privacy problem.
	[Onishi's interpretation of Mobility Transparency in RO]		It is generally undesirable for correspondent nodes to be required
			to implement new functionalities.
	In RO solutions, MR can optimize the route between its own HA and MR.		o Correspondent Routers
	It is desirable that communication can not be interrupted by this
	route optimization. ????
	6.5 Multihoming Considerations		Correspondent routers are new entity to be deployed in the
			infrastructure. Such addition would generally cause the least
			disruption to the existing routing infrastructure.
	In multihomed mobile networks, route optimization is dependant on how		4.1.5 Other Considerations
	the connections to the Internet are available and selected.
	In case of macro mobility, we may have multiple HAs from place to		There are other considerations when analyzing the route optimization
	place. New route optimization could be possible by routing between CN		solution space. These may not be a 'tradeoff" so to speak, but are
	and one of the multiple Home Agents (possibly using differenc Home		beneficial to keep in mind when considering a route optimization
	Addresses).		solutions.
	When multiple connections are available for the purpose of fault		o Compatibility with NEMO Basic Support
	tolerance, a selection mechanism is needed for CN to eveluate the
	connection availability in order to perform route optimization.
	7. Conclusion		It will be beneficial to vendors if a route optimized solution for
			NEMO is compatible with NEMO Basic Support. This reduces the
			complexity and achieves greater reuse of existing functionalities.
	The Problem space of Route Optimization in the NEMO context is		o In-Plane Signaling versus Off-Plane Signaling
	multifold and can be split is several work areas. It will be
			There is also considerations of whether route optimization
			signaling should be done in-plane and off-plane. In-plane
			signaling involves embedding signaling information into headers of
			data packets (a good example would be the Reverse Routing Header
			[13]). Off-plane signaling involves separating the signaling
			packets from the data packets. Most proposals involving sending
			of binding updates fall within this category.
			4.2 Specific Types of RO Solution
			Many of the tradeoffs discussed previously in Section 4.2 are
			dependent on the actual route optimization approach. In the
			following sub-sections, we will explore deeper into the issues
			involved in each specific type of route optimization approach.
			4.2.1 MR-to-CN Optimization
			One approach of MR-to-CN optimization involves the mobile router
			sending binding update messages with mobile network prefix
			information to the correspondent node. This raised several issues:
			o Security Considerations
			With mobile router sending binding update containing network
			prefix information to correspondent node, there is a question on
			the additional risk imposed on the correspondent node. Although
			return routability procedure allows the correspondent node to
			verify that the care-of and home addresses of the mobile router
			are indeed collocated, it does not allow the correspondent node to
			verify the validity of the network prefix. If the correspondent
			node accepts the binding without verification, it will be exposed
			to a class of attacks where the attacker tricks the correspondent
			node into forwarding packets destined for a mobile network to the
			attacker.
			Hence, MR-to-CN optimization would most likely require an extended
			return routability procedure to be developed for correspondent
			node to authenticate the validity of the mobile network prefix.
			This require additional functionality on the correspondent node,
			and a mechanism must be provided for the mobile router to check if
			the correspondent node has such functionality implemented.
			o Mobility Awareness
			By sending binding update with mobile network prefix to the
			correspondent node, the mobile router is effectively revealing the
			location and mobility of the mobile network to the correspondent
			node. Hence this is a case of trading location privacy for route
			optimization. However, since route optimization in this case is
			initiated by the mobile router, the mobile network nodes may not
			have an influence to the decision of whether the tradeoff should
			be made.
			o Binding Update Storm
			If the mobile network nodes in a mobile network are communicating
			with a lot of correspondent nodes, whenever the mobile router
			changes its point of attachment, it needs to send out a large
			number of binding updates to correspondent nodes. This is further
			worsen by the fact that the mobile router has to perform the
			return routability procedure prior to sending binding updates.
			Another approach involves the mobile router acting as a proxy for
			MNNs behind it. This has the following issues:
			o Security Considerations
			Having the mobile router alters packets (such as inserting home
			address destination option and removing type 2 routing header)
			raise considerable security concerns. Such a scheme may break
			existing IPSec protocols, and cause packets to be dropped.
			o Complexity
			This also greatly increases the complexity of a mobile router, as
			it needs to look beyond the standard IPv6 headers for
			ingress/egress packets, and performs hacks appropriately. The
			mobile router is also required to maintain some form of state
			information for each pair of MNN and CN, resulting in scaling
			issues. This scheme also places all processing burden on the
			mobile router, which may be undesirable for mobile device with
			limited power and processing resources.
			o Binding Update Storm
			Whenever the mobile router changes its point of attachment, it
			needs to perform binding updates with every correspondent node.
			Some CN selection scheme may be required to moderate the effect of
			binding update storm and processing burden on the mobile router.
			o A Hack of Existing Protocol
			There have been comments on the NEMO WG mailing list that such an
			approach is essentially a hack of the existing return routability
			procedure. The disadvantages of it being a hack is that firstly a
			change/extension in the current return routability procedure would
			render this hack broken, and secondly, it might be very difficult
			to accommodate other protocols that are not aware of such hacks
			(IPSec being an excellent example).
			o Nesting of Mobile Routers
			Should one mobile router be attached to another mobile router, it
			is unclear how this solution will work if both mobile routers try
			to perform route optimization on behalf of the same mobile network
			node. Using Figure 1 as an example, if MR5 perform route
			optimization on behalf of LFN2, and then MR1 again tries to act as
			a proxy to MR5, the results might be messy without any
			co-ordination between these mobile routers.
			4.2.2 Infrastructure Optimization
			An infrastructure optimization approach using correspondent routers
			may face the following issues:
			o Security Considerations
			The first security-related issue is how do the mobile router
			verify the validity of a correspondent router. In other words,
			the mobile router needs some mechanism to ascertain that the
			correspondent router is indeed a valid correspondent router
			capable of forwarding packets to and from the correspondent node.
			A second security-related issue is how can the correspondent
			router verify the validity of a mobile router. In other words,
			the correspondent router needs some mechanism to ascertain that
			the mobile router is indeed managing the mobile network prefix it
			claims to be managing. This is related to the issues discussed in
			Section 4.2.1.
			o Mobility Awareness
			Infrastructure optimization requires the correspondent router to
			be informed of the location and mobility of the mobile network.
			Correspondent nodes and mobile network nodes remain ignorant of
			the mobile network's mobility.
			o Discovery of Correspondent Routers
			How should a mobile router discover a correspondent router given a
			particular correspondent node? The discovery mechanism may have
			impact on the security issue discussed earlier.
			4.2.3 Nested Tunnels Optimization
			Nested tunnels optimization usually involves the nested mobile router
			sending information of upstream mobile router(s).
			o Security Considerations
			One issue for consideration is whether the home agent should trust
			the upstream information supplied by the nested mobile router. If
			the upstream information falsely points to a victim node, the home
			agent may unconsciously flood the victim with packets intended for
			the nested mobile network.
			This risk can be minimized if the upstream information is
			protected by security association between the nested mobile router
			and its home agent (e.g. the upstream information may be
			transmitted in a binding update that is protected from tampering).
			However, this does not protect against a malicious mobile router
			intentionally supplying false upstream information to its home
			agent, with the intent of launching a flooding attack against a
			victim node.
			o Mobility Awareness
			Usually, nested tunnels optimization involves the nested mobile
			router sending upstream information to its home agent. This
			implies that the upstream mobile router will have to reveal some
			information to sub-mobile routers. Such information may reveal
			the location and mobility of the upstream mobile router.
			o Binding Update Storm
			Depending on the specifics of a solution for nested tunnels
			optimization, the upstream information may be the care-of address
			of the upstream mobile router. This will leads to the a burst of
			binding update messages whenever an upstream mobile router changes
			its point of attachment, since all its sub-MRs must send binding
			updates to their home agents to update the new upstream
			information.
			o Complexity
			Sending of upstream information for nested tunnels optimization
			requires the home agent to store the upstream information in order
			to build a routing header. Complexity of the home agent is
			further increased if the upstream information is sent individually
			by all upstream mobile routers, requiring the home agent to
			recursively build a routing header.
			Alternatively, a prefix delegation approach may be used to achieve
			nested tunnel optimization by eliminating the need for nesting. This
			approach may face the following issues:
			o Protocol Complexity
			This approach requires the access router (or some other entity
			within the access network) to possess prefix delegation
			functionality, and also maintains information on what prefix is
			delegated to which node.
			o Binding Update Storm
			A change in the point of attachment of the root mobile router will
			require every nested mobile router (and possibly visiting mobile
			nodes) to change their care-of addresses and delegated prefixes.
			These will cause a burst of binding update and prefix delegation
			activities where every mobile routers and visiting mobile nodes
			start sending binding updates to their home agents and possibly
			correspondent nodes.
			4.2.4 MIPv6-over-NEMO Optimization
			If MIPv6 route optimization is not used, the optimization for
			MIPv6-over-NEMO is very similar to nested tunnels optimization, where
			the MIPv6 mobile node acts like a visiting mobile router. The
			analysis of such optimization is thus similar to those discussed in
			Section 4.2.3, and hence will not be repeated here. In this section,
			we explore the issues if MIPv6 route optimization is used.
			As described in Section 3.4, MIPv6-over-NEMO optimization can be
			achieved using various approaches. One approach involves including
			upstream information (see nested tunnels optimization) in the binding
			update sent from the visiting mobile node to the correspondent node.
			This approach has the following considerations:
			o Security Considerations
			A security-related issue is how can the correspondent node verify
			the validity of the supplied upstream information. See also
			Section 4.2.3.
			o Mobility Awareness
			The visiting mobile node will need to acquire the upstream
			information, most likely including the mobility and location
			information of the upstream mobile routers.
			On the other hand, the mobile router can perform some hacks on the
			return routability messages exchanged between the visiting mobile
			node and correspondent node to achieve MIPv6-over-NEMO optimization.
			This, is generally undesirable due to:
			o Security Considerations
			Such a scheme may break existing security related protocols, as it
			requires the mobile router to make changes to contents of a packet
			that is not originated by the mobile router.
			Alternatively, the mobile router can perform return routability
			procedure on behalf of the visiting mobile node. Here the issues
			are:
			o Security Considerations
			Such a scheme require the visiting mobile node to place
			considerable trust on the mobile router, as the mobility
			management key is now transfered to the mobile router.
			o Mobility Awareness
			This approach aims to keep the functionality of the correspondent
			node to be identical as those required by MIPv6 route
			optimization. The expense will be that a new form of signaling
			between the visiting mobile node and mobile router would most
			likely be required.
			o Processing Burden
			This approach also increases the processing burden of the mobile
			router, as it needs to maintain information necessary for route
			optimization to work for every correspondent node that is
			communicating with each visiting mobile node. This may not scale
			very well when one consider, for example, a train network, where
			there are hundreds of visiting mobile nodes in one mobile network.
			4.2.5 Intra-NEMO Optimization
			As mentioned in Section 3.5, it is likely that any MR-to-CN
			optimization may be able to fulfill the role of an intra-NEMO
			optimization. Such solutions will face the same issues as described
			in Section 4.2.1, as well as the following:
			o Reliance on Outside Infrastructure
			Most MR-to-CN optimization rely on the operations of home agent in
			one way or another. For instance, the return routability
			procedure requires a Home Test (HoT) or Home Test Init (HoTI)
			messages be forwarded by the home agent. This means that should
			the path to the Internet be broken, such optimization techniques
			can no longer be used (and thus LFN1 can no longer communicates
			with LFN2 in the example of Figure 1).
			5. Conclusion
			The problem space of route optimization in the NEMO context is
			multifold and can be split into several work areas. It will be
	critical, though, that the solution to a given piece of the puzzle be		critical, though, that the solution to a given piece of the puzzle be
	compatible and integrate smoothly with the others.		compatible and integrate smoothly with the others.
	Hopefully, the solutions will build on MIPv6 ([1]), as recommended by		This memo explored into various problems of sub-optimality of NEMO
	the NEMO Charter. On the other hand, MIPv6 seems to be evolving in a		Basic Support, and discussed different aspects of a route optimized
	direction that makes it more and more difficult to provide a NEMO		solution in NEMO. The intent of this document is to trigger fruitful
	solution with backward compatibility, since:		discussions that in turn will enhance our common understanding of the
			route optimization problem and solution space.
	1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,		6. Acknowledgments
	2) The RR test has no negotiable option and is not open for		The authors wish to thank: Greg Daley, Thierry Ernst, Erik Nordmark,
	extension, and		T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji Wakikawa
			and Patrick Wetterwald for their various contributions. In addition,
			the authors would also like to extend their heart-felt gratitude to
			Marco Molteni, who was a co-author for the earlier versions of this
			document.
	3) The HaO and RH type 2 are designed for a collocated CareOf		7 References
	Address. More specifically, they are not designed to be multi-hop as
	RRH is, and not extensible, though RRH can be considered as an
	extension of HAO.
	The authors intent is to trigger fruitful discussions that in turn		[1] Devarapalli, V., "Network Mobility (NEMO) Basic Support
	will enhance our common understanding of the problem space so that at		Protocol", draft-ietf-nemo-basic-support-03 (work in progress),
	some point, this paper turns into a problem statement for the Nemo		June 2004.
	Route Optimization.
	8. Acknowledgements		[2] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
			IPv6", RFC 3775, June 2004.
	The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki		[3] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
	Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji		3753, June 2004.
	Wakikawa and Patrick Wetterwald for their various contributions.
	References		[4] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
			draft-ietf-nemo-terminology-01 (work in progress), February
			2004.
	[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[5] Ernst, T., "Network Mobility Support Goals and Requirements",
	IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July		draft-ietf-nemo-requirements-02 (work in progress), February
	2003.		2004.
	[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[6] Zhao, F., Wu, F. and S. Jung, "NEMO Route Optimization Problem
	draft-ietf-nemo-terminology-00 (work in progress), May 2003.		Statement, Requirements and Evaluation Considerations",
			draft-zhao-nemo-ro-ps-00 (work in progress), October 2004.
	[3] kniveton, t., "Mobile Router Support with Mobile IP",		[7] Watari, M. and T. Ernst, "Route Optimization with Nested
	draft-kniveton-mobrtr-02 (work in progress), July 2002.		Correspondent Nodes", draft-watari-nemo-nested-cn-00 (work in
			progress), October 2004.
	[4] Deering, S. and B. Zill, "Redundant Address Deletion when		[8] Deering, S. and B. Zill, "Redundant Address Deletion when
	Encapsulating IPv6 in IPv6",		Encapsulating IPv6 in IPv6",
	draft-deering-ipv6-encap-addr-deletion-00 (work in progress),		draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
	November 2001.		November 2001.
	[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and		[9] Na, J., "Generic Route Optimization Model for NEMO Extended
			Support", draft-na-nemo-gen-ro-model-00 (work in progress),
			July 2004.
			[10] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
			"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
			draft-ietf-mipshop-hmipv6-02 (work in progress), June 2004.
			[11] Thubert, P., "Global HA to HA protocol",
			draft-thubert-nemo-global-haha-00 (work in progress), October
			2004.
			[12] Droms, R. and O. Troan, "IPv6 Prefix Options for DHCPv6",
			draft-troan-dhcpv6-opt-prefix-delegation-01 (work in progress),
			May 2002.
			[13] 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-04 (work in		draft-thubert-nemo-reverse-routing-header-05 (work in
	progress), February 2004.		progress), June 2004.
	[6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization		[14] Ng, C. and J. Hirano, "Extending Return Routability Procedure
	with Access Router Option",		for Network Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in
	draft-ng-nemo-access-router-option-00 (work in progress),		progress), October 2004.
	November 2002.
	[7] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",		[15] Bernardos, C., Bagnulo, M. and M. Calderon, "MIRON: MIPv6 Route
	draft-droms-nemo-dhcpv6-pd-01 (work in progress), February		Optimization for NEMO", ASWN 2004, Online:
			http://www.it.uc3m.es/cjbc/papers/miron_aswn2004.pdf.
			[16] Ng, C. and T. Tanaka, "Securing Nested Tunnels Optimization
			with Access Router Option",
			draft-ng-nemo-access-router-option-01 (work in progress), July
	2004.		2004.
	[8] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc		[17] Na, J., "Route Optimization Scheme based on Path Control
	Networks", draft-wakikawa-manet-globalv6-03 (work in progress),		Header", draft-na-nemo-path-control-header-00 (work in
	October 2003.		progress), April 2004.
	[9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,		[18] Wakikawa, R., "Optimized Route Cache Protocol (ORC)",
	"Hierarchical MIPv6 mobility management (HMIPv6)",		draft-wakikawa-nemo-orc-00 (work in progress), July 2004.
	draft-ietf-mobileip-hmipv6-06 (work in progress), July 2002.
	[10] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad		[19] Na, J., "Secure Nested Tunnels Optimization using Nested Path
	Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in		Information", draft-na-nemo-nested-path-info-00 (work in
	progress), April 2003.		progress), September 2003.
	[11] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance		[20] Kang, H., "Route Optimization for Mobile Network by Using
	Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in		Bi-directional Between Home Agent and Top Level Mobile
	progress), July 2002.		Router", draft-hkang-nemo-ro-tlmr-00 (work in progress), June
			2003.
	[12] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[21] Ohnishi, H., "HMIP based Route optimization method in a mobile
	1981.		network", draft-ohnishi-nemo-ro-hmip-00 (work in progress),
			October 2003.
	[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[22] Paakkonen, P. and J. Latvakoski, "Mobile Network Prefix
	Specification", RFC 2460, December 1998.		Delegation extension for Mobile IPv6",
			draft-paakkonen-nemo-prefix-delegation-00 (work in progress),
			March 2003.
	Authors' Addresses		[23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
			draft-droms-nemo-dhcpv6-pd-01 (work in progress), February
			2004.
	Pascal Thubert		[24] Lee, K., "Route Optimization for Mobile Nodes in Mobile Network
	Cisco Systems Technology Center		based on Prefix Delegation", draft-leekj-nemo-ro-pd-02 (work
	Village d'Entreprises Green Side		in progress), February 2004.
	400, Avenue Roumanille
	Biot - Sophia Antipolis 06410
	FRANCE
	EMail: pthubert@cisco.com		[25] Jeong, J., "ND-Proxy based Route Optimization for Mobile Nodes
			in Mobile Network", draft-jeong-nemo-ro-ndproxy-02 (work in
			progress), February 2004.
	Marco Molteni		[26] Perera, E., "Extended Network Mobility Support",
	Cisco Systems Technology Center		draft-perera-nemo-extended-00 (work in progress), July 2003.
	Village d'Entreprises Green Side
	400, Avenue Roumanille
	Biot - Sophia Antipolis 06410
	FRANCE
	EMail: mmolteni@cisco.com		Authors' Addresses
	Chan-Wah Ng		Chan-Wah Ng
	Panasonic Singapore Laboratories Pte Ltd		Panasonic Singapore Laboratories Pte Ltd
	Blk 1022 Tai Seng Ave #06-3530		Blk 1022 Tai Seng Ave #06-3530
	Tai Seng Industrial Estate		Tai Seng Industrial Estate
	Singapore 534415		Singapore 534415
	SG		SG
			Phone: +65 65505420
	EMail: cwng@psl.com.sg		EMail: cwng@psl.com.sg
			Pascal Thubert
			Cisco Systems Technology Center
			Village d'Entreprises Green Side
			400, Avenue Roumanille
			Biot - Sophia Antipolis 06410
			FRANCE
			EMail: pthubert@cisco.com
	Hiroyuki Ohnishi		Hiroyuki Ohnishi
	NTT network service systems laboratories, NTT cooperation		NTT network service systems laboratories, NTT cooperation
	9-11, Midori-Cho 3-Chome		9-11, Midori-Cho 3-Chome
	Musashino-shi		Musashino-shi
	Tokyo 180-8585		Tokyo 180-8585
	JAPAN		JAPAN
	EMail: ohnishi.hiroyuki@lab.ntt.co.jp		EMail: ohnishi.hiroyuki@lab.ntt.co.jp
	Eun Kyoung Paik
	Seoul National University
	Shillim-dong, Kwanak-gu
	Seoul 151-744
	KOREA
	EMail: eun@mmlab.snu.ac.kr		Paik, Eun Kyoung
			KT
			Portable Internet Team, Convergence Lab., KT
			17 Woomyeon-dong, Seocho-gu
			Seoul 137-792
			Korea
			Phone: +82-2-526-5233
			Fax: +82-2-526-5200
			EMail: euna@kt.co.kr
			URI: http://mmlab.snu.ac.kr/~eun/
			Appendix A. Proposed Route Optimizations
			Here, we attempt to list the numerous proposed solutions according to
			the solution space defined in Section 3. Although we made effort in
			listing all possible solutions, sincere apology is extended to
			authors of solutions that we might have missed out.
			A.1 MR-to-CN Optimizations
			Most MR-to-CN optimizations proposals are implicitly achieved by
			sending mobile network prefixes to correspondent nodes. The Return
			Routability procedure with Network Prefix (RRNP) [14] proposed an
			extension to return routability procedure for verifying the validity
			of mobile network prefixes.
			One approach that uses the mobile router as a proxy for establishing
			route optimization on behalf of mobile network nodes can be found in
			[15].
			In addition, various nested tunnel optimizations proposals (see
			Appendix A.3) can also be extended to correspondent node, thus
			enabling the MR-to-CN optimizations. Example includes the Reverse
			Routing Header (RRH) [13], Access Router Option (ARO) [16].
			A.2 Infrastructure Optimizations
			All known infrastructure optimization proposals defines the entity
			known as correspondent router capable of terminating bi-directional
			tunnels from mobile routers on behalf of correspondent nodes, thereby
			achieving route optimization. The difference between these proposals
			is mainly the way correspondent routers are discovered. Proposals
			include:
			o Path Control Header (PCH) [17]
			The PCH approach requires the home agent to piggyback a Path
			Control Header on the packet when forwarding packets arriving from
			a bi-directional tunnel to a correspondent node. Because PCH is a
			hop-by-hop option header, all intermediate routers lying between
			the home agent and the correspondent node will inspect the PCH.
			If a correspondent router exists among these intermediate router,
			it can contact the mobile router (identified in the PCH) and
			establish a optimized tunnel with the mobile router.
			o Optimized Routing Cache (ORC) [18]
			The ORC approach defines the functionality of a correspondent
			router able to terminate bi-directional tunnels from mobile
			routers. Mobile routers discover correspondent routers by sending
			a query message to a multicast address corresponding to "all
			correspondent router" address. The query message contains the
			address of the correspondent node for which the mobile router
			wishes to send packets to. The correspondent router managing the
			network within which the correspondent node resides will responds
			to this query. The proposal also suggest correspondent router to
			inform mobile routers the prefix information of the network it is
			capable of managing, so that any other traffic flows that
			originate and end at the mobile network and the network the
			correspondent router is managing can also enjoy route
			optimization.
			A.3 Nested Tunnel Optimizations
			Many proposed solutions for NEMO Extended Support targets the nested
			tunnel optimization. Most of these involves sending of upstream
			information to the home agent of a nested mobile router, including
			o Reverse Routing Header (RRH) [13]
			The RRH approach avoids the multiple encapsulation of the traffic
			but maintains the home tunnel of the first mobile router on the
			egress path. The first mobile router on the way out (egress
			direction) encapsulates the packet over its reverse tunnel, using
			a form of Record Route header, the RRH.
			The upstream mobile routers simply swap their care-of address and
			the source of the packet, saving the original source in the RRH.
			The home agent transforms the RRH in a Routing Header to perform
			source routing across the nested mobile network, along the ingress
			path to the target mobile router.
			o Access Router Option (ARO) [16]
			The ARO approach is somewhat similar to the RRH in that only the
			home tunnel of the first nested mobile router in the egress path
			is maintained. This is done by having the nested mobile router to
			send an ARO in Binding Update to inform its home agent the address
			of its access router (i.e. an upstream mobile router). Using
			this information, the home agent can build a Routing Header to
			source-route a packet to the nested mobile router within in a
			nested mobile network. Upstream mobile routers can also send
			binding update messages to the home agent of the nested mobile
			router, thus allowing a complete routing header be built
			recursively by the home agent.
			o Nested Path Info (NPI) [19]
			The NPI approach is somewhat similar to the ARO approach, except
			that instead of sending only the home address of the upstream
			mobile router to its home agent, a nested mobile router send a
			nested information on the care-of addresses of all upstream mobile
			routers. Using this information, the home agent can build a
			Routing Header to source-route a packet to the nested mobile
			router within in a nested mobile network.
			o Top Level Mobile Router (TLMR) [20]
			In TLMR, each visiting mobile router obtains the address of the
			root-MR through router advertisement messages. This information
			is passed to its home agent in a binding update message. The
			visiting mobile router also registers with the root-MR. With
			these registrations, the root-MR maintains a topology of the
			mobile network. In addition, the root MR also establish tunnels
			with the home agents of every visiting mobile router. This way,
			packet to and from each nested mobile network will be relayed
			through the root-MR, through an additional tunnel between the
			root-MR and the home agent of the nested mobile network.
			o Hierarchical Mobile IP (HMIP) [21]
			This approach proposes an adaptation of HMIPv6 [10] for NEMO.
			Here, information on the root-MR (acting as a Mobile Anchor Point,
			MAP) is passed to nested mobile routers in the MAP option of a
			router advertisement. Nested mobile routers then register their
			regional and local care-of address with the root-MR. Packets are
			then transfered to and from a nested mobile router through two
			separate tunnels: one between the nested mobile router and the
			root-MR, the other between the root-MR and the home agent of the
			nested mobile router.
			Other approaches that does not really require the sending of upstream
			information to home agent includes:
			o Prefix Delegation [22][23][24]
			The prefix delegation approach is somewhat to HMIPv6 what NEMO is
			to MIPv6. The Access Router of the nested structure is both a
			NEMO home agent and a DHCP-PD server, for an aggregation that it
			owns and advertises to the infrastructure. When visiting the
			nested structure, each mobile router is delegated a mobile network
			prefix from the access router using DHCP-Prefix Delegation. The
			mobile router registers this delegated prefix to the access router
			that is acting as a NEMO home agent. The mobile router also
			autoconfigures an address from the delegated prefix and uses it as
			a care-of address to register its own mobile network prefix(es) to
			its own home agent using NEMO Basic Support. It is possible for a
			mobile router to protect its own mobile network prefixes while
			advertising in the clear the local prefix for other mobile routers
			to roam into. This allows a strict privacy of visited and
			visitors, and enables some specific policies in each mobile
			router.
			o Neighbor Discovery Proxy (ND-Proxy) [25]
			The ND-Proxy approach achieves route optimization by having mobile
			routers to act as neighbor discovery proxy. Mobile router will
			configure a care-of address from the network prefix advertised by
			its access router, and also relay this prefix to its subnets. As
			ND-Proxy, mobile routers will also handle neighbor discovery on
			behalf of visiting mobile nodes in its subnets. As such, the
			entire mobile network and its access network forms a logical
			multilink subnet, thus eliminating any nesting. This solution
			also lends itself well to achieve MIPv6-over-NEMO optimization.
			A.4 MIPv6-over-NEMO Optimizations
			Some solutions proposed for nested tunnels optimization can be
			extended for MIPv6-over-NEMO optimization, including Access Router
			Option (ARO) [16], Top Level Mobile Router (TLMR) [20], Prefix
			Delegation approaches [22][23][24], and Neighbor Discovery Proxy
			(ND-Proxy) [25]. One solution that caters specifically for
			MIPv6-over-NEMO optimization is:
			o Extended Network Mobility Support [26]
			This approach is somewhat similar to the Prefix Delegation in
			which the mobile router would obtain a prefix from its access
			network, and allows visiting mobile network nodes to autoconfigure
			their care-of addresses from this prefix. By doing so, packets
			destined to any MIPv6 node within the mobile network will not go
			through the home agent of the mobile router, thereby achieving
			MIPv6-over-NEMO optimization. This solution also allows the
			mobile router to act as home agent for local fixed nodes and local
			mobile nodes within the mobile network in an attempt to allow
			these nodes to achieve route optimization (using standard MIPv6
			techniques).
			A.5 Intra-NEMO Optimizations
			Currently, there are no proposals that specifically target intra-NEMO
			optimization, though as explained previously, most solutions that
			achieves MN-to-CN optimizations can also achieve intra-NEMO
			optimization.
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	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.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 184 change blocks.
	612 lines changed or deleted		1231 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/