< draft-thubert-nemo-ro-taxonomy-01.txt		draft-thubert-nemo-ro-taxonomy-02.txt >
	Network Working Group P. Thubert		Network Working Group P. Thubert
	Internet-Draft M. Molteni		Internet-Draft M. Molteni
	Expires: December 2, 2003 Cisco Systems		Expires: August 15, 2004 Cisco Systems
	C. Ng		C. Ng
	Panasonic Singapore Labs		Panasonic Singapore Labs
	June 3, 2003		H. Ohnishi
			NTT
			E. Paik
			Seoul National Univ.
			February 15, 2004
	Taxonomy of Route Optimization models in the Nemo Context		Taxonomy of Route Optimization models in the Nemo Context
	draft-thubert-nemo-ro-taxonomy-01		draft-thubert-nemo-ro-taxonomy-02
	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 in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that other
	other groups may also distribute working documents as Internet-		groups may also distribute working documents as Internet-Drafts.
	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 http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 December 2, 2003.		This Internet-Draft will expire on August 15, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Nemo enables Mobile Networks by extending Mobile IP to support Mobile		NEMO enables Mobile Networks by extending Mobile IP to support Mobile
	Routers. This paper documents how the MIPv6 concept of Route		Routers. This memo documents how the MIPv6 concept of Route
	Optimization can to be adapted for Nemo to optimize:		Optimization can to be adapted for NEMO to optimize traffic routing
			between nodes in a mobile network and their correspodnet nodes.
			Different route optimizations schemes are discussed, including:
	1. the nested tunnels of the nested Nemo configuration		1. route optimization with corresponding nodes initiated bu mobile
			routers on behalf of the mobile network nodes;
	2. router-to-router in the infrastructure as opposed to end-to-end.		2. a visiting mobile node performing MIPv6 RO over the NEMO base
			protocol;
	and much more ... :)		3. performing RO over the routing infrastructure involving
			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
			levels of nesting.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Nested Mobile Network . . . . . . . . . . . . . . . . . . 3		2. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . 3		3. MIPv6 Route Optimization over NEMO . . . . . . . . . . . . . . 4
	2.1.1 Pitfalls and threats . . . . . . . . . . . . . . . . . . . 7		4. Optimization within the infrastructure . . . . . . . . . . . . 4
	2.1.1.1 Securing the protocol . . . . . . . . . . . . . . . . . . 7		4.1 Route Optimization within a ISP network . . . . . . . . . . . 5
	2.1.1.2 Recursive complexity . . . . . . . . . . . . . . . . . . . 7		4.2 Correspondent Router . . . . . . . . . . . . . . . . . . . . . 6
	2.2 Route Optimization inside the Nested Mobile Network . . . 8		4.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . . . 7
	3. MR-to-CN . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Nested Mobile Network . . . . . . . . . . . . . . . . . . . . 8
	4. MIPv6 Route Optimization over Nemo . . . . . . . . . . . . 9		5.1 Nested Tunnels Optimization . . . . . . . . . . . . . . . . . 8
	5. Optimization within the infrastructure . . . . . . . . . . 9		5.2 Route Optimization inside the Nested Mobile Network . . . . . 12
	5.1 Route Optimization within a ISP network . . . . . . . . . 10		6. General Considerations . . . . . . . . . . . . . . . . . . . . 12
	5.2 Correspondent Router . . . . . . . . . . . . . . . . . . . 11		6.1 Securing the protocol in nested tunnels optimization . . . . . 12
	5.3 Distributed Anchor Routers . . . . . . . . . . . . . . . . 12		6.2 Recursive complexity in route optimization . . . . . . . . . . 12
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 13		6.3 Mobile Access router selection . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 13		6.4 Mobility transparency and RO . . . . . . . . . . . . . . . . . 14
	References . . . . . . . . . . . . . . . . . . . . . . . . 14		6.5 Multihoming Considerations . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15		7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Full Copyright Statement . . . . . . . . . . . . . . . . . 16		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
			References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . 19
	1. Introduction		1. Introduction
	This document assumes the reader is familiar with Mobile IPv6 defined		This document assumes the reader is familiar with Mobile IPv6 defined
	in [1], with the concept of Mobile Router (MR) and with the Nemo		in [1], with the concept of Mobile Router (MR) and with the Nemo
	terminology defined in [2].		terminology defined in [2].
	From the discussions on the mailing list, it appears that the common		From the discussions on the mailing list, it appears that the common
	current understanding of the problem space of Route Optimization		current understanding of the problem space of Route Optimization
	(RO), in the Nemo context, is still limited.		(RO), in the Nemo context, is still limited.
	This paper attempts to clarify the state of the discussion and		This draft attempts to clarify the state of the discussion and
	propose a taxonomy of the various aspects of the problem. We will		propose a taxonomy of the various aspects of the problem. We will
	look at different possible types of route optimizations related to		look at different possible types of route optimizations related to
	mobile network.		mobile network.
	Firstly, route optimizations involving nested mobile networks are		Firstly, the Mobile Router can initiate route optimization with
	explored. This involves minimizing the number of tunnels required
	when there is multiple levels of nesting.
	Secondly, the Mobile Router can initiate route optimization with
	corresponding nodes (CN) on behalf of the mobile network nodes (MNN).		corresponding nodes (CN) on behalf of the mobile network nodes (MNN).
	Thirdly, we consider the feasibility of having a visiting mobile node		Secondly, we consider the feasibility of having a visiting mobile
	(VMN) performing MIPv6 RO over the NEMO base protocol.		node (VMN) performing MIPv6 RO over the NEMO base protocol.
	Lastly, we explore the prospect of performing RO over the routing		Thirdly, we explore the prospect of performing RO over the routing
	infrastructure. This involve optimizing the route between two		infrastructure. This involves optimizing the route between two
	routers situated near to each end point.		routers situated near to each end point.
	2. Nested Mobile Network		Lastly, route optimizations involving nested mobile networks are
			explored. This involves minimizing the number of tunnels required
			when there is multiple levels of nesting.
	2.1 Nested Tunnels Optimization		2. MR-to-CN
	Let us illustrate the problem by an example. In this example, the		This section covers the case where the Route Optimization is
	nested Mobile Network has a tree topology. In the tree each node is		performed between the MR and the correspondent nodes which mobile
	a basic Mobile Network, represented by its MR.		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
			principle of the MIPv6 Reverse Routability (RR) test is broken. The
			RR test is meant to ensure the care-of address (CoA) and the home
			address (HoA) are collocated. With a mobile network, when the MR
			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
			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
			from the start of the RR test to determine the protocol. In
			particular, the Mobile Node and the CN must decide whether checking
			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
			negotiation capability at this time.
			3. MIPv6 Route Optimization over NEMO
			MIPv6 mobile nodes can move everywhere. If the user brings mobile
			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
			Optimization is obtained if the path in the Infrastructure is the
			same as if the Mobile Network was attached at the attachment point of
			the Mobile Router (i.e., there is not additional Tunneling that is
			linked to NEMO).
			A possible approach to this is to extend the solution for nested
			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
			most likely require some extensions for a MIPv6 VMN and CN.
			4. Optimization within the infrastructure
			This section elaborates on cases where the Route Optimization is
			performed within the Routing Infrastructure. This model is useful
			when an ISP wants to control the route optimization procedures and
			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.
			The general idea is that there is a correspondent-side router (C-side
			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
			# 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
			This optimization is only valid when the path via the C-side Router
			is shorter than the path via the Home Agent.
			The Optimization can take place independently for the 2 directions of
			the traffic:
			Egress
			The MR locates the C-side Router, establishes a tunnel with that
			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
			The C-side Router is on the way of the traffic from the
			Correspondent Node to the Home Agent. Also, it is aware of the MR
			and the mobile network behind the MR and establishes the
			appropriate tunnel and route. After this, it is able to reroute
			traffic to the mobile network over the tunnel to the MR.
			4.1 Route Optimization within a ISP network
			This form of Route Optimization provides local savings for an ISP.
			This idea was described in Ohnishi's Mobile Border Gateway draft. The
			goal is to locate the closest (BGP) gateway for a Correspondent that
			is located outside of the domain, and tunnel between the MR and that
			gateway as opposed to the Home Agent for that specific Correspondent.
			4.2 Correspondent Router
			A globally better optimization is obtained if the tunnel from the MR
			is terminated closer to the destination on the Correspondent side.
			This is the role of a Correspondent Router (CR).
			+-------------------+ # :== Tunnel
			| Autonomous System | o :== Optimized
			| ----------------- | n :== Non-Optimized
			| |
			| |
			| Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent
			| | # n #
			| o | # n #
			| o | # n #
			| o | # n #
			| o | # n #
			| o | # n #
			| #################################### ?
			| CR oooooooooooooooooooooooooooooooooooooo Mobile
			| #################################### Router
			| | |
			+-------------------+ ===========Mobile Network========
			Correspondent Router
			The MR locates the CR for a given Correspondent and establishes a
			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
			traffic from the Correspondent to the Mobile Networks in order to
			reroute the traffic over the appropriate Tunnel. This can be achieved
			in several fashions:
			Redistribution
			There's a limited Number of CRs that cover an Autonomous System.
			They redistribute the Mobile Routes on the fly, or within rate and
			amount limits. Garbage Collection is done at appropriate time to
			limit the perturbation on the Routing.
			Default Router
			The CR is a Default Router for the Correspondent, or for the whole
			AS of the Correspondent (it's a border gateway). In this case,
			redistribution is not needed.
			Core Routers
			The Core Routers for the network of the Correspondent are all CRs.
			If the path from the correspondent to the Home Agent does not pass
			via a CR, then it's not worth optimizing. If it is, then the CRs
			are on the way. Again, redistribution is not needed.
			4.3 Distributed Anchor Routers
			Taking the idea of a correspondent router a step further, it is
			possible to have a distributed set of anchor routers across the
			Internet. Outgoing packets sent from a mobile network will be
			tunneled to one of the nearest anchor router (instead of to the home
			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
			o # n #
			o # n # # :== Tunnel
			o # n # o :== Optimized
			o # n # n :== Non-Optimized
			o # n #
			C-Side ################## M-Side ###### n #
			Anchor oooooooooooooooooo Anchor oooo Mobile
			Router ################## Router #### Router
			|
			====Mobile Network=======
			Optimization in the Infrastructure
			The C-Side Anchor Router will be subjected to the same condition as
			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
			Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)
			[9]. In fact, it can be combined with HMIPv6 whereby each M-Side
			anchor router is also an MAP, and the MR obtains a regional
			care-of-address from the MAP.
			5. Nested Mobile Network
			5.1 Nested Tunnels Optimization
			This section covers the case where one mobile network is within
			another mobile network. For example, a user brings a Personal Area
			Network (PAN) consisting of some IP devices to a train which is also
			using NEMO technology. In another example, a car which conatins a
			mobile network moves into the ferry which has another mobile network.
			This configuration of mobile networks within another mobile network
			is called nested Mobile Networks.
			Let us illustrate the problem by an example. In this example, the
			nested Mobile Network has a tree topology. In the tree each node is a
			basic Mobile Network, represented by its MR.
	+---------------------+		+---------------------+
	| Internet |---CN		| Internet |---CN
	+---------------|-----+		+---------------|-----+
	/ Access Router		/ Access Router
	MR3_HA |		MR3_HA |
	======?======		======?======
	MR1		MR1
	|		|
	====?=============?==============?===		====?=============?==============?===
	skipping to change at page 4, line 27 ¶		skipping to change at page 8, line 43 ¶
	MR3		MR3
	|		|
	==|=========?== Net3		==|=========?== Net3
	LFN1 MR4		LFN1 MR4
	|		|
	=========		=========
	An example nested Mobile Network		An example nested Mobile Network
	This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3)		This example focuses on a Local Fixed Node (LFN) at depth 3 (in Net3)
	inside the tree, represented by its mobile router MR3. The path to		inside the tree, represented by its mobile router MR3. The path to
	the Top Level Mobile Router (TLMR) MR1 and then the Internet is:		the Top Level Mobile Router (TLMR) MR1 and then the Internet is:
	MR3 -> MR2 -> MR1 -> Internet		MR3 -> MR2 -> MR1 -> Internet
	Consider the case where a LFN belonging to Net3 sends a packet to a		Consider the case where a LFN belonging to Net3 sends a packet to a
	Correspondent Node (CN) in the Internet, and the CN replies back.		Correspondent Node (CN) in the Internet, and the CN replies back.
	With no Nested Tunnels Optimization, we would have three bi-		With no Nested Tunnels Optimization, we would have three
	directional nested tunnels, as described in [3] and illustrated in		bi-directional nested tunnels, as described in [3] and illustrated in
	the following drawings:		the following drawings:
	-----------.		-----------.
	--------/ /-----------.		--------/ /-----------.
	-------/ | | /-----------		-------/ | | /-----------
	CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN		CN ------( - - | - - - | - - - | - - - | - - - (-------- LFN
	MR3_HA -------\ | | \----------- MR3		MR3_HA -------\ | | \----------- MR3
	MR2_HA --------\ \----------- MR2		MR2_HA --------\ \----------- MR2
	MR1_HA ----------- MR1		MR1_HA ----------- MR1
	No Nested Tunnels Optimization		No Nested Tunnels Optimization
	Such a solution introduces the following problems:		Such a solution introduces the following problems:
	"Pinball" routing		"Pinball" routing
	Both inbound and outbound packets will flow via the HAs of all the		Both inbound and outbound packets will flow via the HAs of all the
	MRs on their path within the NEMO, with increased latency, less		MRs on their path within the NEMO, with increased latency, less
	resilience and more bandwidth usage. To illustrate this effect,		resilience and more bandwidth usage. To illustrate this effect,
	the figure below shows the route taken by a packet sent from LFN		the figure below shows the route taken by a packet sent from LFN
	to CN:		to CN:
	+--> HAofMR1 ---------------------+		+--> HAofMR1 ---------------------+
	| |		| |
	+----------------- HAofMR2 <--+ |		+----------------- HAofMR2 <--+ |
	| |		| |
	+---------------+ |		+---------------+ |
	| V		| V
	HAofMR3 <------+ CN		HAofMR3 <------+ CN
	|		|
	|		|
	LFN --> MR1 --> MR2 --> MR3		LFN --> MR1 --> MR2 --> MR3
	'Pinball' Routing		'Pinball' Routing
	Packet size		Packet size
	An extra IPv6 header is added per level of nesting to all the		An extra IPv6 header is added per level of nesting to all the
	packets. The header compression suggested in [4] cannot be		packets. The header compression suggested in [4] cannot be applied
	applied because both the source and destination (the intermediate		because both the source and destination (the intermediate MR and
	MR and its HA), are different hop to hop.		its HA), are different hop to hop.
	On the other hand, with a Nested Tunnel Optimization, we would have		On the other hand, with a Nested Tunnel Optimization, we would have
	at most one bi-directional tunnel outside the Mobile Network, that		at most one bi-directional tunnel outside the Mobile Network, that
	may depend on the traffic flow:		may depend on the traffic flow:
	__- --_		__- --_
	Tunnel---------------------------- MR1 ( Mobile ) MR3		Tunnel---------------------------- MR1 ( Mobile ) MR3
	CN ----------( - - - - - - - - - - ( - - - - )--------- LFN		CN ----------( - - - - - - - - - - ( - - - - )--------- LFN
	Endpoint---------------------------- MR1 ( Network ) MR3		Endpoint---------------------------- MR1 ( Network ) MR3
	--___---		--___---
	Nested Tunnels Optimization		Nested Tunnels Optimization
	The end-point of such a Tunnel on the Mobile side may either be MR1		The end-point of such a Tunnel on the Mobile side may either be MR1
	or MR3, depending on the solution. In the case of a Mobile Node		or MR3, depending on the solution. In the case of a Mobile Node
	visiting Net3, that Mobile Node may also be the end-point.		visiting Net3, that Mobile Node may also be the end-point.
	The potential approaches for avoiding the nesting of tunnels include:		The potential approaches for avoiding the nesting of tunnels include:
	Mobile Aggregation		Mobile Aggregation
	This model applies to a category of problems were the Mobile		This model applies to a category of problems were the Mobile
	Networks share a same administration and consistently move		Networks share a same administration and consistently move
	together (e.g. a fleet at sea). In this model, there is a		together (e.g. a fleet at sea). In this model, there is a cascade
	cascade of Home Agents.		of Home Agents.
	The main Home Agent is fixed in the infrastructure, and advertises		The main Home Agent is fixed in the infrastructure, and advertises
	an aggregated view of all the Mobile Networks. This aggregation		an aggregated view of all the Mobile Networks. This aggregation is
	is actually divided over a number of Mobile Routers, the TLMRs.		actually divided over a number of Mobile Routers, the TLMRs. The
	The TLMRs subdivide some of their address space to the other		TLMRs subdivide some of their address space to the other Mobile
	Mobile Routers forming their fleet, for which they are Home Agent.		Routers forming their fleet, for which they are Home Agent.
	As Home Agents, the TLMRs terminate MIP Tunnels from the inside of		As Home Agents, the TLMRs terminate MIP Tunnels from the inside of
	the Mobile Network. As Mobile Router, they also terminate their		the Mobile Network. As Mobile Router, they also terminate their
	home Tunnels. As routers, they forward packets between the 2		home Tunnels. As routers, they forward packets between the 2
	tunnels.		tunnels.
	Surrogate		Surrogate
	The TLMR acts as a proxy in the MIP registration, in a fashion of		The TLMR acts as a proxy in the MIP registration, in a fashion of
	MIPv4 Foreign Agent or HMIP MAP (see [8]). For instance, the TLMR		MIPv4 Foreign Agent or HMIP MAP (see [9]). For instance, the TLMR
	maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and		maintains a Tunnel to each MR, a Tunnel to the HA of each MR, and
	switches packets between the two.		switches packets between the two.
	Internal Routing and gateway		Internal Routing and gateway
	This item can be approached from a MANET standpoint. This was		This item can be approached from a MANET standpoint. This was
	already done for DSR (see [9]) and AODV (see [10] and [7]) From a		already done for DSR (see [10]) and AODV (see [11] and [8]) From a
	Nemo standpoint, a full MANET is not necessary since the goal is		Nemo standpoint, a full MANET is not necessary since the goal is
	to find a way to the infrastructure, as opposed to any-to-any		to find a way to the infrastructure, as opposed to any-to-any
	connectivity.		connectivity.
	RRH		RRH
	The Reverse Routing Header (RRH) approach avoids the multiple		The Reverse Routing Header (RRH) approach avoids the multiple
	encapsulation of the traffic but maintains the home tunnel of the		encapsulation of the traffic but maintains the home tunnel of the
	first MR on the egress path. It is described in details in [5].		first MR on the egress path. It is described in details in [5].
	The first MR on the way out (egress direction) encapsulates the		The first MR on the way out (egress direction) encapsulates the
	packet over its reverse tunnel, using a form of Record Route		packet over its reverse tunnel, using a form of Record Route
	header, the RRH.		header, the RRH.
	The next MRs simply swap their CoA and the source of the packet,		The next MRs simply swap their CoA and the source of the packet,
	saving the original source in the RRH. The HA transforms the RRH		saving the original source in the RRH. The HA transforms the RRH
	in a Routing Header to perform a Source Routing across the nested		in a Routing Header to perform a Source Routing across the nested
	Mobile Network, along the ingress path to the target MR.		Mobile Network, along the ingress path to the target MR.
	Access Router Option		Access Router Option
	The Access Router Option (ARO) approach [6] is somewhat similar to		The Access Router Option (ARO) approach [6] is somewhat similar to
	the RRH in that only the home tunnel of the first MR in the egress		the RRH in that only the home tunnel of the first MR in the egress
	path is maintained. This is done by having MR to send an ARO in		path is maintained. This is done by having MR to send an ARO in
	Binding Update to inform its HA the address of its access router.		Binding Update to inform its HA the address of its access router.
	Using this information, HA can build a Routing Header to source-		Using this information, HA can build a Routing Header to
	route a packet to the target MR within in a nested mobile network.		source-route a packet to the target MR within in a nested mobile
	Details can be found in [6].		network. Details can be found in [6].
	2.1.1 Pitfalls and threats		Prefix delegation approach
	2.1.1.1 Securing the protocol		The prefix delegation approach [7] 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 MR is delegated a mobile network prefix
			from the AR using DHCP-Prefix Delegation. The MR registers this
			delegated MNP to the AR that is acting as a Nemo Home Agent. The
			MR also autoconfigures an address from the delegated MNP and uses
			it as a CareOf to register its own MNPs to its own Home Agent
			using Nemo basic support. It is possible for a MR to protect its
			own MNPs while advertising in the clear the local MNP for other
			MRs to roam in. This allows a strict privacy of visited and
			visitors, and enables some specific policies in each Mobile
			Router. Details can be found in [7].
			5.2 Route Optimization inside the Nested Mobile Network
			Although optimization within a mobile network is not within the
			charter of the NEMO working group, it might be insightful to discuss
			such optimizations.
			The expectation is that the mobile routes installed by NEMO can
			cohabit with a MANET support that would perform the RO inside the
			Nested Mobile Network. In other words, MIP redistributes its prefixes
			locally to a MANET and the MR-HA tunnel is bypassed.
			6. General Considerations
			6.1 Securing the protocol in nested tunnels optimization
	These approaches are generally difficult to secure unless all the		These approaches are generally difficult to secure unless all the
	Mobile Routers and Visiting Mobile Node belong to a same		Mobile Routers and Visiting Mobile Node belong to a same
	administrative domain and share predefined Security Associations.		administrative domain and share predefined Security Associations.
	Even if an intermediate MR is 'trusted', this does not prove it is		Even if an intermediate MR is 'trusted', this does not prove it is
	able to provide the necessary bandwidth, and may not provide a good		able to provide the necessary bandwidth, and may not provide a good
	service. Eventually, a MR that is capable of securing (IPSec) its		service. Eventually, a MR that is capable of securing (IPSec) its
	traffic may select a Mobile Access Router based on quality of service		traffic may select a Mobile Access Router based on quality of service
	heuristics as opposed as trust.		heuristics as opposed as trust.
	The problem is global to the whole Mobile Network in the case of a		The problem is global to the whole Mobile Network in the case of a
	MANET-based solution. For an RRH-based solution, the threat comes		MANET-based solution. For an RRH-based solution, the threat comes
	from on-axis MRs in the nested Mobile Network but is mostly limited		from on-axis MRs in the nested Mobile Network but is mostly limited
	to denial of service. This is detailed in [5]. The approach taken		to denial of service. This is detailed in [5]. The approach taken is
	is to limit the threat to Black Hole and Grey Hole by using IPSec.		to limit the threat to Black Hole and Grey Hole by using IPSec.
	2.1.1.2 Recursive complexity		6.2 Recursive complexity in route optimization
	A number of drafts and publications suggest -or can be extended to- a		A number of drafts and publications suggest -or can be extended to- a
	model where the Home Agent and any arbitrary Correspondent would		model where the Home Agent and any arbitrary Correspondent would
	actually get individual binding from the chain of nested Mobile		actually get individual binding from the chain of nested Mobile
	Routers, and form a routing header appropriately.		Routers, and form a routing header appropriately.
	An intermediate MR would keep track of all the pending communications		An intermediate MR would keep track of all the pending communications
	between hosts in its subtree of Mobile Networks and their CNs, and a		between hosts in its subtree of Mobile Networks and their CNs, and a
	binding message to each CN each time it changes its point of		binding message to each CN each time it changes its point of
	attachment.		attachment.
	skipping to change at page 8, line 10 ¶		skipping to change at page 13, line 10 ¶
	If this was done, then each CN, by receiving all the binding messages		If this was done, then each CN, by receiving all the binding messages
	and processing them recursively, could infer a partial topology of		and processing them recursively, could infer a partial topology of
	the nested Mobile Network, sufficient to build a multi-hop routing		the nested Mobile Network, sufficient to build a multi-hop routing
	header for packets sent to nodes inside the nested Mobile Network.		header for packets sent to nodes inside the nested Mobile Network.
	However, this extension has a cost:		However, this extension has a cost:
	1. Binding Update storm		1. Binding Update storm
	when one MR changes its point of attachment, it needs to send a		when one MR changes its point of attachment, it needs to send a
	BU to all the CNs of each node behind him. When the Mobile		BU to all the CNs of each node behind him. When the Mobile
	Network is nested, the number of nodes and relative CNs can be		Network is nested, the number of nodes and relative CNs can be
	huge, leading to congestions and drops.		huge, leading to congestions and drops.
	2. Protocol Hacks		2. Protocol Hacks
	Also, in order to send the BUs, the MR has to keep track of all		Also, in order to send the BUs, the MR has to keep track of all
	the traffic it forwards to maintain his list of CNs. In case of		the traffic it forwards to maintain his list of CNs. In case of
	IPSec tunneled traffic, that CN information may not be available.		IPSec tunneled traffic, that CN information may not be available.
	3. CN operation		3. CN operation
	The computation burden of the CN becomes heavy, because it has to		The computation burden of the CN becomes heavy, because it has to
	analyze each BU in a recursive fashion in order to infer nested		analyze each BU in a recursive fashion in order to infer nested
	Mobile Network topology required to build a multi hop routing		Mobile Network topology required to build a multi hop routing
	header.		header.
	4. Missing BU		4. Missing BU
	skipping to change at page 8, line 39 ¶		skipping to change at page 13, line 39 ¶
	If a CN doesn't receive the full set of PSBU sent by the MR, it		If a CN doesn't receive the full set of PSBU sent by the MR, it
	will not be able to infer the full path to a node inside the		will not be able to infer the full path to a node inside the
	nested Mobile Network. The RH will be incomplete and the packet		nested Mobile Network. The RH will be incomplete and the packet
	may or may not be delivered.		may or may not be delivered.
	5. Obsolete BU		5. Obsolete BU
	If the Binding messages are sent asynchronously by each MR, then,		If the Binding messages are sent asynchronously by each MR, then,
	when the relative position of MRs and/or the TLMR point of		when the relative position of MRs and/or the TLMR point of
	attachment change rapidly, the image of Mobile Network that the		attachment change rapidly, the image of Mobile Network that the
	CN maintains is highly unstable. If only one BU in the chain is		CN maintains is highly unstable. If only one BU in the chain is
	obsolete due to the movement of an intermediate MR, the		obsolete due to the movement of an intermediate MR, the
	connectivity may be lost.		connectivity may be lost.
	2.2 Route Optimization inside the Nested Mobile Network		6.3 Mobile Access router selection
	This is not part of the Nemo Charter.
	The expectation is that the mobile routes installed by Nemo can
	cohabit with a MANET support that would perform the RO inside the
	Nested Mobile Network. In other words, MIP redistributes its
	prefixes locally to a MANET and the MR-HA tunnel is bypassed.
	3. MR-to-CN
	This section covers the case where the Route Optimization is
	performed between the MR and the Correspondent Node.
	A major issue is that the MIPv6 Reverse Routability test is broken,
	since it is meant to ensure that the CoA (the MR) an the Home Address
	(the Mobile Node) are collocated. With a Mobile Network, a LFN is
	reachable via the Care-Of Address, but not at the Care-Of Address.
	Some tricks may be performed on the fly by the MRs but it seems that
	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
	from the start of the RR test to determine the protocol. In
	particular, the Mobile Node and the CN must decide whether checking
	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
	negotiation capability at this time.
	4. MIPv6 Route Optimization over Nemo
	When a Mobile Node visits a Mobile Network, the best Route
	Optimization is obtained if the path in the Infrastructure is the
	same as if the Mobile Network was attached at the attachment point of
	the Mobile Router (i.e., there is not additional Tunneling that is
	linked to Nemo).
	A possible approach to this is to extend the solution for nested
	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
	most likely require some extensions for a MIPv6 VMN and CN.
	5. Optimization within the infrastructure
	This section elaborates on cases where the Route Optimization is
	performed within the Routing Infrastructure. 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.
	The general idea is that there is a correspondent-side Router in the
	infrastructure that is located "closer" to the Correspondent than the
	HA. That Router can terminate MIP on behalf of the CN.
	Correspondent nnnnnnnnnnnnnnnnnnnnnnnn Home Agent
	# 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
	This optimization is only valid when the path via the correspondent-
	side Router is shorter than the path via the Home Agent.
	The Optimization can take place independently for the 2 directions of
	the traffic:
	Egress
	The MR locates the correspondent-side Router, establishes a Tunnel
	with that Router and sets a route to the Correspondent via the
	correspondent-side Router over the Tunnel. At this point, the
	traffic to the Correspondent does not flow via the Home Agent
	anymore.
	Ingress
	The correspondent-side Router is on the way of the traffic from
	the Correspondent to the Home Agent. Also, it is aware of the MR
	and the Mobile Networks behind the MR and establishes the
	appropriate Tunnel and Route. At that point, it is able to
	reroute the traffic to the Mobile Network over the Tunnel to the
	MR.
	5.1 Route Optimization within a ISP network
	This form of Route Optimization provides local savings for a ISP.
	This idea was described in Ohnishi's Mobile Border Gateway draft.
	The goal is to locate the closest (BGP) gateway for a Correspondent
	that is located outside of the domain, and tunnel between the MR and
	that gateway as opposed to the Home Agent for that specific
	Correspondent.
	5.2 Correspondent Router
	A globally better optimization is obtained if the tunnel from the MR
	is terminated closer to the destination on the Correspondent side.
	This is the role of a Correspondent Router (CR).
	+-------------------+ # :== Tunnel
	| Autonomous System | o :== Optimized
	| ----------------- | n :== Non-Optimized
	| |
	| |
	| Correspondent nnnnnnnnnnnnnnnnnnnnnnnnnnnnn Home Agent
	| | # n #
	| o | # n #
	| o | # n #
	| o | # n #
	| o | # n #
	| o | # n #
	| #################################### ?
	| CR oooooooooooooooooooooooooooooooooooooo Mobile
	| #################################### Router
	| | |
	+-------------------+ ===========Mobile Network========
	Correspondent Router		In some case, nested Mobile Networks attaches to visiting network
			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.
	The MR locates the CR for a given Correspondent and establishes a		6.4 Mobility transparency and RO
	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		[cwng's interpretation of Mobility Transparency in RO]
	traffic from the Correspondent to the Mobile Networks in order to
	reroute the traffic over the appropriate Tunnel. This can be
	achieved in several fashions:
	Redistribution		It is desirable in mobility-related protocols that the mobility of a
			mobile node is transparent to other entities and other layers in the
			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.
	There's a limited Number of CRs that cover an Autonomous System.		Such a feature is, as mentioned, desirable. However, when route
	They redistribute the Mobile Routes on the fly, or within rate and		optimizations, end-to-end principle, and other factors come into
	amount limits. Garbage Collection is done at appropriate time to		consideration, achieving mobility transparency may not be practical.
	limit the perturbation on the Routing.
	Default Router		For instance, to achieve nested tunnel optimizations, the mobility of
			the top-level MR is often exposed to other entities, such as the HA
			of a nested MR. In the case of MR performing BU for MNNs, it might
			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.
	The CR is a Default Router for the Correspondent, or for the whole		Thus, one should bear in mind when designing RO solution that a
	AS of the Correspondent (it's a border gateway). In this case,		sacrifice might be necessary when weighing conflicting factors such
	redistribution is not needed.		as mobility transparency, optimization level, and end-to-end
			integrity.
	Core Routers		[Hosik's interpretation of Mobility Transparency in RO]
	The Core Routers for the network of the Correspondent are all CRs.		In the case of extended support of NEMO such as nested NEMO, mobility
	If the path from the correspondent to the Home Agent does not pass		transparency is desirable but that is not mandatory for the
	via a CR, then it's not worth optimizing. If it is, then the CRs		efficiency of the route optimization. For example, the notebook and
	are on the way. Again, redistribution is not needed.		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.
	5.3 Distributed Anchor Routers		[Onishi's interpretation of Mobility Transparency in RO]
	Taking the idea of a correspondent router a step further, it is		In RO solutions, MR can optimize the route between its own HA and MR.
	possible to have a distributed set of anchor routers across the		It is desirable that communication can not be interrupted by this
	Internet. Outgoing packets sent from a mobile network will be		route optimization. ????
	tunneled to one of the nearest anchor router (instead of to the home
	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		6.5 Multihoming Considerations
	o # n #
	o # n # # :== Tunnel
	o # n # o :== Optimized
	o # n # n :== Non-Optimized
	o # n #
	C-Side ################## M-Side ###### n #
	Anchor oooooooooooooooooo Anchor oooo Mobile
	Router ################## Router #### Router
	|
	====Mobile Network=======
	Optimization in the Infrastructure		In multihomed mobile networks, route optimization is dependant on how
			the connections to the Internet are available and selected.
	The C-Side Anchor Router will be subjected to the same condition as		In case of macro mobility, we may have multiple HAs from place to
	listed in the previous sub-section if packets sent from the CN to the		place. New route optimization could be possible by routing between CN
	mobile network are to be route-optimized too. Otherwise, the		and one of the multiple Home Agents (possibly using differenc Home
	solution will only partially optimize routing to a triangular routing		Addresses).
	(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		When multiple connections are available for the purpose of fault
	Mobility Anchor Point (MAP) proposed in Hierarchical MIPv6 (HMIPv6)		tolerance, a selection mechanism is needed for CN to eveluate the
	[8]. In fact, it can be combined with HMIPv6 whereby each M-Side		connection availability in order to perform route optimization.
	anchor router is also an MAP, and the MR obtains a regional care-of-
	address from the MAP.
	6. Conclusion		7. Conclusion
	The Problem space of Route Optimization in the Nemo context is		The Problem space of Route Optimization in the NEMO context is
	multifold and can be split is several work areas. It will be		multifold and can be split is 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		Hopefully, the solutions will build on MIPv6 ([1]), as recommended by
	the Nemo Charter. On the other hand, MIPv6 seems to be evolving in a		the NEMO Charter. On the other hand, MIPv6 seems to be evolving in a
	direction that makes it more and more difficult to provide a Nemo		direction that makes it more and more difficult to provide a NEMO
	solution with backward compatibility, since:		solution with backward compatibility, since:
	1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,		1) The RR test prevents a MR-LFN dichotomy on the Mobile Side,
	2) The RR test has no negotiable option and is not open for		2) The RR test has no negotiable option and is not open for
	extension, and		extension, and
	3) The HaO and RH type 2 are designed for a collocated CareOf		3) The HaO and RH type 2 are designed for a collocated CareOf
	Address. More specifically, they are not designed to be multi-hop as		Address. More specifically, they are not designed to be multi-hop as
	RRH is, and not extensible, though RRH can be considered as an		RRH is, and not extensible, though RRH can be considered as an
	extension of HaO.		extension of HAO.
	The authors intent is to trigger fruitful discussions that in turn		The authors intent is to trigger fruitful discussions that in turn
	will enhance our common understanding of the problem space so that at		will enhance our common understanding of the problem space so that at
	some point, this paper turns into a problem statement for the Nemo		some point, this paper turns into a problem statement for the Nemo
	Route Optimization.		Route Optimization.
	7. Acknowledgements		8. Acknowledgements
	The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki		The authors wish to thank: Greg Daley, Thierry Ernst, Hiroyuki
	Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji		Ohnishi, T.J. Kniveton, Alexandru Petrescu, Hesham Soliman, Ryuji
	Wakikawa and Patrick Wetterwald for their various contributions.		Wakikawa and Patrick Wetterwald for their various contributions.
	References		References
	[1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in		[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
	IPv6", draft-ietf-mobileip-ipv6-21 (work in progress), March		IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July
	2003.		2003.
	[2] Lach, H. and T. Ernst, "Network Mobility Support Terminology",		[2] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-00 (work in progress), May 2003.		draft-ietf-nemo-terminology-00 (work in progress), May 2003.
	[3] Kniveton, T., "Mobile Router Tunneling Protocol", draft-		[3] kniveton, t., "Mobile Router Support with Mobile IP",
	kniveton-mobrtr-03 (work in progress), November 2002.		draft-kniveton-mobrtr-02 (work in progress), July 2002.
	[4] Deering, S. and B. Zill, "Redundant Address Deletion when		[4] Deering, S. and B. Zill, "Redundant Address Deletion when
	Encapsulating IPv6 in IPv6", draft-deering-ipv6-encap-addr-		Encapsulating IPv6 in IPv6",
	deletion-00 (work in progress), November 2001.		draft-deering-ipv6-encap-addr-deletion-00 (work in progress),
			November 2001.
	[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and		[5] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and
	its application to Mobile Networks", draft-thubert-nemo-		its application to Mobile Networks",
	reverse-routing-header-01 (work in progress), October 2002.		draft-thubert-nemo-reverse-routing-header-04 (work in
			progress), February 2004.
	[6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization		[6] Tanaka, T. and C. Ng, "Securing Nested Tunnels Optimization
	with Access Router Option", draft-ng-nemo-access-router-option-		with Access Router Option",
	00 (work in progress), November 2002.		draft-ng-nemo-access-router-option-00 (work in progress),
	[7] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc
	Networks", draft-wakikawa-manet-globalv6-02 (work in progress),
	November 2002.		November 2002.
	[8] Castelluccia, C., Malki, K., Soliman, H. and L. Bellier,		[7] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
	"Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-		draft-droms-nemo-dhcpv6-pd-01 (work in progress), February
	ietf-mobileip-hmipv6-07 (work in progress), October 2002.		2004.
	[9] Johnson, D., Maltz, D., Broch, J. and J. Jetcheva, "The Dynamic		[8] Wakikawa, R., "Global Connectivity for IPv6 Mobile Ad Hoc
	Source Routing Protocol for Mobile Ad Hoc Networks", draft-		Networks", draft-wakikawa-manet-globalv6-03 (work in progress),
	ietf-manet-dsr-07 (work in progress), February 2002.		October 2003.
	[10] Das, S., Perkins, C. and E. Royer, "Ad Hoc On Demand Distance		[9] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier,
	Vector (AODV) Routing", draft-ietf-manet-aodv-13 (work in		"Hierarchical MIPv6 mobility management (HMIPv6)",
	progress), February 2003.		draft-ietf-mobileip-hmipv6-06 (work in progress), July 2002.
	[11] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[10] Johnson, D., "The Dynamic Source Routing Protocol for Mobile Ad
			Hoc Networks (DSR)", draft-ietf-manet-dsr-09 (work in
			progress), April 2003.
			[11] Perkins, C., Royer, E. and S. Das, "Ad Hoc On Demand Distance
			Vector (AODV) Routing", draft-ietf-manet-aodv-11 (work in
			progress), July 2002.
			[12] Postel, J., "Internet Protocol", STD 5, RFC 791, September
	1981.		1981.
	[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)		[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	Specification", RFC 2460, December 1998.		Specification", RFC 2460, December 1998.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert		Pascal Thubert
	Cisco Systems Technology Center		Cisco Systems Technology Center
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue Roumanille		400, Avenue Roumanille
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	skipping to change at page 16, line 5 ¶		skipping to change at page 17, line 38 ¶
	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
	EMail: cwng@psl.com.sg		EMail: cwng@psl.com.sg
			Hiroyuki Ohnishi
			NTT network service systems laboratories, NTT cooperation
			9-11, Midori-Cho 3-Chome
			Musashino-shi
			Tokyo 180-8585
			JAPAN
			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
			Intellectual Property Statement
			The IETF takes no position regarding the validity or scope of any
			intellectual property or other rights that might be claimed to
			pertain to the implementation or use of the technology described in
			this document or the extent to which any license under such rights
			might or might not be available; neither does it represent that it
			has made any effort to identify any such rights. Information on the
			IETF's procedures with respect to rights in standards-track and
			standards-related documentation can be found in BCP-11. Copies of
			claims of rights made available for publication and any assurances of
			licenses to be made available, or the result of an attempt made to
			obtain a general license or permission for the use of such
			proprietary rights by implementors or users of this specification can
			be obtained from the IETF Secretariat.
			The IETF invites any interested party to bring to its attention any
			copyrights, patents or patent applications, or other proprietary
			rights which may cover technology that may be required to practice
			this standard. Please address the information to the IETF Executive
			Director.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph are		kind, provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for		developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be		copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than		followed, or as required to translate it into languages other than
	English.		English.
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		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. 80 change blocks.
	302 lines changed or deleted		476 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/