< draft-thubert-tree-discovery-01.txt		draft-thubert-tree-discovery-02.txt >
	NEMO Working Group P. Thubert		NEMO Working Group P. Thubert
	Internet-Draft Cisco		Internet-Draft Cisco
	Expires: April 11, 2005 N. Montavont		Expires: January 16, 2006 C. Bontoux
			Fortinet
			N. Montavont
	LSIIT - ULP		LSIIT - ULP
	October 11, 2004		July 15, 2005
	Nested Nemo Tree Discovery		Nested Nemo Tree Discovery
	draft-thubert-tree-discovery-01.txt		draft-thubert-tree-discovery-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 11, 2005.		This Internet-Draft will expire on January 16, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The purpose of this paper is to describe a minimum set of features		The purpose of this paper is to describe a minimum set of features
	that extends the Nemo basic support in order to avoid loops in the		that extends the Nemo basic support [4] in order to avoid loops in
	nested Nemo case. As a result, Mobile Routers assemble into a tree		the nested Nemo case. As a result, Mobile Routers assemble into a
	that can be optimized based on various metrics.		tree that can be optimized based on various metrics.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 3
	3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1 Multihomed nested mobile network . . . . . . . . . . . . . 4		3.1 Multi-Homed nested mobile network . . . . . . . . . . . . 4
	3.2 Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 5		3.2 Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 5
	4. Router Advertisement extensions . . . . . . . . . . . . . . . 6		4. Router Advertisement extensions . . . . . . . . . . . . . . . 6
	4.1 Router Advertisement message . . . . . . . . . . . . . . . 6		4.1 Router Advertisement message . . . . . . . . . . . . . . . 6
	4.2 Tree Information Option . . . . . . . . . . . . . . . . . 6		4.2 Tree Information Option . . . . . . . . . . . . . . . . . 7
	5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1 tree selection . . . . . . . . . . . . . . . . . . . . . . 9		5.1 tree selection . . . . . . . . . . . . . . . . . . . . . . 11
	5.2 Subtree mobility . . . . . . . . . . . . . . . . . . . . . 10		5.2 Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 11
	5.3 Tree Hop Timer . . . . . . . . . . . . . . . . . . . . . . 10		5.3 DRL entries states and stability . . . . . . . . . . . . . 11
	5.4 Collisions and stability . . . . . . . . . . . . . . . . . 11		5.3.1 Held-Up . . . . . . . . . . . . . . . . . . . . . . . 12
	5.4.1 Hold down . . . . . . . . . . . . . . . . . . . . . . 12		5.3.2 Held-Down . . . . . . . . . . . . . . . . . . . . . . 13
	5.4.2 Instability . . . . . . . . . . . . . . . . . . . . . 12		5.3.3 Collision . . . . . . . . . . . . . . . . . . . . . . 13
	5.4.3 Collision . . . . . . . . . . . . . . . . . . . . . . 12		5.3.4 Instability . . . . . . . . . . . . . . . . . . . . . 14
	5.5 Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 13		5.4 Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 14
	6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			8.1 Changes from version 00 to 01 . . . . . . . . . . . . . . 16
			8.2 Changes from version 01 to 02 . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
			10.1 Normative Reference . . . . . . . . . . . . . . . . . . . 17
			10.2 Informative Reference . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
			Intellectual Property and Copyright Statements . . . . . . . . 19
	1. Introduction		1. Introduction
	As per Nemo Basic support, a Mobile Router autoconfigures a single		As per Nemo Basic support [4], a Mobile Router autoconfigures a
	Care of Address to register to its Home Agent and terminate its MR-HA		single Care of Address (CoA) to register to its Home Agent and
	tunnel. That CoA is the MR's point of attachment to the nested Nemo.		terminate its Mobile Router-Home Agent tunnel. That Care of Address
			is the Mobile Router point of attachment to the nested Nemo.
	Consequently, if loops are avoided, the nested Nemo assumes the shape		Consequently, if loops are avoided, the nested Nemo assumes the shape
	of a tree. The nodes of the tree are Mobile Routers, the root is		of a tree. The nodes of the tree are Mobile Routers, the root is
	either a fixed or a Mobile Router, called in the latter case the root		either a fixed or a Mobile Router, called in the latter case the root
	Mobile Router in NEMO terminology [6]. The leaves are mobile or		Mobile Router in NEMO terminology [6]. The leaves are mobile or
	fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and		fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and
	Visiting Mobile Nodes in the NEMO terminology.		Visiting Mobile Nodes in the NEMO terminology.
	This paper provides (1) a minimum extension to IPv6 Neighbour		This paper provides (1) a minimum extension to IPv6 Neighbor
	Discovery Router Advertisements in order to ensure that Mobile		Discovery Router Advertisements in order to ensure that Mobile
	Routers attaching to one another actually avoid loops and end up		Routers attaching to one another actually avoid loops and end up
	forming a tree, and (2) the minimum common part of all MR algorithms		forming a tree, and (2) the minimum common part of all Mobile Router
	that is required to ensure that whatever their specific decisions,		algorithms that is required to ensure that whatever their specific
	loops between MRs will be avoided.		decisions, loops between Mobile Routers will be avoided.
	The method is based on an autonomous decision by each MR with no		The method is based on an autonomous decision by each Mobile Router
	global state convergence such as a MANET proactive routing protocol.		with no global state convergence such as a MANET proactive routing
	In fact, MRs may make different decisions from a same input, based on		protocol. In fact, Mobile Routers may make different decisions from
	their own configuration and their own algorithms.		a same input, based on their own configuration and their own
			algorithms.
	In order to build trees of Mobile Routers, we propose an extension to		In order to build trees of Mobile Routers, we propose an extension to
	the ICMP Router Advertisement (RA) message, the Tree Information		the ICMP Router Advertisement (RA) message, the Tree Information
	Option (TIO). The RA/TIO allows MRs to advertise the tree they		Option (TIO). The RA-TIO allows Mobile Routers to advertise the tree
	belong to, and to select and move to the best location within the		they belong to, and to select and move to the best location within
	available trees. MRs propagate the TIO down the tree, updating some		the available trees. Mobile Routers propagate the TIO down the tree,
	metrics such as the tree depth, leaving alone root information such		updating some metrics such as the tree depth, leaving alone root
	as the tree identifier, and sending the result in RAs over the		information such as the tree identifier, and sending the result in
	ingress interfaces.		RAs over the ingress interfaces.
	2. Terms and Abbreviations		2. Terms and Abbreviations
	This document assumes that the reader is familiar with Mobile IPv6 as		This document assumes that the reader is familiar with Mobile IPv6 as
	defined in [3] and with the concept of Mobile Router defined in the		defined in [3] and with the concept of Mobile Router defined in the
	Nemo terminology document [6].		Nemo terminology document [6].
	For the needs of this paper, the following new definitions are		For the needs of this paper, the following new definitions are
	introduced:		introduced:
	Nemo Clusterhead: The root of a tree of mobile routers. When the		Nemo clusterhead: The root of a tree of mobile routers. When the
	tree of Mobile Routers is attached to the infrastructure, the		tree of Mobile Routers is attached to the infrastructure, the
	fixed Access Router may act as cluster head if it supports the		fixed Access Router may act as cluster head if it supports the
	Tree Information Option described in this document. If it does		Tree Information Option described in this document. If it does
	not, then the Clusterhead coincides with the root MR in NEMO		not, then the clusterhead coincides with the root Mobile Router in
	terminology. A clusterhead is elected even when the tree is not		NEMO terminology. A clusterhead is elected even when the tree is
	attached to the infrastructuture. A stand-alone MR is a		not attached to the infrastructure. A stand-alone Mobile Router
	Clusterhead.		is a clusterhead.
	Floating Tree: A Nested Nemo which Clusterhead is a MR that is not		Floating Tree: A Nested Nemo which clusterhead is a Mobile Router
	attached to an AR.		that is not attached to an Access Router.
	Grounded Tree: A Nested Nemo whose Clusterhead is attached to the		Grounded Tree: A Nested Nemo whose clusterhead is attached to the
	infrastructure. In other words, the clusterhead is either a fixed		infrastructure. In other words, the clusterhead is either a fixed
	router that supports RA/TIO or is a MR which attachment router is		router that supports Router Advertisement - Tree Information
	a fixed router that does not support RA/TIO.		Option or is a Mobile Router which attachment router is a fixed
			router that does not support Router Advertisement - Tree
			Information Option.
	Mobile Access Router: A Mobile Router that provides Access Router		Mobile Access Router: A Mobile Router that provides Access Router
	services to other MRs.		services to other Mobile Routers.
	Attachment Router: The Router that is selected as Access Router by a		Attachment Router: The Router that is selected as Access Router by a
	Mobile Router, making it its parent in the nested NEMO tree.		Mobile Router, making it its parent in the nested NEMO tree.
	Propagation: The action by a Mobile Router that consists in receiving		Propagation: The action by a Mobile Router that consists in receiving
	a RA/TIO from its Attachment Router, recomputing a few specific		a Router Advertisement - Tree Information Option from its
	fields, removing unknown suboption, and appending the resulting		Attachment Router, recomputing a few specific fields, removing
	TIO to RAs sent over the ingress interfaces.		unknown suboption, and appending the resulting TIO to RAs sent
			over the ingress interfaces.
	3. Motivations		3. Motivations
	3.1 Multihomed nested mobile network		3.1 Multi-Homed nested mobile network
	A nested mobile network that is made of multiple MRs having a direct		A nested mobile network that is made of multiple Mobile Routers
	connection to the Internet is said to be multihomed. Multihoming in		having a direct connection to the Internet is said to be multi-homed.
	Nemo offers useful properties to MNNs. The NEMO multihoming issues		Multihoming in Nemo offers useful properties to Mobile Network Nodes.
	[8] draft lists potential multihomed configurations for Nemo and		The NEMO multihoming issues [9] draft lists potential multi-homed
	explains the different problems and advantages that some		configurations for Nemo and explains the different problems and
	configurations may introduce. Multihoming offers three main		advantages that some configurations may introduce. Multihoming
	abilities to the Nemo: it allows route recovery on failure,		offers three main abilities to the Nemo: it allows route recovery on
	redundancy and load-sharing between MRs (or between MRs'interfaces).		failure, redundancy and load-sharing between Mobile Routers (or
	However, for the moment there are no requirements nor protocol		between interfaces of a given Mobile Router). However, for the
	defining how to use several egress interfaces inside a Nemo.		moment, there is no requirements nor protocol that would define in
			interaction between several egress interfaces inside a Nemo.
	In a nested Nemo, the hierarchy of MRs increases the complexity of		In a nested Nemo, the hierarchy of Mobile Routers increases the
	the route and/or router selection for MNNs. Each level of a Nemo		complexity of the route and/or router selection for Mobile Network
	implies the usage of a new tunnel between the MR and its home agent.		Nodes. Each level of a Nemo implies the usage of a new tunnel
	Thus if a MNN connects to a sub-Nemo which is also a sub-Nemo,		between the Mobile Router and its home agent. Thus if a Mobile
	packets from the MNN will be encapsulated three times.		Network Node connects to a sub-Nemo which is also a sub-Nemo, packets
			from the Mobile Network Node will be encapsulated three times.
	When the Nemo where the MN is connected to is multihomed, the MN may		When the Nemo where the MN is connected to is multi-homed, the MN may
	have the choice between several AR to be its default router.		have the choice between several Attachment Router to be its default
	Reference [9] introduces new options in Router Advertisement to allow		router. Reference [7] introduces new options in Router Advertisement
	any node on a link to choose between several routers. This option		to allow any node on a link to choose between several routers. This
	mainly consists of a 2-bits flag that indicates the preference of the		option mainly consists of a 2-bits flag that indicates the preference
	router (low, medium or high). Furthermore, the same flag can be set		of the router (low, medium or high). Furthermore, the same flag can
	in the Route Information option indicating the preference of a		be set in the Route Information option indicating the preference of a
	specific prefix. Therefore, any node can determine its best default		specific prefix. Therefore, any node can determine its best default
	router(s) according to a given destination and its best router for		router(s) according to a given destination and its best router for
	default, which will be used by default.		default, which will be used by default.
	However this preference is only useful in a flat topology; It gives a		However this preference is only useful in a flat topology; It gives a
	way to the node to choose between different access routers		way to the node to choose between different attachment routers
	advertising prefixes on the node link. But if the node is inside a		advertising prefixes on the node link. But if the node is inside a
	hierarchical topology (some access routers are not at the same level)		hierarchical topology the node can not learn the depth of each
	the node can not learn the level of each access router.		attachment router, and might not select the most efficient path.
	One of the usage of the new option introduced in this document is to		One of the usage of the new option introduced in this document is to
	distribute information on the hierarchy of MRs. This information can		distribute information on the hierarchy of Mobile Routers. This
	be distributed to ARs, MRs and MNNs as well in order to allow better		information can be distributed to Attachment Routers, Mobile Routers
	route selection and to increase the knowledge of the Nemo topology on		and Mobile Network Nodes as well in order to allow better route
	each node.		selection and to increase the knowledge of the Nemo topology on each
			node.
	3.2 Loops in nested Nemo		3.2 Loops in nested Nemo
	When several MRs attach to each other to form a nested Nemo, loops		When several Mobile Routers attach to each other to form a nested
	can be created if they are not explicitely avoided. In the simplest		Nemo, loops can be created if they are not explicitly avoided. In
	case, when egress and ingress interfaces of an MR are all wireless, a		the simplest case, when egress and ingress interfaces of an Mobile
	mobile router may be listening to Router Advertisement from its own		Router are all wireless, a mobile router may be listening to Router
	ingress interface, creating a confliction problem. In the general		Advertisement from its own ingress interface, creating a confliction
	case, arbitrary attachment of MRs will form graphs that are not		problem. In the general case, arbitrary attachment of Mobile Routers
	exempt of loops. For instance: Assume a nested Nemo where MR1 is		will form graphs that are not exempt of loops. For instance: Assume
	connected to the infrastructure, and MR3 is attached to MR2. Say		a nested Nemo where Mobile Router1 is connected to the
	that MR2 can hear both MR3 and MR1 over its wireless egress		infrastructure, and Mobile Router3 is attached to Mobile Router2.
	interface. If MR2 select MR1, the connectivity to the infrastruture		Say that Mobile Router2 can hear both Mobile Router3 and Mobile
	is provided for all. But if MR2 selects MR3, MR2 and MR3 end up		Router1 over its wireless egress interface. If Mobile Router2 select
	forming a loop and are disconnected from their Home Agents.		Mobile Router1, the connectivity to the infrastructure is provided
			for all. But if Mobile Router2 selects Mobile Router3, Mobile
			Router2 and Mobile Router3 end up forming a loop and are disconnected
			from their Home Agents.
	With Nemo basic support, a MR uses a single primary CareOf to attach		With Nemo basic support, a Mobile Router uses a single primary Care
	to the nested structure. As a result, if loops are avoided, the		Of Address to attach to the nested structure. As a result, if loops
	nested NEMO end up forming a tree. It is beneficial to be able to		are avoided, the nested NEMO end up forming a tree. It is beneficial
	form that tree in an optimum fashion for a given set of metrics such		to be able to form that tree in an optimum fashion for a given set of
	as tree depth.		metrics such as tree depth.
	The shape of a nested Nemo may change rapidly due to MRs movement.		The shape of a nested Nemo may change rapidly due to Mobile Routers
	It is thus impractical to expect each MR to be able to maintain		movement. It is thus impractical to expect each Mobile Router to be
	states about the whole tree structure in a link state fashion. On		able to maintain states about the whole tree structure in a link
	the contrary, it is also beneficial to allow each MR to make its own		state fashion. On the contrary, it is also beneficial to allow each
	independent selection based on a minimum information about its		Mobile Router to make its own independent selection based on a
	immediate neighbors, in order to reestablish the tree quickly upon		minimum information about its immediate neighbors, in order to
	erratic movements.		reestablish the tree quickly upon erratic movements.
	Each MR should be able to make its own attachment router selection		Each Mobile Router should be able to make its own attachment router
	based on its own condition (eg battery level), its own set of		selection based on its own condition (eg battery level), its own set
	constraints that may not apply to other MRs in the tree, and in		of constraints that may not apply to other Mobile Routers in the
	general its own algorithm. As a result, the standardization effort		tree, and in general its own algorithm. As a result, the
	should concentrate on a common minimum set of rules that must be		standardization effort should concentrate on a common minimum set of
	common to all MRs in order to prevent routing loops in the nested		rules that must be common to all Mobile Routers in order to prevent
	NEMO while leaving MRs independent in their AR selection algorithms.		routing loops in the nested NEMO while leaving Mobile Routers
			independent in their Attachment Router selection algorithms.
	4. Router Advertisement extensions		4. Router Advertisement extensions
	New extensions of Router Advertisement are proposed to distribute the		New extensions of Router Advertisement are proposed to distribute the
	knowledge of the MR hierarchy inside a nested Nemo. These extensions		knowledge of the Mobile Router hierarchy inside a nested Nemo. These
	are defined in different options/sub-options: a flag bit from the		extensions are defined in different options/sub-options: a flag bit
	reserved flag field of Router Advertisement message is used to		from the reserved flag field of Router Advertisement message is used
	indicate whether the sending router is a MR or not; a new option is		to indicate whether the sending router is a Mobile Router or not; a
	defined to transport minimum information on the tree to avoid loops		new option is defined to transport minimum information on the tree to
	generation;		avoid loops generation;
	4.1 Router Advertisement message		4.1 Router Advertisement message
	We propose to use a reserved flag of the Router Advertisement message		We propose to use a reserved flag of the Router Advertisement message
	to inform whether the sending router is a MR or not.		to inform whether the sending router is a Mobile Router or not.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |		| Cur Hop Limit |M|O|H|N|Reservd| Router Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Time |		| Reachable Time |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Retrans Timer |		| Retrans Timer |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options ...		| Options ...
	+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-
			Figure 1: Router Advertisement
	Nemo enabled router (N)		Nemo enabled router (N)
	The Nemo enabled router (N) bit is set when the sending router is a		The Nemo enabled router (N) bit is set when the sending router is a
	Mobile Router.		Mobile Router.
	4.2 Tree Information Option		4.2 Tree Information Option
	The following option regroups the minimum information that allows a		The following option regroups the minimum information that allows a
	MR to discover a tree and select its point of attachment while		Mobile Router to discover a tree and select its point of attachment
	avoiding loop generation. It can also be used by MNNs to select		while avoiding loop generation. It can also be used by Mobile
	their best default router. If the default router of a non-MR sends		Network Nodes to select their best default router. If the default
	Router Advertisements with a tree discovery option, the non-MR MUST		router of a non-Mobile Router sends Router Advertisements with a tree
	set the N flag of its own Router Advertisement to 0 and copy the Tree		discovery option, the non-Mobile Router MUST set the N flag of its
	Discovery Option in its own Router Advertisement.		own Router Advertisement to 0 and copy the Tree Discovery Option in
			its own Router Advertisement.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |G|H| Reserved |		| Type | Length |G|H| Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Preference | BootTimeRandom |		| TreePref. | Preference | BootTimeRandom |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TreeDepth | TreePref. | TreeDelay |		| TreeDepth | Reserved | TreeDelay |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| PathDigest |		| PathDigest |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| TreeID |		| TreeID |
	+ +		+ +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| sub-option(s)...		| sub-option(s)...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. Tree Information Option		Figure 2: Tree Information Option
	Type 8-bit unsigned integer set to 10 by the Clusterhead.		Type 8-bit unsigned integer set to 10 by the clusterhead. Value is
			"TBD".
	Length 8-bit unsigned integer set to 4. The length of the option		Length 8-bit unsigned integer set to 4. The length of the option
	(including the type and length fields) in units of 8 octets.		(including the type and length fields) in units of 8 octets.
	Grounded (G) The Grounded (G) flag is set when the Clusterhead is		Grounded (G) The Grounded (G) flag is set when the clusterhead is
	attached to a fixed network infrastructure (such as the Internet).		attached to a fixed network infrastructure (such as the Internet).
	Home (H) The Home (H) flag is set when the Clusterhead is attached to		Home (H) The Home (H) flag is set when the clusterhead is attached to
	its home network.		its home network.
	Reserved 16-bit unsigned integer set to 0 by the Clusterhead.		Reserved 16-bit unsigned integer set to 0 by the clusterhead.
			TreePreference 8-bit unsigned integer set by the clusterhead to its
			preference and unchanged at propagation. Default is 0 (lowest
			preference).
	Preference The administrative preference of that (mobile) Access		Preference The administrative preference of that (mobile) Access
	Router. Default is 0. 255 is the highest possible preference.		Router. Default is 0. 255 is the highest possible preference.
	Set by each MR at propagation time.		Set by each Mobile Router at propagation time.
	BootTimeRandom A random value computed at boot time and recomputed in		BootTimeRandom A random value computed at boot time and recomputed in
	case of a duplication with another AR. The concatenation of the		case of a duplication with another Attachment Router. The
	Preference and the BootTimeRandom is a 32-bit extended preference		concatenation of the Preference and the BootTimeRandom is a 32-bit
	that is used to resolve collisions. It is set by each MR at		extended preference that is used to resolve collisions. It is set
	propagation time.		by each Mobile Router at propagation time.
	TreeDepth 8-bit unsigned integer. The tree depth of the clusterhead		TreeDepth 8-bit unsigned integer. The tree depth of the clusterhead
	is 0 if it is a fixed router and 1 if it is a Mobile Router. The		is 0 if it is a fixed router and 1 if it is a Mobile Router. The
	tree Depth of a tree Node is the depth of its attachment router as		tree Depth of a tree Node is the depth of its attachment router as
	received in a TIO, incremented by one. All nodes in the tree		received in a TIO, incremented by one. All nodes in the tree
	advertise their tree depth in the Tree Information Options that		advertise their tree depth in the Tree Information Options that
	they append to the RA messages over their ingress interfaces as		they append to the RA messages over their ingress interfaces as
	part of the propagation process.		part of the propagation process.
	TreePreference 8-bit unsigned integer set by the Clusterhead to its		TreeDelay 16-bit unsigned integer set by the clusterhead indicating
	preference and unchanged at propagation. Default is 0 (lowest
	preference).
	TreeDelay 16-bit unsigned integer set by the Clusterhead indicating
	the delay before changing the tree configuration, in milliseconds.		the delay before changing the tree configuration, in milliseconds.
	A default value is 128ms. It is expected to be an order of		A default value is 128ms. It is expected to be an order of
	magnitude smaller than the RA-interval so if the clusterhead has a		magnitude smaller than the RA-interval so if the clusterhead has a
	sub-second RA-interval, the Tree delay may be shorter than 100ms.		sub-second RA-interval, the Tree delay may be shorter than 100ms.
	It is also expected to be an order of magnitude longer than the		It is also expected to be an order of magnitude longer than the
	typical propagation delay inside the nested Nemo.		typical propagation delay inside the nested Nemo.
	PathDigest 32-bit unsigned integer CRC, updated by each MR. This is		PathDigest 32-bit unsigned integer CRC, updated by each Mobile
	the result of a CRC-32c computation on a bit string obtained by		Router. This is the result of a CRC-32c computation on a bit
	appending the received value and the MR Care of Address.		string obtained by appending the received value and the Mobile
	Clusterheads use a 'previous value' of zeroes to initially set the		Router Care of Address. clusterheads use a 'previous value' of
	PathDigest.		zeroes to initially set the PathDigest.
	TreeID 128-bit unsigned integer which uniquely identify a tree set by		TreeID 128-bit unsigned integer which uniquely identify a tree. This
	the Clusterhead. The global IPv6 home address of the Clusterhead		value is set by the clusterhead. The global IPv6 home address of
	can be used.		the clusterhead can be used.
			The following values MUST not change during the propagation of the
			TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and
			TreeID. All other fields of the TIO are updated at each hop of the
			propagation.
	5. Tree Discovery		5. Tree Discovery
	Here follows a set of rules and definitions that MUST be followed be		Here follows a set of rules and definitions that MUST be followed by
	all Mobile Routers:		all Mobile Routers:
	1. An MR that is not attached to an AR is the Nemo Clusterhead of		1. An Mobile Router that is not attached to an Attachment Router is
	its own, floating tree.		the Nemo clusterhead of its own floating tree. It's depth is 1.
	2. An MR that is attached to an AR that does not support TIO, is the		2. An Mobile Router that is attached to an Attachment Router that
	clusterhead of its own, grounded tree.		does not support TIO, is the clusterhead of its own grounded
			tree. It's depth is 1.
	3. A router sending a RA without TIO is considered a grounded AR at		3. A router sending a RA without TIO is considered a grounded
	depth 0. Thus, a MR that attaches to an AR that does not include		Attachment Router at depth 0.
	a TIO in its RA becomes a Clusterhead of depth 1.
	4. The Nemo ClusterHead of a tree exposes the tree in the RA/TIO and		4. The Nemo clusterhead of a tree exposes the tree in the Router
	MRs propagate the TIO down the tree with the RAs that they		Advertisement - Tree Information Option and Mobile Routers
	forward over their ingress links.		propagate the TIO down the tree with the RAs that they forward
			over their ingress links.
	5. An MR that is already part of a tree MAY move at any time and		5. An Mobile Router that is already part of a tree MAY move at any
	with no delay in order to get closer to the clusterhead of its		time and with no delay in order to get closer to the clusterhead
	current tree - i.e. in order to reduce its own tree depth. But		of its current tree - i.e. in order to reduce its own tree depth.
	an MR MUST NOT move down the tree that it is attached to. MRs		But an Mobile Router MUST NOT move down the tree that it is
	MUST ignore RAs that are received from other routers located		attached to. Mobile Routers MUST ignore RAs that are received
	deeper or at the same depth within the same tree.		from other routers located deeper or at the same depth within the
			same tree.
	6. An MR may move from its current tree into any different tree at		6. An Mobile Router may move from its current tree into any
	any time and whatever the depth its reaches in the new tree, but		different tree at any time and whatever the depth its reaches in
	it may have to wait for a Tree Hop timer to elapse in order to do		the new tree, but it may have to wait for a Tree Hop timer to
	so. The MR will join that other tree if it is more preferable		elapse in order to do so. The Mobile Router will join that other
	for reasons of connectivity, configured preference, size,		tree if it is more preferable for reasons of connectivity,
	security, bandwidth, tree depth, or whatever metrics the MR cares		configured preference, size, security, bandwidth, tree depth, or
	to use.		whatever metrics the Mobile Router cares to use.
	7. If a MR has selected a new attachment router but has not moved		7. If a Mobile Router has selected a new attachment router but has
	yet (because it is waiting for Tree Hop timer to elapse), the MR		not moved yet (because it is waiting for Tree Hop timer to
	is unstable and refrains from sending RATIOs.		elapse), the Mobile Router is unstable and refrains from sending
			Router Advertisement - Tree Information Options.
	8. When an MR joins a tree, moves within its tree, or when it		8. When an Mobile Router joins a tree, moves within its tree, or
	receives a modified TIO from its current access router, the MR		when it receives a modified TIO from its current attachment
	sends an unsolicited Router Advertisement message on all its		router, the Mobile Router sends an unsolicited Router
	mobile networks (i.e. all its ingress interfaces). The RA		Advertisement message on all its mobile networks (i.e. all its
	contains a TIO that propagates the new tree information. At the		ingress interfaces). The RA contains a TIO that propagates the
	same time, the MR MAY send a Binding Update to its home agent or		new tree information. At the same time, the Mobile Router MAY
	a local proxy of some sort, because the tree it is attached to		send a Binding Update to its home agent or a local proxy of some
	has changed. If the MR fails to reach its HA, it MAY attempt to		sort, because the tree it is attached to has changed. If the
	roll back the movement or to retry the HA discovery procedure.		Mobile Router fails to reach its Home Agent, it MAY attempt to
			roll back the movement or to retry the Home Agent discovery
			procedure.
	9. This allows the new higher parts of the tree to take place first		9. This allows the new higher parts of the tree to take place first
	eventually dragging their sub-tree with them, and allowing		eventually dragging their sub-tree with them, and allowing
	stepped sub-tree reconfigurations, limiting relative movements.		stepped sub-tree reconfigurations, limiting relative movements.
	5.1 tree selection		5.1 tree selection
	The tree selection is implementation and algorithm dependent. In		The tree selection is implementation and algorithm dependent. In
	order to limit erratic movements, and all metrics being equal, MRs		order to limit erratic movements, and all metrics being equal, Mobile
	SHOULD stick to their previous selection. Also, MRs SHOULD provide a		Routers SHOULD stick to their previous selection. Also, Mobile
	mean to filter out candidate ARs whose availability is detected as		Routers SHOULD provide a mean to filter out candidate Attachment
	fluctuating, at least when more stable choices are available. For		Routers whose availability is detected as fluctuating, at least when
	instance, the MR MAY place the failed AR in a Hold Down mode that		more stable choices are available. For instance, the Mobile Router
	ensures that the AR will not be reused for a given period of time.		MAY place the failed Attachment Router in a Hold Down mode that
			ensures that the Attachment Router will not be reused for a given
			period of time.
	The known trees are associated with the AR that advertises them and		The known trees are associated with the Attachment Router that
	kept in an ordered list, per order of preference, by extending the		advertises them and kept in a list by extending the Default Router
	Default Router List. DRL entries are extended to store the		List. DRL entries are extended to store the information received
	information received from the last TIO, and a timer ID -and related		from the last TIO. These entries are managed by states and timers
	data- to delay the reaction to a better RA message, the tree hop		described in the next section.
	timer, as described in the next section.
	When connection to a fixed network is not possible or preferable for		When connection to a fixed network is not possible or preferable for
	security or other reasons, scattered trees should aggregate as much		security or other reasons, scattered trees should aggregate as much
	as possible into larger trees in order to allow inner connectivity.		as possible into larger trees in order to allow inner connectivity.
	How to balance these trees is implementation dependent, and MAY use a		How to balance these trees is implementation dependent, and MAY use a
	specific visitor-counter suboption in the TIO.		specific visitor-counter suboption in the TIO.
	5.2 Subtree mobility		5.2 Sub-tree mobility
	It might be perceived as beneficial for a subtree to move as a whole.		It might be perceived as beneficial for a sub-tree to move as a
	The way it would work is for a MR to stay root-MR even if itself is		whole. The way it would work is for a Mobile Router to stay root-
	attached into a parent tree. But the loop avoidance is based on the		Mobile Router even if itself is attached into a parent tree. But the
	knowledge of the tree that the MR visit, preventing a MR to move down		loop avoidance is based on the knowledge of the tree that the Mobile
	a same tree. So without additional support, tree-level loops could		Router visit, preventing a Mobile Router to move down a same tree.
	form.		So without additional support, tree-level loops could form.
	To avoid this, it is possible to add a path vector suboption to the		To avoid this, it is possible to add a path vector suboption to the
	TIO that reflects the nesting of trees. If a root-MR joins a parent		TIO that reflects the nesting of trees. If a root-Mobile Router
	tree, then it needs to add its treeID to the path vector, but it can		joins a parent tree, then it needs to add its treeID to the path
	not join if the treeID is already listed.		vector, but it can not join if the treeID is already listed.
	A specific case is the root-MR of a tree that attaches to a fixed		A specific case is the root-Mobile Router of a tree that attaches to
	Access Router. That root-MR might omit to consider a TIO that comes		a fixed Access Router. That root-Mobile Router might omit to
	from the new AR and decide to stay root, in order to keep the tree		consider a TIO that comes from the new Attachment Router and decide
	consistency from the nested MRs standpoint. This does not create		to stay root, in order to keep the tree consistency from the nested
	loops, even if the path vector is not present		Mobile Routers standpoint. This does not create loops, even if the
			path vector is not present
	5.3 Tree Hop Timer		5.3 DRL entries states and stability
	The tree Hop timer serves 2 purposes:		Attachment routers in the DRL may or may not be usable for roaming
			depending on runtime conditions. The following states are defined:
	Delay the reattachment of a subtree that has been forced to		Current This Attachment Router is used for roaming
	detach. This allows to make sure that when a subtree has
	detached, the RATIO that is initiated by the new clusterhead has
	spread down the subtree so that two different trees have formed.
	Limit RA/TIO storms when two trees collide. The idea is that		Candidate This Attachment Router can be used for roaming.
	between the nodes from tree A that wish to move to tree B, those
	that see the highest place in tree B will move first and advertise
	their new locations before other nodes from tree A actually move.
	A new tree is discovered upon a router advertisement message with or		Held-Up This Attachment Router can not be used till tree hop timer
	without a RA/TIO. The MR joins the tree by selecting the source of		elapses. This does not occur for a fixed Attachment Router that
	the RA message as its access router (default gateway) and propagating		does not send a TIO since the tree delay is null in that case.
	the TIO accordingly.
	When a new tree is discovered, the candidate AR that advertises the		Held-Down This Attachment Router can not be used till hold down timer
	new tree is placed in a held up state for the duration of a Tree Hop		elapses. At the end of the hold-down period, the router is
	timer. If the new AR is more preferable than the current one, the MR		removed from the DRL, and will be reinserted if it appears again
	expects to jump and becomes unstable.		with a RA.
	A MR that is unstable may discover other ARs from the same new tree		Collision This Attachment Router can not be used till its next RA.
	during the instability phase. It needs to start a new Tree Hop timer
	for all these. The first timer that elapses for a given new tree
	clears them all for that tree, allowing the MR to jump to the highest
	position available in the new tree.
	The duration of the Tree Hop timer depends on the tree delay of the		5.3.1 Held-Up
	new tree and on the depth of AR that triggers it:
	(AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It		This state is managed by the tree Hop timer, it serves 2 purposes:
	is randomized in order to limit collisions and synchronizations.
	5.4 Collisions and stability		Delay the reattachment of a sub-tree that has been forced to
			detach. This allows to make sure that when a sub-tree has
			detached, the Router Advertisement - Tree Information Option that
			is initiated by the new clusterhead has spread down the sub-tree
			so that two different trees have formed.
	Attachment routers in the DRL may or may not be usable for roaming		Limit Router Advertisement - Tree Information Option storms when
	depending on runtime conditions. The following states are defined:		two trees collide. The idea is that between the nodes from tree A
			that wish to move to tree B, those that see the highest place in
			tree B will move first and advertise their new locations before
			other nodes from tree A actually move.
	Current This AR is used for roaming		A new tree is discovered upon a router advertisement message with or
			without a Router Advertisement - Tree Information Option. The Mobile
			Router joins the tree by selecting the source of the RA message as
			its attachment router (default gateway) and propagating the TIO
			accordingly.
	Candidate This AR can be used for roaming. Typically, an initial		When a new tree is discovered, the candidate Attachment Router that
	held-up period is over but the candidate is not preferred over the		advertises the new tree is placed in a held up state for the duration
	current AR.		of a Tree Hop timer. If the new Attachment Router is more preferable
			than the current one, the Mobile Router expects to jump and becomes
			unstable.
	Held-Up This AR can not be used till tree hop timer elapses. This		A Mobile Router that is unstable may discover other Attachment
	does not occur for a fixed AR that does not send a TIO since the		Routers from the same new tree during the instability phase. It
	tree delay is null in that case..		needs to start a new Tree Hop timer for all these. The first timer
			that elapses for a given new tree clears them all for that tree,
			allowing the Mobile Router to jump to the highest position available
			in the new tree.
	Held-Down This AR can not be used till hold down timer elapses. At		The duration of the Tree Hop timer depends on the tree delay of the
	the end of the hold-down period, the router is removed from the		new tree and on the depth of Attachment Router that triggers it:
	DRL, and will be reinserted if it appears again with a RA.
	Collision This AR can not be used till its next Router Advertisement		(AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It
			is randomized in order to limit collisions and synchronizations.
	5.4.1 Hold down		5.3.2 Held-Down
	When a router is 'removed' from the Default Router List, it is		When a router is 'removed' from the Default Router List, it is
	actually held down for a hold down timer period, in order to prevent		actually held down for a hold down timer period, in order to prevent
	flapping. This happens when an AR disappears (upon expiration		flapping. This happens when an Attachment Router disappears (upon
	timer), and when an AR is tried but can not reach the HA (upon		expiration timer), and when an Attachment Router is tried but can not
	expiration of another AR, or upon tree hop for that AR).		reach the Home Agent (upon expiration of another Attachment Router,
			or upon tree hop for that Attachment Router).
	An Attachment Router that is held down is not considered for the		An Attachment Router that is held down is not considered for the
	purpose of roaming. When the hold down timer elapses, the AR is		purpose of roaming. When the hold down timer elapses, the Attachment
	removed from the DRL.		Router is removed from the DRL.
	5.4.2 Instability
	A MR is instable when a Held-Up AR is placed before the current AR.
	Instability is transient (In the order of tree hop timers). When a
	MR is instable, it MUST NOT send RAs with TIO. This avoids loops
	when MR A wishes to attach to MR B and MR B wishes to attach to MR A.
	Unless RA cross (which is a short window of time), a MR receives TIO
	from stable ARs, which do not plan to attach to itself, so the MR can
	safely attach to them.
	A MR is instable when it is prepared to move shortly to another AR.
	This happens typically when it discovers a new and more preferred
	candidate AR, for the duration of the tree hop timer. During that
	time, the new candidate is placed in Held-up state. Instability may
	also occur when the current AR is lost and the next best is still
	held up. Instability is resolved when the tree hop timer of all the
	AR (s) causing instability elapse. Such AR is changes state to
	Current or Held-Down.
	5.4.3 Collision		5.3.3 Collision
	A race condition occurs if 2 MRs send RA/TIO at the same time and		A race condition occurs if 2 Mobile Routers send Router Advertisement
	wish to join each other. In order to detect the situation, MRs time		- Tree Information Option at the same time and wish to join each
	stamp the sending of RA/TIO. Any RA/TIO received within a short		other. In order to detect the situation, Mobile Routers time stamp
	media-dependant period introduces a risk. To divide the risk, A		the sending of Router Advertisement - Tree Information Option. Any
	32bits extended preference is added in the TIO. The first byte is		Router Advertisement - Tree Information Option received within a
	the AR own preference (default 0), the rest is a boot time computed		short media-dependant period introduces a risk. To divide the risk,
			A 32bits extended preference is added in the TIO. The first byte is
			the clusterhead preference, then the router own preference (default
			is 0 for both), the remaining 16 bits is a boot time computed
	random.		random.
	A MR that decides to join an AR will do so between (AR depth) and (AR		A Mobile Router that decides to join an Attachment Router will do so
	depth + 1) times the AR tree delay. But since a MR is unstable as		between (Attachment Router depth) and (Attachment Router depth + 1)
	soon as it receives the RA/TIO from the preferred AR, it will		times the Attachment Router tree delay. But since a Mobile Router is
	restrain from sending a RA/TIO between the time it receives the RA		unstable as soon as it receives the Router Advertisement - Tree
	and the time it actually jumps. So the crossing of RA may only		Information Option from the preferred Attachment Router, it will
	happen during the propagation time between the AR and the MR, plus		restrain from sending a Router Advertisement - Tree Information
	some internal queuing and processing time within each machine. It is		Option between the time it receives the RA and the time it actually
			jumps. So the crossing of RA may only happen during the propagation
			time between the Attachment Router and the Mobile Router, plus some
			internal queuing and processing time within each machine. It is
	expected that one tree delay normally covers that interval, but		expected that one tree delay normally covers that interval, but
	ultimately it is up to the implementation and the configuration of		ultimately it is up to the implementation and the configuration of
	the AR to define the duration of risk window.		the Attachment Router to define the duration of risk window.
	There is risk of a collision when a MR receives an RA, for an other		There is risk of a collision when a Mobile Router receives an RA, for
	mobile router that is more preferable than the current AR, within the		an other mobile router that is more preferable than the current
	risk window. In the face of a potential collision, the Mobile Router		Attachment Router, within the risk window. In the face of a
	with the lowest extended preference processes the RA/TIO normally,		potential collision, the Mobile Router with the lowest extended
	while the router with the highest preference places the other in		preference processes the Router Advertisement - Tree Information
	collision state, does not start the tree hop timer, and does not		Option normally, while the router with the highest preference places
	become instable. It is expected that next RAs between the two will		the other in collision state, does not start the tree hop timer, and
	not cross anyway.		does not become instable. It is expected that next RAs between the
			two will not cross anyway.
	5.5 Legacy Routers		5.3.4 Instability
			A Mobile Router is instable when it is prepared to move shortly to
			another Attachment Router. This happens typically when the Mobile
			Router has selected a more preferred candidate Attachment Router and
			has to wait for the tree hop timer to elapse before roaming.
			Instability may also occur when the current Attachment Router is lost
			and the next best is still held up. Instability is resolved when the
			tree hop timer of all the Attachment Router (s) causing instability
			elapse. Such Attachment Router is changes state to Current or Held-
			Down.
			Instability is transient (in the order of tree hop timers). When a
			Mobile Router is unstable, it MUST NOT send RAs with TIO. This
			avoids loops when Mobile Router A wishes to attach to Mobile Router B
			and Mobile Router B wishes to attach to Mobile Router A. Unless RA
			cross (see Collision section), a Mobile Router receives TIO from
			stable Attachment Routers, which do not plan to attach to itself, so
			the Mobile Router can safely attach to them.
			5.4 Legacy Routers
	A legacy router sends its Router Advertisements without a TIO.		A legacy router sends its Router Advertisements without a TIO.
	Consequently, a legacy router can be mistaken for a fixed Access		Consequently, a legacy router can be mistaken for a fixed Access
	Router when it is placed within a nested NEMO structure, and defeat		Router when it is placed within a nested NEMO structure, and defeat
	the loop avoidance mechanism. Consequently, it is important for the		the loop avoidance mechanism. Consequently, it is important for the
	administrator to prevent address autoconfiguration by visiting MRs		administrator to prevent address autoconfiguration by visiting Mobile
	from such a legacy router.		Routers from such a legacy router.
	6. Changes		6. IANA Considerations
	6.1 Changes from version 00 to 01		Section 4.2. requires the definition of a new option to Neighbor
			discovery [1] messages, the Router Advertisement - Tree Information
			Option (RA-TIO). The Router Advertisement - Tree Information Option
			has been assigned the value TBD within the numbering space for IPv6
			Neighbor Discovery Option Formats.
	Added text on subtree mobility from the discussion with Marcelo.		7. Security Considerations
			At the current level of this draft, the TIO bears the security level
			of the RA and the link. Nothing is added to it. A deeper threat
			analysis would be required to eventually propose additional security.
			8. Changes
			8.1 Changes from version 00 to 01
			Added text on sub-tree mobility from the discussion with Marcelo.
	Added text on nested legacy routers from the discussion with		Added text on nested legacy routers from the discussion with
	Marcelo.		Marcelo.
	7. Acknowledgments		8.2 Changes from version 01 to 02
			Improved text on instability
			Changed the formula for the 4 bytes number used in collision
			avoidance
			9. Acknowledgments
	The authors wish to thank Marco Molteni and Patrick Wetterwald		The authors wish to thank Marco Molteni and Patrick Wetterwald
	(cisco) for their participation to this design and the review of the		(cisco) for their participation to this design and the review of the
	document, and Massimo Villari (university of Messina), for his early		document, and Massimo Villari (university of Messina), for his early
	work on simulation and research on the subject. This work is also		work on simulation and research on the subject. This work is also
	based on prior publications, in particular HMRA [7] by Hosik Cho and		based on prior publications, in particular HMRA [8] by Hosik Cho and
	Eun-Kyoung Paik from Seoul National University and other non IETF		Eun-Kyoung Paik from Seoul National University and other non IETF
	publications coauthored with Thierry Ernst and Thomas Noel. Finally,		publications coauthored with Thierry Ernst and Thomas Noel. Finally,
	thanks to Marcelo Bagnulo Braun for his constructive review.		thanks to Marcelo Bagnulo Braun for his constructive review.
	8 References		10. References
	[1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for		10.1 Normative Reference
	IP Version 6 (IPv6)", RFC 2461, December 1998.
			[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
			for IP Version 6 (IPv6)", RFC 2461, December 1998.
	[2] Thomson, S. and T. Narten, "IPv6 Stateless Address		[2] Thomson, S. and T. Narten, "IPv6 Stateless Address
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July		IPv6", RFC 3775, June 2004.
	2003.
	[4] Devarapalli, V., "Network Mobility (NEMO) Basic Support		[4] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
	Protocol", draft-ietf-nemo-basic-support-03 (work in progress),		"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
	June 2004.		January 2005.
	[5] Ernst, T., "Network Mobility Support Goals and Requirements",		[5] Ernst, T., "Network Mobility Support Goals and Requirements",
	draft-ietf-nemo-requirements-02 (work in progress), February		draft-ietf-nemo-requirements-04 (work in progress),
	2004.		February 2005.
	[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",		[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
	draft-ietf-nemo-terminology-01 (work in progress), February		draft-ietf-nemo-terminology-03 (work in progress),
	2004.		February 2005.
	[7] Cho, H., "Hierarchical Mobile Router Advertisement for nested		[7] Draves, R. and D. Thaler, "Default Router Preferences and More-
			Specific Routes", draft-ietf-ipv6-router-selection-07 (work in
			progress), January 2005.
			10.2 Informative Reference
			[8] Cho, H., "Hierarchical Mobile Router Advertisement for nested
	mobile networks", draft-cho-nemo-hmra-00 (work in progress),		mobile networks", draft-cho-nemo-hmra-00 (work in progress),
	January 2004.		January 2004.
	[8] Ernst, T., "Analysis of Multihoming in Network Mobility		[9] Ernst, T., "Analysis of Multihoming in Network Mobility
	Support", draft-ietf-nemo-multihoming-issues-00 (work in		Support", draft-ietf-nemo-multihoming-issues-02 (work in
	progress), July 2004.		progress), February 2005.
	[9] Draves, R. and R. Hinden, "Default Router Preferences and
	More-Specific Routes", draft-ietf-ipv6-router-selection-03 (work
	in progress), December 2003.
	Authors' Addresses		Authors' Addresses
	Pascal Thubert		Pascal Thubert
	Cisco Systems		Cisco Systems
	Village d'Entreprises Green Side		Village d'Entreprises Green Side
	400, Avenue de Roumanille		400, Avenue de Roumanille
	Batiment T3		Batiment T3
	Biot - Sophia Antipolis 06410		Biot - Sophia Antipolis 06410
	FRANCE		FRANCE
	Phone: +33 4 97 23 26 34		Phone: +33 4 97 23 26 34
	EMail: pthubert@cisco.com		Email: pthubert@cisco.com
			Caroline Bontoux
			Fortinet
			Sophia Antipolis
			Biot 06410
			FRANCE
			Email: cbontoux@fortinet.com
	Nicolas Montavont		Nicolas Montavont
	LSIIT - Univerity Louis Pasteur		LSIIT - Univerity Louis Pasteur
	Pole API, bureau C444		Pole API, bureau C444
	Boulevard Sebastien Brant		Boulevard Sebastien Brant
	Illkirch 67400		Illkirch 67400
	FRANCE		FRANCE
	Phone: (33) 3 90 24 45 87		Phone: (33) 3 90 24 45 87
	EMail: montavont@dpt-info.u-strasbg.fr		Email: montavont@dpt-info.u-strasbg.fr
	URI: http://www-r2.u-strasbg.fr/~montavont/		URI: http://www-r2.u-strasbg.fr/~montavont/
	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 Rights 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; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	skipping to change at page 17, line 41 ¶		skipping to change at page 19, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	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. 111 change blocks.
	365 lines changed or deleted		447 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/