< draft-ietf-manet-nhdp-06.txt		draft-ietf-manet-nhdp-07.txt >
	Mobile Ad hoc Networking (MANET) T. Clausen		Mobile Ad hoc Networking (MANET) T. Clausen
	Internet-Draft LIX, Ecole Polytechnique, France		Internet-Draft LIX, Ecole Polytechnique, France
	Intended status: Standards Track C. Dearlove		Intended status: Standards Track C. Dearlove
	Expires: September 11, 2008 BAE Systems Advanced Technology		Expires: January 11, 2009 BAE Systems Advanced Technology
	Centre		Centre
	J. Dean		J. Dean
	Naval Research Laboratory		Naval Research Laboratory
	The OLSRv2 Design Team		The OLSRv2 Design Team
	MANET Working Group		MANET Working Group
	March 10, 2008		July 10, 2008
	MANET Neighborhood Discovery Protocol (NHDP)		MANET Neighborhood Discovery Protocol (NHDP)
	draft-ietf-manet-nhdp-06		draft-ietf-manet-nhdp-07
	Status of This Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 September 11, 2008.		This Internet-Draft will expire on January 11, 2009.
	Abstract		Abstract
	This document describes a 1-hop and symmetric 2-hop neighborhood		This document describes a 1-hop and symmetric 2-hop neighborhood
	discovery protocol (NHDP) for mobile ad hoc networks (MANETs).		discovery protocol (NHDP) for mobile ad hoc networks (MANETs).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Applicability Statement . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Overview and Functioning . . . . . . . . . . . . . . 8		3. Applicability Statement . . . . . . . . . . . . . . . . . . . 8
	4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 9		4. Protocol Overview and Functioning . . . . . . . . . . . . . . 9
	4.2. Information Base Overview . . . . . . . . . . . . . . . . 9		4.1. Nodes and Interfaces . . . . . . . . . . . . . . . . . . . 10
	4.2.1. Local Information Base . . . . . . . . . . . . . . . . 9		4.2. Information Base Overview . . . . . . . . . . . . . . . . 10
	4.2.2. Interface Information Bases . . . . . . . . . . . . . 10		4.2.1. Local Information Base . . . . . . . . . . . . . . . . 10
	4.2.3. Node Information Base . . . . . . . . . . . . . . . . 10		4.2.2. Interface Information Bases . . . . . . . . . . . . . 11
	4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11		4.2.3. Node Information Base . . . . . . . . . . . . . . . . 11
	4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 11		4.3. Signaling Overview . . . . . . . . . . . . . . . . . . . . 12
	4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 11		4.3.1. HELLO Message Generation . . . . . . . . . . . . . . . 12
	4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 12		4.3.2. HELLO Message Content . . . . . . . . . . . . . . . . 12
	4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 13		4.3.3. HELLO Message Processing . . . . . . . . . . . . . . . 13
	5. Protocol Parameters and Constants . . . . . . . . . . . . . . 14		4.4. Link Quality . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 14		5. Protocol Parameters and Constants . . . . . . . . . . . . . . 15
	5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 14		5.1. Interface Parameters . . . . . . . . . . . . . . . . . . . 15
	5.1.2. Information Validity Times . . . . . . . . . . . . . . 15		5.1.1. Message Intervals . . . . . . . . . . . . . . . . . . 15
	5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 16		5.1.2. Information Validity Times . . . . . . . . . . . . . . 16
	5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 17		5.1.3. Link Quality . . . . . . . . . . . . . . . . . . . . . 17
	5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 17		5.1.4. Jitter . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.2.1. Information Validity Time . . . . . . . . . . . . . . 17		5.2. Node Parameters . . . . . . . . . . . . . . . . . . . . . 18
	5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 17		5.2.1. Information Validity Time . . . . . . . . . . . . . . 18
	5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 19		5.3. Parameter Change Constraints . . . . . . . . . . . . . . . 18
	6. Local Information Base . . . . . . . . . . . . . . . . . . . . 20		5.4. Constants . . . . . . . . . . . . . . . . . . . . . . . . 20
	6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 20		6. Local Information Base . . . . . . . . . . . . . . . . . . . . 21
	6.2. Removed Interface Address Set . . . . . . . . . . . . . . 20		6.1. Local Interface Set . . . . . . . . . . . . . . . . . . . 21
	7. Interface Information Base . . . . . . . . . . . . . . . . . . 21		6.2. Removed Interface Address Set . . . . . . . . . . . . . . 21
	7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 21		7. Interface Information Base . . . . . . . . . . . . . . . . . . 22
	7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 22		7.1. Link Set . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8. Node Information Base . . . . . . . . . . . . . . . . . . . . 23		7.2. 2-Hop Set . . . . . . . . . . . . . . . . . . . . . . . . 23
	8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 23		8. Node Information Base . . . . . . . . . . . . . . . . . . . . 24
	8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 23		8.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 24
	9. Local Information Base Changes . . . . . . . . . . . . . . . . 24		8.2. Lost Neighbor Set . . . . . . . . . . . . . . . . . . . . 24
	9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 24		9. Local Information Base Changes . . . . . . . . . . . . . . . . 25
	9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 24		9.1. Adding an Interface . . . . . . . . . . . . . . . . . . . 25
	9.3. Adding an Address to an Interface . . . . . . . . . . . . 25		9.2. Removing an Interface . . . . . . . . . . . . . . . . . . 25
	9.4. Removing an Address from an Interface . . . . . . . . . . 26		9.3. Adding an Address to an Interface . . . . . . . . . . . . 26
	10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 27		9.4. Removing an Address from an Interface . . . . . . . . . . 27
	10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 27		10. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 28
	10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 28		10.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 28
			10.1.1. Address Blocks . . . . . . . . . . . . . . . . . . . . 29
	11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 30		11. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 31
	11.1. HELLO Message Specification . . . . . . . . . . . . . . . 30		11.1. HELLO Message Specification . . . . . . . . . . . . . . . 31
	11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 32		11.2. HELLO Message Transmission . . . . . . . . . . . . . . . . 33
	11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 32		11.2.1. HELLO Message Jitter . . . . . . . . . . . . . . . . . 33
	12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 33		12. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 34
	12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 34		12.1. Updating the Neighbor Set . . . . . . . . . . . . . . . . 35
	12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 35		12.2. Updating the Lost Neighbor Set . . . . . . . . . . . . . . 36
	12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 35		12.3. Updating the Link Set . . . . . . . . . . . . . . . . . . 36
	12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 37		12.4. Updating the 2-Hop Set . . . . . . . . . . . . . . . . . . 38
	13. Other Information Base Changes . . . . . . . . . . . . . . . . 39		13. Other Information Base Changes . . . . . . . . . . . . . . . . 40
	13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 39		13.1. Link Tuple Not Symmetric . . . . . . . . . . . . . . . . . 40
	13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 40		13.2. Link Tuple Symmetric . . . . . . . . . . . . . . . . . . . 41
	13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 41		13.3. Link Tuple Heard Timeout . . . . . . . . . . . . . . . . . 42
	14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 42		14. Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . 43
	14.1. Deployment Without Link Quality . . . . . . . . . . . . . 42		14.1. Deployment Without Link Quality . . . . . . . . . . . . . 43
	14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 42		14.2. Basic Principles of Link Quality . . . . . . . . . . . . . 43
	14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 43		14.3. When Link Quality Changes . . . . . . . . . . . . . . . . 44
	14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 44		14.4. Updating Link Quality . . . . . . . . . . . . . . . . . . 45
	15. Proposed Values for Parameters and Constants . . . . . . . . . 45		15. Proposed Values for Parameters and Constants . . . . . . . . . 46
	15.1. Message Interval Interface Parameters . . . . . . . . . . 45		15.1. Message Interval Interface Parameters . . . . . . . . . . 46
	15.2. Information Validity Time Interface Parameters . . . . . . 45		15.2. Information Validity Time Interface Parameters . . . . . . 46
	15.3. Information Validity Time Node Parameters . . . . . . . . 45		15.3. Information Validity Time Node Parameters . . . . . . . . 46
	15.4. Link Quality Interface Parameters . . . . . . . . . . . . 45		15.4. Link Quality Interface Parameters . . . . . . . . . . . . 46
	15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 45		15.5. Jitter Interface Parameters . . . . . . . . . . . . . . . 46
	15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 46		15.6. Constants . . . . . . . . . . . . . . . . . . . . . . . . 47
	16. Security Considerations . . . . . . . . . . . . . . . . . . . 47		16. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 47		16.1. Invalid HELLO messages . . . . . . . . . . . . . . . . . . 48
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 49		17.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 50
	17.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 49		17.2. Address Block TLV Types . . . . . . . . . . . . . . . . . 50
	17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 50		17.3. LINK_STATUS and OTHER_NEIGHB Values . . . . . . . . . . . 51
	18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51		18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
	18.1. Normative References . . . . . . . . . . . . . . . . . . . 51		18.1. Normative References . . . . . . . . . . . . . . . . . . . 53
	18.2. Informative References . . . . . . . . . . . . . . . . . . 51		18.2. Informative References . . . . . . . . . . . . . . . . . . 53
	Appendix A. Address Block TLV Combinations . . . . . . . . . . . 52		Appendix A. Address Block TLV Combinations . . . . . . . . . . . 54
	Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 53		Appendix B. HELLO Message Example . . . . . . . . . . . . . . . . 55
	Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 56		Appendix C. Constraints . . . . . . . . . . . . . . . . . . . . . 58
	Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 59		Appendix D. Flow and Congestion Control . . . . . . . . . . . . . 61
	Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 60		Appendix E. Contributors . . . . . . . . . . . . . . . . . . . . 62
	Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 61		Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 63
	1. Introduction		1. Introduction
	This document describes a neighborhood discovery protocol (NHDP) for		This document describes a neighborhood discovery protocol (NHDP) for
	a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an		a mobile ad hoc network (MANET) [RFC2501]. This protocol uses an
	exchange of HELLO messages in order that each node can determine the		exchange of HELLO messages in order that each node can determine the
	presence and status of its 1-hop and symmetric 2-hop neighbors.		presence and status of its 1-hop and symmetric 2-hop neighbors.
	Messages are defined as instances of the specification [packetbb].		Messages are defined as instances of the specification [packetbb].
	This neighborhood information is recorded in the form of Information		This neighborhood information is recorded in the form of Information
	skipping to change at page 5, line 5 ¶		skipping to change at page 4, line 27 ¶
	presence of a dynamic network topology.		presence of a dynamic network topology.
	This protocol makes no assumptions about the underlying link layer,		This protocol makes no assumptions about the underlying link layer,
	other than support of link local broadcast or multicast. Link layer		other than support of link local broadcast or multicast. Link layer
	information may be used if available and applicable.		information may be used if available and applicable.
	This protocol is based on the neighborhood discovery process		This protocol is based on the neighborhood discovery process
	contained in the Optimized Link State Routing Protocol (OLSR)		contained in the Optimized Link State Routing Protocol (OLSR)
	[RFC3626].		[RFC3626].
			1.1. Motivation
			MANETs differ from more traditional wired and infrastructure based
			wireless networks, due to their envisioned applicability also over
			more challenging network interfaces (e.g. wireless, lossy, broadcast
			interfaces with moderate and shared bandwidth, hidden and exposed
			terminals and interference from other network interfaces and the
			environment) and in more challenging topological conditions (e.g.
			rapid and unpredictable mobility, dynamic and non-predetermined
			network membership). An approach, often taken by MANET routing
			protocols, is to collect local topological information up to 2 hops,
			in order to, for example, optimize their flooding performance within
			the MANET.
			Due to the properties of wireless transmissions, communication
			between two network interfaces on neighboring nodes may not be bi-
			directional; even if node A is able to receive a packets from node B,
			the converse is not guaranteed to be true. Furthermore, because of
			the localized nature of wireless broadcasts communication, differing
			neighbor sets often exist for differing neighboring nodes within the
			same communications channel. If node A is able to exchange packets
			with node B and node B is able to exchange packets with node C on the
			same interface, this does not guarantee that node A and node C can
			exchange packets directly.
			Nodes in a MANET may have multiple heterogeneous interfaces
			participating in the same MANET routing protocol, each of which with
			the characteristics as described above. Between the same pair of
			nodes more than one distinct communications channel (links) may
			therefore exist, with different properties.
			For MANET routing protocols to correctly identify candidate links for
			inclusion in a routing path, the existence and bi-directionality of
			such distinct links between a node and its neighbors must be
			established and monitored.
			The set of neighbor nodes of a given MANET node may be continuously
			changing, often due to node mobility or due to a changing physical
			environment in which the MANET is located. There are typically no
			signals from lower layers which would enable an IP routing protocol
			to detect and, as appropriate, react to such changes. Yet as such
			changes are can often take place on the order of seconds, requiring
			MANET IP routing protocols to also act rapidly to ensure sufficient
			convergence properties.
			MANET routing protocols often employ relay set reductions in order to
			conserve network capacity when maintaining network-wide topological
			information, with calculation of these reduced relay sets employing
			up to 2-hop information. Such is the case e.g. for [RFC3626].
			The neighborhood discovery protocol specified in this document
			provides continued tracking of neighborhood changes, continued bi-
			directionality tracking of links between neighbors and local
			topological information up to two hops. Combined, this allows a
			MANET routing protocol access to information describing link
			establishment/disappearance, and provides the necessary topological
			information for reduced relay set selection and other purposes.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	The terms "packet", "message", "address", "address block", "TLV", and		The terms "packet", "message", "address", "address block", "TLV", and
	"TLV block" in this document are to be interpreted as described in		"TLV block" in this document are to be interpreted as described in
	[packetbb].		[packetbb].
	Additionally, this document uses the following terminology:		Additionally, this document uses the following terminology:
	Node - A MANET router which implements this neighborhood discovery		Node - A MANET router which implements this neighborhood discovery
	protocol.		protocol.
	Interface - A network device, configured and assigned one or more IP		Interface - A network device, configured and assigned one or more IP
	addresses.		addresses.
	Address - An address, as recorded in the Information Bases specified		Address - An address, as recorded in the Information Bases specified
	by this protocol, and included in HELLO messages generated by this		by this protocol, and included in HELLO messages generated by this
	protocol, may be either an address or an address prefix. These		protocol, may be either an address or an address prefix. The
	can be represented as a single address object in a HELLO message,		exception to this is addresses described as originator addresses;
	as defined by [packetbb]. An address so represented is considered		these must be simple addresses without a prefix length. Non-
	to have a prefix length equal to its length (in bits) when		originator addresses can be represented as a single address object
	considered as an address object, and a similar convention is used		in a HELLO message, as defined by [packetbb]. An address so
	in the Information Bases specified by this protocol. Two		represented is considered to have a prefix length equal to its
	addresses (address objects) are considered equal only if their		length (in bits) when considered as an address object, and a
	prefix lengths are also equal.		similar convention is used in the Information Bases specified by
			this protocol. Two addresses (address objects) are considered
			equal only if their prefix lengths are also equal.
	MANET interface - An interface participating in a MANET and using		MANET interface - An interface participating in a MANET and using
	this neighborhood discovery protocol. A node may have several		this neighborhood discovery protocol. A node may have several
	MANET interfaces.		MANET interfaces.
	Heard - A MANET interface of node X is considered heard on a MANET		Heard - A MANET interface of node X is considered heard on a MANET
	interface of a node Y if the latter can receive traffic from the		interface of a node Y if the latter can receive traffic from the
	former.		former.
	Link - A pair of MANET interfaces from two different nodes, where at		Link - A pair of MANET interfaces from two different nodes, where at
	skipping to change at page 7, line 23 ¶		skipping to change at page 8, line 23 ¶
	o Is designed to work in networks with a dynamic topology, and in		o Is designed to work in networks with a dynamic topology, and in
	which messages may be lost, such as due to collisions in wireless		which messages may be lost, such as due to collisions in wireless
	networks.		networks.
	o Supports nodes that each have one or more participating MANET		o Supports nodes that each have one or more participating MANET
	interfaces. The set of a node's interfaces may change over time.		interfaces. The set of a node's interfaces may change over time.
	Each interface may have one or more interface addresses, and these		Each interface may have one or more interface addresses, and these
	may also be dynamically changing.		may also be dynamically changing.
	o Can use the link local multicast address and either the "manet"		o Can use the link local multicast address "LL-MANET-Routers", and
	UDP port or the "manet" IP protocol number specified in		either the "manet" UDP port or the "manet" IP protocol number, all
	[manet-iana].		as specified in [manet-iana].
	o Uses the packet and message formats specified in [packetbb]. Such		o Uses the packet and message formats specified in [packetbb]. Such
	packets may contain messages specified by this protocol as well as		packets may contain messages specified by this protocol as well as
	other protocols.		other protocols.
	o Specifies signaling using HELLO messages. The necessary contents		o Specifies signaling using HELLO messages. The necessary contents
	of these messages are defined in this specification, and may be		of these messages are defined in this specification, and may be
	extended using the TLV mechanisms described in [packetbb].		extended using the TLV mechanisms described in [packetbb].
	o Can use relevant link layer information if it is available.		o Can use relevant link layer information if it is available.
	skipping to change at page 28, line 20 ¶		skipping to change at page 29, line 20 ¶
	All addresses in a node's Local Interface Set (i.e. in any		All addresses in a node's Local Interface Set (i.e. in any
	I_local_iface_addr_list) MUST be included in the address blocks in		I_local_iface_addr_list) MUST be included in the address blocks in
	all generated HELLO messages with the following exception. If the		all generated HELLO messages with the following exception. If the
	MANET interface on which the HELLO message is to be sent has a single		MANET interface on which the HELLO message is to be sent has a single
	interface address with maximum prefix length then that address MAY be		interface address with maximum prefix length then that address MAY be
	omitted. All addresses of the node's interfaces included in an		omitted. All addresses of the node's interfaces included in an
	address block MUST be associated with a TLV with Type == LOCAL_IF, as		address block MUST be associated with a TLV with Type == LOCAL_IF, as
	defined in Table 1.		defined in Table 1.
	+----------+--------+-----------------------------------------------+		+----------+---------+----------------------------------------------+
	| Name | Value | Description |		| Name | Value | Description |
	| | Length | |		| | Length | |
	+----------+--------+-----------------------------------------------+		+----------+---------+----------------------------------------------+
	| LOCAL_IF | 1 | Specifies that the address is an address |		| LOCAL_IF | 1 octet | Specifies that the address is an address |
	| | octet | associated with the interface on which the |		| | | associated with the interface on which the |
	| | | message was sent (THIS_IF), another interface |		| | | message was sent (THIS_IF), another |
	| | | of the sending node (OTHER_IF), or an |		| | | interface of the sending node (OTHER_IF), or |
	| | | unspecified interface of the sending node |		| | | an unspecified interface of the sending node |
	| | | (UNSPEC_IF). |		| | | (UNSPEC_IF). |
	+----------+--------+-----------------------------------------------+		+----------+---------+----------------------------------------------+
	Table 1		Table 1
	Note that the value UNSPEC_IF is not used by this protocol. It is		Note that the value UNSPEC_IF is not used by this protocol. It is
	provided for an expected alternative use of this TLV.		provided for an expected alternative use of this TLV.
	Address blocks MAY contain current or recently lost 1-hop neighbors'		Address blocks MAY contain current or recently lost 1-hop neighbors'
	interface addresses, each of which is associated with address block		interface addresses, each of which is associated with address block
	TLVs as described in Table 2.		TLVs as described in Table 2.
	+--------------+--------+-------------------------------------------+		+--------------+---------+------------------------------------------+
	| Name | Value | Description |		| Name | Value | Description |
	| | Length | |		| | Length | |
	+--------------+--------+-------------------------------------------+		+--------------+---------+------------------------------------------+
	| LINK_STATUS | 1 | Specifies the status of the link from the |		| LINK_STATUS | 1 octet | Specifies the status of the link from |
	| | octet | indicated address (LOST, SYMMETRIC or |		| | | the indicated address (LOST, SYMMETRIC |
	| | | HEARD). |		| | | or HEARD). |
	| | | |		| | | |
	| OTHER_NEIGHB | 1 | Specifies that the address is (SYMMETRIC) |		| OTHER_NEIGHB | 1 octet | Specifies that the address is |
	| | octet | or was (LOST) of an interface of a |		| | | (SYMMETRIC) or was (LOST) of an |
	| | | symmetric 1-hop neighbor of the node |		| | | interface of a symmetric 1-hop neighbor |
	| | | transmitting the HELLO message. |		| | | of the node transmitting the HELLO |
	+--------------+--------+-------------------------------------------+		| | | message. |
			+--------------+---------+------------------------------------------+
	Table 2		Table 2
	A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==		A TLV with Type == LINK_STATUS and (Value == SYMMETRIC or Value ==
	LOST) also performs the function of a TLV with Type == OTHER_NEIGHB		LOST) also performs the function of a TLV with Type == OTHER_NEIGHB
	and the same value. The latter SHOULD NOT also be included. If a		and the same value. The latter SHOULD NOT also be included. If a
	TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with		TLV with Type == LINK_STATUS and Value == SYMMETRIC is combined with
	a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter		a TLV with Type == OTHER_NEIGHB and Value == LOST then the latter
	MUST be ignored, and SHOULD NOT be included. See Appendix A.		MUST be ignored, and SHOULD NOT be included. See Appendix A.
	skipping to change at page 49, line 9 ¶		skipping to change at page 50, line 9 ¶
	status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop		status (LOST, SYMMETRIC or HEARD) of the link from a 1-hop
	neighbor.		neighbor.
	* The value of an OTHER_NEIGHB TLV may incorrectly indicate the		* The value of an OTHER_NEIGHB TLV may incorrectly indicate the
	status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.		status (LOST or SYMMETRIC) of a symmetric 1-hop neighbor.
	17. IANA Considerations		17. IANA Considerations
	17.1. Message Types		17.1. Message Types
	This specification defines one message type, which must be allocated		This specification defines one message type, to be allocated from the
	from the "Assigned Message Types" repository of [packetbb] with		0-223 range of the "Message Types" namespace defined in [packetbb],
	assignment as specified in Table 3.		as specified in Table 3.
	+-------+------+------------------+		+-------+------+------------------+
	| Name | Type | Description |		| Name | Type | Description |
	+-------+------+------------------+		+-------+------+------------------+
	| HELLO | TBD1 | Local signaling. |		| HELLO | TBD1 | Local signaling. |
	+-------+------+------------------+		+-------+------+------------------+
	Table 3		Table 3
	17.2. TLV Types		17.2. Address Block TLV Types
	This specification defines three address block TLV types, which must		This specification defines three address block TLV types, which must
	be allocated from the "Assigned Address Block TLV Types" repository		be allocated from the "Address Block TLV Types" namespace defined in
	of [packetbb] with assignments as specified in Table 4.		[packetbb]. IANA are requested to make allocations in the 8-127
			range for these types. This will create three new type extension
			registries with assignments as specified in Table 4, Table 5 and
			Table 6. Specifications of these TLVs are in Section 10.1.1, with
			value constants defined in Section 17.3.
			+----------+------+-----------+-------------------------------------+
			| Name | Type | Type | Description |
			| | | extension | |
			+----------+------+-----------+-------------------------------------+
			| LOCAL_IF | TBD2 | 0 | Specifies that the address is |
			| | | | associated with a local interface |
			| | | | of the sending node. |
			| | | | |
			| | | 1-255 | Expert Review |
			+----------+------+-----------+-------------------------------------+
			Table 4
			+-------------+------+-----------+----------------------------------+
			| Name | Type | Type | Description |
			| | | extension | |
			+-------------+------+-----------+----------------------------------+
			| LINK_STATUS | TBD3 | 0 | Specifies the status of the link |
			| | | | from the indicated address |
			| | | | (LOST, SYMMETRIC or HEARD). |
			| | | | |
			| | | 1-255 | Expert Review |
			+-------------+------+-----------+----------------------------------+
			Table 5
	+--------------+------+-----------+---------------------------------+		+--------------+------+-----------+---------------------------------+
	| Name | Type | Type | Description |		| Name | Type | Type | Description |
	| | | extension | |		| | | extension | |
	+--------------+------+-----------+---------------------------------+		+--------------+------+-----------+---------------------------------+
	| LOCAL_IF | TBD2 | 0 | Specifies that the address is |
	| | | | associated with a local |
	| | | | interface of the sending node. |
	| | | | |
	| | | 1-255 | RESERVED |
	| | | | |
	| LINK_STATUS | TBD3 | 0 | Specifies the status of the |
	| | | | link from the indicated address |
	| | | | (LOST, SYMMETRIC or HEARD). |
	| | | | |
	| | | 1-255 | RESERVED |
	| | | | |
	| OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is |		| OTHER_NEIGHB | TBD4 | 0 | Specifies that the address is |
	| | | | (SYMMETRIC) or recently was |		| | | | (SYMMETRIC) or recently was |
	| | | | (LOST) of an interface of a |		| | | | (LOST) of an interface of a |
	| | | | symmetric 1-hop neighbor of the |		| | | | symmetric 1-hop neighbor of the |
	| | | | node transmitting the message. |		| | | | node transmitting the message. |
	| | | | |		| | | | |
	| | | 1-255 | RESERVED |		| | | 1-255 | Expert Review |
	+--------------+------+-----------+---------------------------------+		+--------------+------+-----------+---------------------------------+
	Table 4		Table 6
	Type extensions indicated as RESERVED may be allocated by standards		Type extensions indicated as Expert Review SHOULD be allocated as
	action, as specified in [RFC2434].		described in [packetbb], based on Expert Review as defined in
			[RFC5226].
	17.3. LINK_STATUS and OTHER_NEIGHB Values		17.3. LINK_STATUS and OTHER_NEIGHB Values
	The values which the LOCAL_IF TLV can use are the following:		The values which the LOCAL_IF TLV can use are the following:
	o UNSPEC_IF = 0		o UNSPEC_IF = 0
	o THIS_IF = 1		o THIS_IF = 1
	o OTHER_IF = 2		o OTHER_IF = 2
	skipping to change at page 50, line 23 ¶		skipping to change at page 52, line 4 ¶
	o THIS_IF = 1		o THIS_IF = 1
	o OTHER_IF = 2		o OTHER_IF = 2
	The values which the LINK_STATUS TLV can use are the following:		The values which the LINK_STATUS TLV can use are the following:
	o LOST = 0		o LOST = 0
	o SYMMETRIC = 1		o SYMMETRIC = 1
	o HEARD = 2		o HEARD = 2
	The values which the OTHER_NEIGHB TLV can use are the following:		The values which the OTHER_NEIGHB TLV can use are the following:
	o LOST = 0		o LOST = 0
	o SYMMETRIC = 1		o SYMMETRIC = 1
	18. References		18. References
	18.1. Normative References		18.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, BCP 14, March 1997.
			[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
			considerations in MANETs", RFC 5148, February 2008.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
			an IANA Considerations Section in RFCs", RFC 5226,
			BCP 26, May 2008.
	[packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,		[packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
	"Generalized MANET Packet/Message Format", Work In		"Generalized MANET Packet/Message Format", Work In
	Progress draft-ietf-manet-packetbb-12.txt, March 2008.		Progress draft-ietf-manet-packetbb-13.txt, June 2008.
	[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
	Work In Progress draft-ietf-manet-iana-07.txt,
	November 2007.
	[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value		[timetlv] Clausen, T. and C. Dearlove, "Representing multi-value
	time in MANETs", Work In		time in MANETs", Work In
	Progress draft-ietf-manet-timetlv-04.txt,		Progress draft-ietf-manet-timetlv-04.txt,
	November 2007.		November 2007.
	[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter		[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
	considerations in MANETs", RFC 5148, February 2008.		Work In Progress draft-ietf-manet-iana-07.txt,
			November 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
	an IANA Considerations Section in RFCs", RFC 2434,
	BCP 26, October 1998.
	18.2. Informative References		18.2. Informative References
	[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
	Routing Protocol", RFC 3626, October 2003.
	[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking		[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
	(MANET): Routing Protocol Performance Issues and		(MANET): Routing Protocol Performance Issues and
	Evaluation Considerations", RFC 2501, January 1999.		Evaluation Considerations", RFC 2501, January 1999.
			[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
			Routing Protocol", RFC 3626, October 2003.
	Appendix A. Address Block TLV Combinations		Appendix A. Address Block TLV Combinations
	The algorithm for generating HELLO messages in Section 11 specifies		The algorithm for generating HELLO messages in Section 11 specifies
	which 1-hop addresses may be included in the address blocks, and with		which 1-hop addresses may be included in the address blocks, and with
	which associated TLVs. These TLVs may have Type == LINK_STATUS or		which associated TLVs. These TLVs may have Type == LINK_STATUS or
	Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may		Type == OTHER_NEIGHB, or both. TLVs with Type == LINK_STATUS may
	have three possible values (Value == HEARD, Value == SYMMETRIC or		have three possible values (Value == HEARD, Value == SYMMETRIC or
	Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two		Value == LOST), and TLVs of TYPE == OTHER_NEIGHB may have two
	possible values (Value == SYMMETRIC or Value == LOST). When both		possible values (Value == SYMMETRIC or Value == LOST). When both
	TLVs are associated with the same address only certain combinations		TLVs are associated with the same address only certain combinations
	of these TLV values are necessary, and are the only combinations		of these TLV values are necessary, and are the only combinations
	generated by the algorithm in Section 11. These combinations are		generated by the algorithm in Section 11. These combinations are
	indicated in Table 5.		indicated in Table 7.
	Cells labeled with "Yes" indicate the possible combinations which are		Cells labeled with "Yes" indicate the possible combinations which are
	generated by the algorithm in Section 11. Cells labeled with "No"		generated by the algorithm in Section 11. Cells labeled with "No"
	indicate combinations not generated by the algorithm in Section 11,		indicate combinations not generated by the algorithm in Section 11,
	but which are correctly parsed and interpreted by the algorithm in		but which are correctly parsed and interpreted by the algorithm in
	Section 12.		Section 12.
	+----------------+----------------+----------------+----------------+		+----------------+----------------+----------------+----------------+
	| | Type == | Type == | Type == |		| | Type == | Type == | Type == |
	| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |		| | OTHER_NEIGHB | OTHER_NEIGHB, | OTHER_NEIGHB, |
	skipping to change at page 52, line 49 ¶		skipping to change at page 54, line 49 ¶
	| Type == | Yes | No | No |		| Type == | Yes | No | No |
	| LINK_STATUS, | | | |		| LINK_STATUS, | | | |
	| Value == | | | |		| Value == | | | |
	| SYMMETRIC | | | |		| SYMMETRIC | | | |
	| | | | |		| | | | |
	| Type == | Yes | Yes | No |		| Type == | Yes | Yes | No |
	| LINK_STATUS, | | | |		| LINK_STATUS, | | | |
	| Value == LOST | | | |		| Value == LOST | | | |
	+----------------+----------------+----------------+----------------+		+----------------+----------------+----------------+----------------+
	Table 5		Table 7
	Appendix B. HELLO Message Example		Appendix B. HELLO Message Example
	An example HELLO message, transmitted by an originator node with a		An example HELLO message, transmitted by an originator node with a
	single MANET interface, is as follows. The message uses IPv4 (four		single MANET interface, is as follows. The message uses IPv4 (four
	octet) addresses without specified prefix lengths. The message is		octet) addresses without specified prefix lengths. The message is
	transmitted with a full message header other than version number		transmitted with a full message header (flags octet value is 240)
	(message semantics octet is 30) with a hop limit of 1 and a hop count		with a hop limit of 1 and a hop count of 0. The overall message
	of 0. The overall message length is 49 octets.		length is 49 octets.
	The message contains a message TLV block with content length 8 octets		The message contains a message TLV block with content length 8 octets
	containing two message TLVs, of types VALIDITY_TIME and		containing two message TLVs, of types VALIDITY_TIME and
	INTERVAL_TIME. Each uses a TLV with semantics value 8, indicating		INTERVAL_TIME. Each uses a TLV with flags octet value 16, indicating
	that each has a value. Each has a value length of 1 octet; the		that each has a value. Each has a value length of 1 octet; the
	values included (0x64 and 0x58) are time codes representing the		values included (0x64 and 0x58) are time codes representing the
	default values of parameters H_HOLD_TIME and HELLO_INTERVAL,		default values of parameters H_HOLD_TIME and HELLO_INTERVAL,
	respectively (6 seconds and 2 seconds) assuming the default value of		respectively (6 seconds and 2 seconds) assuming the default value of
	constant C (1/1024 second).		constant C (1/1024 second).
	The message has a single address block containing 5 addresses. The		The message has a single address block containing 5 addresses. The
	semantics octet value 1 indicates an address head but no address		flags octet value 128 indicates an address head but no address tail.
	tail. The head length of 3 octets indicates address mid sections of		The head length of 3 octets indicates address mid sections of one
	one octet each (Mid 0 to Mid 4).		octet each (Mid 0 to Mid 4).
	The following TLV block (content length 14 octets) includes two TLVs.		The following TLV block (content length 14 octets) includes two TLVs.
	The first is a LOCAL_IF TLV which (with semantics value 10) indicates		The first is a LOCAL_IF TLV which (with flags octet value 80)
	that a single address, with index 0 (i.e. Head:Mid 0) is the single		indicates that a single address, with index 0 (i.e. Head:Mid 0) is
	local interface address of this node (the 1 octet value LOCAL_IF		the single local interface address of this node (the 1 octet value
	indicates that this address is of this interface). The second is a		THIS_IF indicates that this address is of this interface). The
	LINK_STATUS TLV which (with semantics octet 44) specifies the link		second is a LINK_STATUS TLV which (with flags octet value 48)
	status values of all reported neighbors in a single multivalue TLV		specifies the link status values of all reported neighbors in a
	which covers the addresses with indexes 1 to 4. The TLV value length		single multivalue TLV which covers the addresses with indexes 1 to 4.
	of 4 octets indicates one octet per value per address. The last four		The TLV value length of 4 octets indicates one octet per value per
	addresses are first and second HEARD, third SYMMETRIC, and fourth		address. The last four addresses are first and second HEARD, third
	LOST.		SYMMETRIC, and fourth LOST.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| HELLO |0 0 0 1 1 1 1 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|		| HELLO |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originator Address |		| Originator Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |		|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| Message Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|		|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 0 1 0 0 0|		|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0| INTERVAL_TIME |0 0 0 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 1|		|0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 1 1| Head |		|0 0 0 0 0 0 1 1| Head |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mid 0 | Mid 1 | Mid 2 | Mid 3 |		| Mid 0 | Mid 1 | Mid 2 | Mid 3 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF |		| Mid 4 |0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0| LOCAL_IF |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF |		|0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1| THIS_IF |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LINK_STATUS |0 0 1 0 1 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|		| LINK_STATUS |0 0 1 1 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |		|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LOST |		| LOST |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Note that this example is for illustrative purposes. The essential		Note that this example is for illustrative purposes. The essential
	information can be conveyed, more efficiently (assuming that the		information can be conveyed, more efficiently (assuming that the
	local interface address will be supplied by IP, and that the		local interface address will be supplied by IP, and that the
	INTERVAL_TIME is not needed) by the 29 octets:		INTERVAL_TIME is not needed) by the 29 octets:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|		| HELLO |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 0 1 0 0 0|		|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0| VALIDITY_TIME |0 0 0 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0|		|0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 1 0 0|1 0 0 0 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 1 1| Head |		|0 0 0 0 0 0 1 1| Head |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mid 1 | Mid 2 | Mid 3 | Mid 4 |		| Mid 1 | Mid 2 | Mid 3 | Mid 4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 1 0 1 0 0 0|		|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1| LINK_STATUS |0 0 0 1 0 1 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |		|0 0 0 0 0 1 0 0| HEARD | HEARD | SYMMETRIC |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LOST |		| LOST |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Appendix C. Constraints		Appendix C. Constraints
	Any process which updates the Local Information Base or the Node		Any process which updates the Local Information Base or the Node
	Information Base MUST ensure that all constraints specified in this		Information Base MUST ensure that all constraints specified in this
	skipping to change at page 61, line 12 ¶		skipping to change at page 63, line 12 ¶
	o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>		o Philippe Jacquet, INRIA, France, <Philippe.Jacquet@inria.fr>
	Appendix F. Acknowledgements		Appendix F. Acknowledgements
	The authors would like to acknowledge the team behind OLSRv1,		The authors would like to acknowledge the team behind OLSRv1,
	specified in RFC3626 for their contributions.		specified in RFC3626 for their contributions.
	The authors would like to gratefully acknowledge the following people		The authors would like to gratefully acknowledge the following people
	for intense technical discussions, early reviews and comments on the		for intense technical discussions, early reviews and comments on the
	specification and its components: Joe Macker (NRL), Alan Cullen (BAE		specification and its components (listed alphabetically): Alan Cullen
	Systems), and the entire IETF MANET working group.		(BAE Systems), Ulrich Herberg (LIX), Satoh Hiroki (Hitachi) Joe
			Macker (NRL), Charles E. Perkins (WiChorus), Laurent Viennot (INRIA),
			and the entire IETF MANET working group.
	Authors' Addresses		Authors' Addresses
	Thomas Heide Clausen		Thomas Heide Clausen
	LIX, Ecole Polytechnique, France		LIX, Ecole Polytechnique, France
	Phone: +33 6 6058 9349		Phone: +33 6 6058 9349
	EMail: T.Clausen@computer.org		EMail: T.Clausen@computer.org
	URI: http://www.ThomasClausen.org/		URI: http://www.ThomasClausen.org/
End of changes. 40 change blocks.
	192 lines changed or deleted		274 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/