< draft-ietf-manet-olsrv2-06.txt		draft-ietf-manet-olsrv2-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: December 8, 2008 BAE Systems Advanced Technology		Expires: January 11, 2009 BAE Systems Advanced Technology
	Centre		Centre
	P. Jacquet		P. Jacquet
	Project Hipercom, INRIA		Project Hipercom, INRIA
	The OLSRv2 Design Team		The OLSRv2 Design Team
	MANET Working Group		MANET Working Group
	June 6, 2008		July 10, 2008
	The Optimized Link State Routing Protocol version 2		The Optimized Link State Routing Protocol version 2
	draft-ietf-manet-olsrv2-06		draft-ietf-manet-olsrv2-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 December 8, 2008.		This Internet-Draft will expire on January 11, 2009.
	Abstract		Abstract
	This document describes version 2 of the Optimized Link State Routing		This document describes version 2 of the Optimized Link State Routing
	(OLSRv2) protocol. The protocol embodies an optimization of the		(OLSRv2) protocol. The protocol embodies an optimization of the
	classical link state algorithm tailored to the requirements of a		classical link state algorithm tailored to the requirements of a
	Mobile Ad hoc NETwork (MANET).		Mobile Ad hoc NETwork (MANET).
	The key optimization in OLSRv2 is that of multipoint relays (MPRs),		The key optimization in OLSRv2 is that of multipoint relays (MPRs),
	providing an efficient mechanism for network-wide broadcast of link		providing an efficient mechanism for network-wide broadcast of link
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	7. Packet Processing and Message Forwarding . . . . . . . . . . . 26		7. Packet Processing and Message Forwarding . . . . . . . . . . . 26
	7.1. Actions when Receiving an OLSRv2 Packet . . . . . . . . . 26		7.1. Actions when Receiving an OLSRv2 Packet . . . . . . . . . 26
	7.2. Actions when Receiving an OLSRv2 Message . . . . . . . . . 26		7.2. Actions when Receiving an OLSRv2 Message . . . . . . . . . 26
	7.3. Message Considered for Processing . . . . . . . . . . . . 27		7.3. Message Considered for Processing . . . . . . . . . . . . 27
	7.4. Message Considered for Forwarding . . . . . . . . . . . . 28		7.4. Message Considered for Forwarding . . . . . . . . . . . . 28
	8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31		8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 31
	8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31		8.1. HELLO Messages . . . . . . . . . . . . . . . . . . . . . . 31
	8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 32		8.1.1. HELLO Message TLVs . . . . . . . . . . . . . . . . . . 32
	8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 32		8.1.2. HELLO Message Address Block TLVs . . . . . . . . . . . 32
	8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 32		8.2. TC Messages . . . . . . . . . . . . . . . . . . . . . . . 32
	8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 34		8.2.1. TC Message TLVs . . . . . . . . . . . . . . . . . . . 33
	8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 34		8.2.2. TC Message Address Block TLVs . . . . . . . . . . . . 34
	9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 35		9. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 35
	9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 35		9.1. HELLO Message: Transmission . . . . . . . . . . . . . . . 35
	10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36		10. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 36
	10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 36		10.1. Updating Willingness . . . . . . . . . . . . . . . . . . . 36
	10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 36		10.2. Updating MPR Selectors . . . . . . . . . . . . . . . . . . 36
	10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 36		10.3. Symmetric 1-Hop and 2-Hop Neighborhood Changes . . . . . . 36
	11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 38		11. TC Message Generation . . . . . . . . . . . . . . . . . . . . 38
	11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 39		11.1. TC Message: Transmission . . . . . . . . . . . . . . . . . 39
	12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 40		12. TC Message Processing . . . . . . . . . . . . . . . . . . . . 40
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 51		17.5. Jitter Time Parameters . . . . . . . . . . . . . . . . . . 51
	17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 51		17.6. Hop Limit Parameter . . . . . . . . . . . . . . . . . . . 51
	17.7. Willingness Parameter and Constants . . . . . . . . . . . 52		17.7. Willingness Parameter and Constants . . . . . . . . . . . 52
	18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 53		18. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 53
	19. Security Considerations . . . . . . . . . . . . . . . . . . . 54		19. Security Considerations . . . . . . . . . . . . . . . . . . . 54
	19.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 54		19.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 54
	19.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 54		19.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 54
	19.3. Interaction with External Routing Domains . . . . . . . . 55		19.3. Interaction with External Routing Domains . . . . . . . . 55
	20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57		20. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
	20.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 57		20.1. Message Types . . . . . . . . . . . . . . . . . . . . . . 57
	20.2. TLV Types . . . . . . . . . . . . . . . . . . . . . . . . 57		20.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 57
	21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59		20.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 58
	21.1. Normative References . . . . . . . . . . . . . . . . . . . 59		21. References . . . . . . . . . . . . . . . . . . . . . . . . . . 60
	21.2. Informative References . . . . . . . . . . . . . . . . . . 59		21.1. Normative References . . . . . . . . . . . . . . . . . . . 60
	Appendix A. Node Configuration . . . . . . . . . . . . . . . . . 61		21.2. Informative References . . . . . . . . . . . . . . . . . . 60
	Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 62		Appendix A. Node Configuration . . . . . . . . . . . . . . . . . 62
	B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 62		Appendix B. Example Algorithm for Calculating MPRs . . . . . . . 63
	B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 63		B.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 63
	Appendix C. Example Algorithm for Calculating the Routing Set . . 64		B.2. MPR Selection Algorithm for each OLSRv2 Interface . . . . 64
	C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 64		Appendix C. Example Algorithm for Calculating the Routing Set . . 65
	C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 65		C.1. Add Local Symmetric Links . . . . . . . . . . . . . . . . 65
	C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 66		C.2. Add Remote Symmetric Links . . . . . . . . . . . . . . . . 66
	Appendix D. Example Message Layout . . . . . . . . . . . . . . . 67		C.3. Add Attached Networks . . . . . . . . . . . . . . . . . . 67
	Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 69		Appendix D. Example Message Layout . . . . . . . . . . . . . . . 68
	Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 73		Appendix E. Constraints . . . . . . . . . . . . . . . . . . . . . 70
	Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 74		Appendix F. Flow and Congestion Control . . . . . . . . . . . . . 74
	Appendix H. Acknowledgements . . . . . . . . . . . . . . . . . . 75		Appendix G. Contributors . . . . . . . . . . . . . . . . . . . . 75
			Appendix H. Acknowledgements . . . . . . . . . . . . . . . . . . 76
	1. Introduction		1. Introduction
	The Optimized Link State Routing protocol version 2 (OLSRv2) is an		The Optimized Link State Routing protocol version 2 (OLSRv2) is an
	update to OLSRv1 as published in [RFC3626]. Compared to RFC3626,		update to OLSRv1 as published in [RFC3626]. Compared to RFC3626,
	OLSRv2 retains the same basic mechanisms and algorithms, while		OLSRv2 retains the same basic mechanisms and algorithms, while
	providing a more flexible signaling framework and some simplification		providing a more flexible signaling framework and some simplification
	of the messages being exchanged. Also, OLSRv2 accommodates either		of the messages being exchanged. Also, OLSRv2 accommodates either
	IPv4 and IPv6 addresses in a compact manner.		IPv4 and IPv6 addresses in a compact manner.
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	OLSRv2 may use link layer information and notifications when		OLSRv2 may use link layer information and notifications when
	available and applicable, as described in [nhdp].		available and applicable, as described in [nhdp].
	OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying		OLSRv2, as OLSRv1, inherits its concept of forwarding and relaying
	from HIPERLAN (a MAC layer protocol) which is standardized by ETSI		from HIPERLAN (a MAC layer protocol) which is standardized by ETSI
	[HIPERLAN], [HIPERLAN2].		[HIPERLAN], [HIPERLAN2].
	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].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	MANET specific terminology is to be interpreted as described in		MANET specific terminology is to be interpreted as described in
	[packetbb] and [nhdp].		[packetbb] and [nhdp].
	Additionally, this document uses the following terminology:		Additionally, this document uses the following terminology:
	Node - A MANET router which implements the Optimized Link State		Node - A MANET router which implements the Optimized Link State
	Routing protocol version 2 as specified in this document.		Routing protocol version 2 as specified in this document.
	OLSRv2 interface - A MANET interface, running OLSRv2. Note that all		OLSRv2 interface - A MANET interface, running OLSRv2. Note that all
	skipping to change at page 10, line 5 ¶		skipping to change at page 9, line 7 ¶
	Information Bases describing the node's 1-hop and symmetric 2-hop		Information Bases describing the node's 1-hop and symmetric 2-hop
	neighbors. This neighborhood discovery protocol, which also uses		neighbors. This neighborhood discovery protocol, which also uses
	[packetbb], is extended in this document by the addition of MPR		[packetbb], is extended in this document by the addition of MPR
	information.		information.
	OLSRv2 does not make any assumption about node addresses, other than		OLSRv2 does not make any assumption about node addresses, other than
	that each node is assumed to have at least one unique and routable IP		that each node is assumed to have at least one unique and routable IP
	address for each interface that it has which participates in the		address for each interface that it has which participates in the
	MANET.		MANET.
			OLSRv2 can, as does [nhdp], use the link local multicast address "LL-
			MANET-Routers", and either the "manet" UDP port or the "manet" IP
			protocol number, all as specified in [manet-iana].
	4. Protocol Overview and Functioning		4. Protocol Overview and Functioning
	OLSRv2 is a proactive routing protocol for mobile ad hoc networks.		OLSRv2 is a proactive routing protocol for mobile ad hoc networks.
	The protocol inherits the stability of a link state algorithm and has		The protocol inherits the stability of a link state algorithm and has
	the advantage of having routes immediately available when needed due		the advantage of having routes immediately available when needed due
	to its proactive nature. OLSRv2 is an optimization of the classical		to its proactive nature. OLSRv2 is an optimization of the classical
	link state protocol, tailored for mobile ad hoc networks. The main		link state protocol, tailored for mobile ad hoc networks. The main
	tailoring and optimizations of OLSRv2 are:		tailoring and optimizations of OLSRv2 are:
	o Unacknowledged transmission of all control messages; control		o Unacknowledged transmission of all control messages; control
	skipping to change at page 27, line 11 ¶		skipping to change at page 27, line 11 ¶
	Originator Tuple) then the message MUST be silently discarded.		Originator Tuple) then the message MUST be silently discarded.
	2. Otherwise:		2. Otherwise:
	1. If the message is a HELLO message, then the message is		1. If the message is a HELLO message, then the message is
	processed according to Section 10.		processed according to Section 10.
	2. Otherwise:		2. Otherwise:
	1. Define the "dependent message type" of the message to		1. Define the "dependent message type" of the message to
	equal the message type if the mistypedep bit of the		equal the message type if the mistypedep flag bit in the
	message semantics octet in the message header is set		message header is set ('1'), or otherwise to equal a
	('1'), or to equal 0 otherwise.		value "type-independent" which is not in the range 0 to
			255.
	2. If the message is of a known type, including being a TC		2. If the message is of a known type, including being a TC
	message, then the message is considered for processing		message, then the message is considered for processing
	according to Section 7.3, AND;		according to Section 7.3, AND;
	3. If for the message:		3. If for the message:
	- <hop-limit> is present and <hop-limit> > 1, AND;		- <hop-limit> is present and <hop-limit> > 1, AND;
	- <hop-count> is not present or <hop-count> < 255		- <hop-count> is not present or <hop-count> < 255
	skipping to change at page 31, line 28 ¶		skipping to change at page 31, line 28 ¶
	o OLSRv2 packets MAY include packet TLVs, however OLSRv2 itself does		o OLSRv2 packets MAY include packet TLVs, however OLSRv2 itself does
	not specify any packet TLVs.		not specify any packet TLVs.
	o All references in this specification to TLVs that do not indicate		o All references in this specification to TLVs that do not indicate
	a type extension, assume Type Extension == 0. TLVs in processed		a type extension, assume Type Extension == 0. TLVs in processed
	messages with a type extension which is neither zero as so		messages with a type extension which is neither zero as so
	assumed, nor a specifically indicated non-zero type extension, are		assumed, nor a specifically indicated non-zero type extension, are
	ignored.		ignored.
	Other options defined in [packetbb] may be freely used, in particular		Other options defined in [packetbb] may be freely used, in particular
	any other values of <pkt-semantics>, <msg-semantics>, <addr-		any other values of <pkt-flags>, <msg-flags>, <addr-flags> or <tlv-
	semantics> or <tlv-semantics> consistent with their specifications.		flags> consistent with their specifications.
	The remainder of this section defines, within the framework of		The remainder of this section defines, within the framework of
	[packetbb], message types and TLVs specific to OLSRv2.		[packetbb], message types and TLVs specific to OLSRv2.
	8.1. HELLO Messages		8.1. HELLO Messages
	A HELLO message in OLSRv2 is generated as specified in [nhdp].		A HELLO message in OLSRv2 is generated as specified in [nhdp].
	Additionally, an OLSRv2 node:		Additionally, an OLSRv2 node:
	o MUST include TLV(s) with Type == MPR associated with all OLSRv2		o MUST include TLV(s) with Type == MPR associated with all OLSRv2
	skipping to change at page 32, line 15 ¶		skipping to change at page 32, line 15 ¶
	o MAY include a message TLV with Type == MPR_WILLING, indicating the		o MAY include a message TLV with Type == MPR_WILLING, indicating the
	node's willingness to be selected as an MPR.		node's willingness to be selected as an MPR.
	8.1.1. HELLO Message TLVs		8.1.1. HELLO Message TLVs
	In a HELLO message, a node MUST include an MPR_WILLING message TLV as		In a HELLO message, a node MUST include an MPR_WILLING message TLV as
	specified in Table 1, unless WILLINGNESS == WILL_DEFAULT (in which		specified in Table 1, unless WILLINGNESS == WILL_DEFAULT (in which
	case it MAY be included). A node MUST NOT include more than one		case it MAY be included). A node MUST NOT include more than one
	MPR_WILLING message TLV.		MPR_WILLING message TLV.
	+-------------+--------+--------------------------------------------+		+-------------+--------------+--------------------------------------+
	| Type | Value | Value |		| Type | Value Length | Value |
	| | Length | |		+-------------+--------------+--------------------------------------+
	+-------------+--------+--------------------------------------------+		| MPR_WILLING | 1 octet | Node parameter WILLINGNESS; unused |
	| MPR_WILLING | 8 bits | Node parameter WILLINGNESS; unused bits |		| | | bits (based on the maximum |
	| | | (based on the maximum willingness value |		| | | willingness value WILL_ALWAYS) are |
	| | | WILL_ALWAYS) are RESERVED and SHOULD be |		| | | RESERVED and SHOULD be set to zero. |
	| | | set to zero. |		+-------------+--------------+--------------------------------------+
	+-------------+--------+--------------------------------------------+
	Table 1		Table 1
	If a node does not advertise an MPR_WILLING TLV in a HELLO message,		If a node does not advertise an MPR_WILLING TLV in a HELLO message,
	then the node MUST be assumed to have WILLINGNESS equal to		then the node MUST be assumed to have WILLINGNESS equal to
	WILL_DEFAULT.		WILL_DEFAULT.
	8.1.2. HELLO Message Address Block TLVs		8.1.2. HELLO Message Address Block TLVs
	In a HELLO message, a node MAY include MPR address block TLV(s) as		In a HELLO message, a node MAY include MPR address block TLV(s) as
	specified in Table 2.		specified in Table 2.
	+------+--------------+-------+		+------+--------------+-------+
	| Type | Value Length | Value |		| Type | Value Length | Value |
	+------+--------------+-------+		+------+--------------+-------+
	| MPR | 0 bits | None. |		| MPR | 0 octets | None. |
	+------+--------------+-------+		+------+--------------+-------+
	Table 2		Table 2
	8.2. TC Messages		8.2. TC Messages
	A TC message MUST contain:		A TC message MUST contain:
	o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its		o <msg-orig-addr>, <msg-seq-num> and <msg-hop-limit> elements in its
	message header, as specified in [packetbb].		message header, as specified in [packetbb].
	skipping to change at page 33, line 35 ¶		skipping to change at page 33, line 34 ¶
	message's address blocks.		message's address blocks.
	o TLV(s) with Type == LOCAL_IF and Value == UNSPEC_IF associated		o TLV(s) with Type == LOCAL_IF and Value == UNSPEC_IF associated
	with all of the node's interface addresses.		with all of the node's interface addresses.
	o If the TC message is complete, all addresses in the Advertised		o If the TC message is complete, all addresses in the Advertised
	Address Set and all addresses in the Local Attached Network Set,		Address Set and all addresses in the Local Attached Network Set,
	the latter (only) with associated GATEWAY address block TLV(s), as		the latter (only) with associated GATEWAY address block TLV(s), as
	specified in Section 8.2.2.		specified in Section 8.2.2.
	A TC message SHOULD have the mistypedep bit of <msg-semantics>, as		A TC message SHOULD have the mistypedep bit of <msg-flags>, as
	defined in [packetbb], cleared ('0').		defined in [packetbb], cleared ('0').
	A TC message MAY contain:		A TC message MAY contain:
	o If the TC message is incomplete, any addresses in the Advertised		o If the TC message is incomplete, any addresses in the Advertised
	Address Set and any addresses in the Local Attached Network Set,		Address Set and any addresses in the Local Attached Network Set,
	the latter (only) with associated GATEWAY address block TLV(s), as		the latter (only) with associated GATEWAY address block TLV(s), as
	specified in Section 8.2.2.		specified in Section 8.2.2.
	o A message TLV with Type == INTERVAL_TIME, as specified in		o A message TLV with Type == INTERVAL_TIME, as specified in
	[timetlv]. The options included in [timetlv] for representing		[timetlv]. The options included in [timetlv] for representing
	zero and infinite times MUST NOT be used.		zero and infinite times MUST NOT be used.
	8.2.1. TC Message TLVs		8.2.1. TC Message TLVs
	In a TC message, a node MUST include a single CONT_SEQ_NUM message		In a TC message, a node MUST include a single CONT_SEQ_NUM message
	TLV, as specified in Table 3, and with Type Extension == COMPLETE or		TLV, as specified in Table 3, and with Type Extension == COMPLETE or
	Type Extension == INCOMPLETE, according to whether the TC message is		Type Extension == INCOMPLETE, according to whether the TC message is
	complete or incomplete.		complete or incomplete.
	+--------------+------------+---------------------------------------+		+--------------+--------------+-------------------------------------+
	| Type | Value | Value |		| Type | Value Length | Value |
	| | Length | |		+--------------+--------------+-------------------------------------+
	+--------------+------------+---------------------------------------+		| CONT_SEQ_NUM | 1 octet | The ANSN contained in the |
	| CONT_SEQ_NUM | 8 bits | The ANSN contained in the Advertised |		| | | Advertised Neighbor Set. |
	| | | Neighbor Set. |		+--------------+--------------+-------------------------------------+
	+--------------+------------+---------------------------------------+
	Table 3		Table 3
	8.2.2. TC Message Address Block TLVs		8.2.2. TC Message Address Block TLVs
	In a TC message, a node MAY include GATEWAY address block TLV(s) as		In a TC message, a node MAY include GATEWAY address block TLV(s) as
	specified in Table 4.		specified in Table 4.
	+---------+--------------+-------------------------------------+		+---------+--------------+-------------------------------------+
	| Type | Value Length | Value |		| Type | Value Length | Value |
	+---------+--------------+-------------------------------------+		+---------+--------------+-------------------------------------+
	| GATEWAY | 8 bits | Number of hops to attached network. |		| GATEWAY | 1 octet | Number of hops to attached network. |
	+---------+--------------+-------------------------------------+		+---------+--------------+-------------------------------------+
	Table 4		Table 4
	GATEWAY address block TLV(s) MUST be associated with all attached		GATEWAY address block TLV(s) MUST be associated with all attached
	network addresses, and MUST NOT be associated with any other		network addresses, and MUST NOT be associated with any other
	addresses.		addresses.
	9. HELLO Message Generation		9. HELLO Message Generation
	skipping to change at page 57, line 9 ¶		skipping to change at page 57, line 9 ¶
	domain to an OLSRv2 routed MANET is to assign an IP prefix (under the		domain to an OLSRv2 routed MANET is to assign an IP prefix (under the
	authority of the nodes/gateways connecting the MANET with the exiting		authority of the nodes/gateways connecting the MANET with the exiting
	routing domain) exclusively to the OLSRv2 MANET area, and to		routing domain) exclusively to the OLSRv2 MANET area, and to
	configure the gateways statically to advertise routes to that IP		configure the gateways statically to advertise routes to that IP
	sequence to nodes in the existing routing domain.		sequence to nodes in the existing routing domain.
	20. IANA Considerations		20. IANA Considerations
	20.1. Message Types		20.1. Message Types
	OLSRv2 defines one message type, which must be allocated from the		This specification defines one message type, to be allocated from the
	"Assigned Message Types" repository of [packetbb].		0-223 range of the "Message Types" namespace defined in [packetbb],
			as specified in Table 5.
	+------+------+-----------------------------------------+		+------+------+-----------------------------------------+
	| Name | Type | Description |		| Name | Type | Description |
	+------+------+-----------------------------------------+		+------+------+-----------------------------------------+
	| TC | TBD1 | Topology Control (MANET-wide signaling) |		| TC | TBD1 | Topology Control (MANET-wide signaling) |
	+------+------+-----------------------------------------+		+------+------+-----------------------------------------+
	Table 5		Table 5
	20.2. TLV Types		20.2. Message TLV Types
	OLSRv2 defines two message TLV types, which must be allocated from		This specification defines two message TLV types, which must be
	the "Assigned message TLV Types" repository of [packetbb].		allocated from the "Message TLV Types" namespace defined in
			[packetbb]. IANA are requested to make allocations in the 8-127
			range for these types. This will create two new type extension
			registries with assignments as specified in Table 6 and Table 7.
			Specifications of these TLVs are in Section 8.1.1 and Section 8.2.1.
			+-------------+------+-----------+----------------------------------+
			| Name | Type | Type | Description |
			| | | extension | |
			+-------------+------+-----------+----------------------------------+
			| MPR_WILLING | TBD2 | 0 | Specifies the originating node's |
			| | | | willingness to act as a relay |
			| | | | and to partake in network |
			| | | | formation |
			| | | | |
			| | | 1-255 | Expert Review |
			+-------------+------+-----------+----------------------------------+
			Table 6
	+--------------+------+----------------+----------------------------+		+--------------+------+----------------+----------------------------+
	| Name | Type | Type extension | Description |		| Name | Type | Type extension | Description |
	+--------------+------+----------------+----------------------------+		+--------------+------+----------------+----------------------------+
	| MPR_WILLING | TBD2 | 0 | Specifies the originating |
	| | | | node's willingness to act |
	| | | | as a relay and to partake |
	| | | | in network formation |
	| | | | |
	| | | 1-255 | RESERVED |
	| | | | |
	| CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content |		| CONT_SEQ_NUM | TBD3 | 0 (COMPLETE) | Specifies a content |
	| | | | sequence number for this |		| | | | sequence number for this |
	| | | | complete message |		| | | | complete message |
	| | | | |		| | | | |
	| | | 1 (INCOMPLETE) | Specifies a content |		| | | 1 (INCOMPLETE) | Specifies a content |
	| | | | sequence number for this |		| | | | sequence number for this |
	| | | | incomplete message |		| | | | incomplete message |
	| | | | |		| | | | |
	| | | 2-255 | RESERVED |		| | | 2-255 | Expert Review |
	+--------------+------+----------------+----------------------------+		+--------------+------+----------------+----------------------------+
	Table 6		Table 7
	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].
	OLSRv2 defines two Address Block TLV types, which must be allocated		20.3. Address Block TLV Types
	from the "Assigned address block TLV Types" repository of [packetbb].
			This specification defines two address block TLV types, which must be
			allocated from the "Address Block TLV Types" namespace defined in
			[packetbb]. IANA are requested to make allocations in the 8-127
			range for these types. This will create two new type extension
			registries with assignments as specified in Table 8 and Table 9.
			Specifications of these TLVs are in Section 8.1.2 and Section 8.2.2.
			+------+------+-----------+-----------------------------------------+
			| Name | Type | Type | Description |
			| | | extension | |
			+------+------+-----------+-----------------------------------------+
			| MPR | TBD4 | 0 | Specifies that a given address is of a |
			| | | | node selected as an MPR |
			| | | | |
			| | | 1-255 | Expert Review |
			+------+------+-----------+-----------------------------------------+
			Table 8
	+---------+------+-----------+--------------------------------------+		+---------+------+-----------+--------------------------------------+
	| Name | Type | Type | Description |		| Name | Type | Type | Description |
	| | | extension | |		| | | extension | |
	+---------+------+-----------+--------------------------------------+		+---------+------+-----------+--------------------------------------+
	| MPR | TBD4 | 0 | Specifies that a given address is of |
	| | | | a node selected as an MPR |
	| | | | |
	| | | 1-255 | RESERVED |
	| | | | |
	| GATEWAY | TBD5 | 0 | Specifies that a given address is |		| GATEWAY | TBD5 | 0 | Specifies that a given address is |
	| | | | reached via a gateway on the |		| | | | reached via a gateway on the |
	| | | | originating node |		| | | | originating node |
	| | | | |		| | | | |
	| | | 1-255 | RESERVED |		| | | 1-255 | Expert Review |
	+---------+------+-----------+--------------------------------------+		+---------+------+-----------+--------------------------------------+
	Table 7		Table 9
	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].
	21. References		21. References
	21.1. Normative References		21.1. Normative References
	[packetbb] Clausen, T., Dean, J., Dearlove, C., and C. Adjih,		[packetbb] Clausen, T., Dean, J., Dearlove, C., 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.
	[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, November 2007.		Progress draft-ietf-manet-timetlv-05.txt, July 2008.
	[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter		[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
	considerations in MANETs", RFC 5148, February 2008.		considerations in MANETs", RFC 5148, February 2008.
	[nhdp] Clausen, T., Dean, J., and C. Dearlove, "MANET		[nhdp] Clausen, T., Dean, J., and C. Dearlove, "MANET
	Neighborhood Discovery Protocol (NHDP)", work in		Neighborhood Discovery Protocol (NHDP)", work in
	progress draft-ietf-manet-nhdp-06.txt, March 2008.		progress draft-ietf-manet-nhdp-07.txt, July 2008.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[manet-iana] Chakeres, I., "IANA Allocations for MANET Protocols",
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Work In Progress draft-ietf-manet-iana-07.txt,
			November 2007.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	IANA Considerations Section in RFCs", RFC 2434, BCP 26,		Requirement Levels", RFC 2119, BCP 14, March 1997.
	October 1998.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
			an IANA Considerations Section in RFCs", RFC 5226,
			BCP 26, May 2008.
	21.2. Informative References		21.2. Informative References
	[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State		[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking
	Routing Protocol", RFC 3626, October 2003.		(MANET): Routing Protocol Performance Issues and
			Evaluation Considerations", RFC 2501, January 1999.
	[RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,		[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
	"OpenPGP message format", RFC 4880, November 2007.		Routing Protocol", RFC 3626, October 2003.
	[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and		[RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
	systems: HIPERLAN type 1, functional specifications ETS		"OpenPGP message format", RFC 4880, November 2007.
	300-652", June 1996.
	[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N.		[HIPERLAN] ETSI, "ETSI STC-RES10 Committee. Radio equipment and
	Rivierre, "Increasing reliability in cable free radio		systems: HIPERLAN type 1, functional specifications ETS
	LANs: Low level forwarding in HIPERLAN.", 1996.		300-652", June 1996.
	[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint		[HIPERLAN2] Jacquet, P., Minet, P., Muhlethaler, P., and N.
	relaying: An efficient technique for flooding in mobile		Rivierre, "Increasing reliability in cable free radio
	wireless networks.", 2001.		LANs: Low level forwarding in HIPERLAN.", 1996.
	[RFC2501] Macker, J. and S. Corson, "Mobile Ad hoc Networking		[MPR] Qayyum, A., Viennot, L., and A. Laouiti, "Multipoint
	(MANET): Routing Protocol Performance Issues and		relaying: An efficient technique for flooding in mobile
	Evaluation Considerations", RFC 2501, January 1999.		wireless networks.", 2001.
	[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state routing		[FSR] Pei, G., Gerla, M., and T. Chen, "Fisheye state routing
	in mobile ad hoc networks", 2000.		in mobile ad hoc networks", 2000.
	[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis,		[FSLS] Santivanez, C., Ramanathan, R., and I. Stavrakakis,
	"Making link-state routing scale for ad hoc networks",		"Making link-state routing scale for ad hoc networks",
	2000.		2000.
	Appendix A. Node Configuration		Appendix A. Node Configuration
	OLSRv2 does not make any assumption about node addresses, other than		OLSRv2 does not make any assumption about node addresses, other than
	that each node is assumed to have at least one unique and routable IP		that each node is assumed to have at least one unique and routable IP
	address for each interface that it has which participates in the		address for each interface that it has which participates in the
	MANET.		MANET.
	When applicable, a recommended way of connecting an OLSRv2 network to		When applicable, a recommended way of connecting an OLSRv2 network to
	an existing IP routing domain is to assign an IP prefix (under the		an existing IP routing domain is to assign an IP prefix (under the
	skipping to change at page 67, line 10 ¶		skipping to change at page 68, line 10 ¶
	+ R_dist = (R_dist of the previous Routing Tuple) + AN_dist;		+ R_dist = (R_dist of the previous Routing Tuple) + AN_dist;
	+ R_local_iface_addr = R_local_iface_addr of the previous		+ R_local_iface_addr = R_local_iface_addr of the previous
	Routing Tuple.		Routing Tuple.
	Appendix D. Example Message Layout		Appendix D. Example Message Layout
	An example TC message, using IPv4 (four octet) addresses, is as		An example TC message, using IPv4 (four octet) addresses, is as
	follows. The overall message length is 65 octets.		follows. The overall message length is 65 octets.
	The message has semantics octet 30, and hence all required message		The message has flags octet value 240, and hence a complete message
	header fields. It has a message TLV block with content length 13		header. It has a message TLV block with content length 13 octets
	octets containing three TLVs. The first two TLVs are validity and		containing three TLVs. The first two TLVs are validity and interval
	interval times for the message. The third TLV is the content		times for the message. The third TLV is the content sequence number
	sequence number TLV used to carry the 2 octet ANSN, and (with default		TLV used to carry the 2 octet ANSN, and (with default type extension
	type extension zero, i.e. COMPLETE) indicating that the TC message		zero, i.e. COMPLETE) indicating that the TC message is complete.
	is complete. Each TLV uses a TLV with semantics value 8, indicating		Each TLV uses a TLV with flags octet value 16, indicating that it has
	that it has a value, but no type extension or start and stop indexes.		a value, but no type extension or start and stop indexes. The first
	The first two TLVs have a value length of 1 octet, the last has a		two TLVs have a value length of 1 octet, the last has a value length
	value length of 2 octets.		of 2 octets.
	The message has two address blocks. The first address block contains		The message has two address blocks. The first address block contains
	6 addresses, with semantics octet 1, hence with a head section, (with		6 addresses, with flags octet value 128, hence with a head section,
	length 2 octets) but no tail section, and hence mid sections with		(with length 2 octets) but no tail section, and hence mid sections
	length two octets. The following TLV block (content length 6 octets)		with length two octets. The following TLV block (content length 6
	contains a single LOCAL_IF TLV (semantics value 12) indicating that		octets) contains a single LOCAL_IF TLV (flags octet value 48)
	the first three addresses (indexes 0 to 2) are associated with the		indicating that the first three addresses (indexes 0 to 2) are
	value (length 1 octet) UNSPEC_IF, i.e. they are the originating		associated with the value (length 1 octet) UNSPEC_IF, i.e. they are
	node's local interface addresses. The remaining three addresses have		the originating node's local interface addresses. The remaining
	no associated TLV, they are the interface addresses of advertised		three addresses have no associated TLV, they are the interface
	neighbors.		addresses of advertised neighbors.
	The second address block contains 1 address, with semantics octet 13		The second address block contains 1 address, with flags octet 176
	indicating that there is a head section (with length 2 octets), that		indicating that there is a head section (with length 2 octets), that
	the tail section (length 2 octets) consists of zero valued octets		the tail section (length 2 octets) consists of zero valued octets
	(not included), and that there is a single prefix length, which is		(not included), and that there is a single prefix length, which is
	16. The network address is thus Head.0.0/16. The following TLV		16. The network address is thus Head.0.0/16. The following TLV
	block (content length 8 octets) includes one TLV that indicates that		block (content length 8 octets) includes one TLV that indicates that
	the originating node is a gateway to this network, at a given number		the originating node is a gateway to this network, at a given number
	of hops distance (value length 1 octet). The TLV semantics value of		of hops distance (value length 1 octet). The TLV flags octet value
	8 indicates that no indexes are needed.		of 16 indicates that no indexes are needed.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TC |0 0 0 1 1 1 1 0|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1|		| TC |1 1 1 1 0 0 0 0|0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Originator Address |		| Originator Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Hop Limit | Hop Count | Message Sequence Number |		| Hop Limit | Hop Count | Message Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 0 1 0 0 0|		|0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1| VALIDITY_TIME |0 0 0 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 0 1 0 0 0|		|0 0 0 0 0 0 0 1| Value | INTERVAL_TIME |0 0 0 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 0 1 0 0 0|		|0 0 0 0 0 0 0 1| Value | CONT_SEQ_NUM |0 0 0 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 1 1 0|		|0 0 0 0 0 0 1 0| Value (ANSN) |0 0 0 0 0 1 1 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0| Head |		|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| Head |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mid | Mid |		| Mid | Mid |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mid | Mid |		| Mid | Mid |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Mid | Mid |		| Mid | Mid |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| LOCAL_IF |0 0 0 0 1 1 0 0|		|0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0| LOCAL_IF |0 0 1 1 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| UNSPEC_IF |		|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| UNSPEC_IF |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 0 0 1|0 0 0 0 1 1 0 1|0 0 0 0 0 0 1 0| Head |		|0 0 0 0 0 0 0 1|1 0 1 1 0 0 0 0|0 0 0 0 0 0 1 0| Head |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Head (cont) |0 0 0 0 0 0 1 0|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|		| Head (cont) |0 0 0 0 0 0 1 0|0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 0|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|0 0 0 0 0 1 0 0| GATEWAY |0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1|		|0 0 0 0 0 1 0 0| GATEWAY |0 0 0 1 0 0 0 0|0 0 0 0 0 0 0 1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Number Hops |		| Number Hops |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Appendix E. Constraints		Appendix E. Constraints
	Any process which updates the Local Information Base, the		Any process which updates the Local Information Base, the
	Neighborhood Information Base or the Topology Information Base MUST		Neighborhood Information Base or the Topology Information Base MUST
	ensure that all constraints specified in this appendix are		ensure that all constraints specified in this appendix are
	maintained, as well as those specified in [nhdp].		maintained, as well as those specified in [nhdp].
	skipping to change at page 75, line 14 ¶		skipping to change at page 76, line 14 ¶
	Appendix H. Acknowledgements		Appendix H. Acknowledgements
	The authors would like to acknowledge the team behind OLSRv1,		The authors would like to acknowledge the team behind OLSRv1,
	specified in RFC3626, including Anis Laouiti (INT, Paris), Pascale		specified in RFC3626, including Anis Laouiti (INT, Paris), Pascale
	Minet (INRIA, France), Laurent Viennot (INRIA, France), and Amir		Minet (INRIA, France), Laurent Viennot (INRIA, France), and Amir
	Qayyum (M.A. Jinnah University, Islamabad) for their contributions.		Qayyum (M.A. Jinnah University, Islamabad) 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: Li Li (CRC), Louise Lamont (CRC),		specification and its components (listed alphabetically): Khaldoun Al
	Joe Macker (NRL), Alan Cullen (BAE Systems), Khaldoun Al Agha (LRI),		Agha (LRI), Song-Yean Cho (LIX), Alan Cullen (BAE Systems), Louise
	Richard Ogier (SRI), Song-Yean Cho (LIX), Shubhranshu Singh (Samsung		Lamont (CRC), Li Li (CRC), Joe Macker (NRL), Richard Ogier (SRI),
	AIT), Charles E. Perkins, and the entire IETF MANET working group.		Charles E. Perkins (WiChorus), Shubhranshu Singh (Samsung AIT), 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. 54 change blocks.
	146 lines changed or deleted		183 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/