draft-ietf-manet-timetlv-04.txt		draft-ietf-manet-timetlv-05.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: May 19, 2008 BAE Systems Advanced Technology		Expires: January 11, 2009 BAE Systems Advanced Technology
	Centre		Centre
	November 16, 2007		July 10, 2008
	Representing multi-value time in MANETs		Representing multi-value time in MANETs
	draft-ietf-manet-timetlv-04		draft-ietf-manet-timetlv-05
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 May 19, 2008.		This Internet-Draft will expire on January 11, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes a general and flexible TLV (type-length-value		This document describes a general and flexible TLV (type-length-value
	structure) for representing time using the generalized MANET packet/		structure) for representing time using the generalized MANET packet/
	message format. It defines two message and two address block TLVs		message format. It defines two message and two address block TLVs
	for representing validity and interval times for MANET routing		for representing validity and interval times for MANET routing
	protocols.		protocols.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5		3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
	4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6		4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5
	5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 7		5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 5
	6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 8		6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 6
	7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.1. Single-value Time TLVs . . . . . . . . . . . . . . . . . . 7
	7.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10		6.2. Multi-value Time TLVs . . . . . . . . . . . . . . . . . . 8
	7.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10		7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11		7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 9
	8.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11		7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 9
	8.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 11		8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 9
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 9
	9.1. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12		8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
	9.2. Address Block TLV Types . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 14		9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 10
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 11
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 15		9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 11
	11.2. Informative References . . . . . . . . . . . . . . . . . . 15		10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17		11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . . 12
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The generalized packet/message format [1] specifies a signaling		The generalized packet/message format [packetbb] specifies a
	format which MANET routing protocols can employ for exchanging		signaling format which MANET routing protocols can employ for
	protocol information. This format presents the ability to express		exchanging protocol information. This format presents the ability to
	and associate attributes to packets, messages or addresses, by way of		express and associate attributes to packets, messages or addresses,
	a general TLV (type-length-value) mechanism.		by way of a general TLV (type-length-value) mechanism.
	This document specifies a general Time TLV structure, which can be		This document specifies a general Time TLV structure, which can be
	used by any MANET routing protocol that needs to express either		used by any MANET routing protocol that needs to express either
	single time-values or a set of time-values with each time-value		single time-values or a set of time-values with each time-value
	associated with a range of distances. Distances may be equated to		associated with a range of hop counts, as provided by the message
	hop count, as provided by [1]. This allows a receiving node to		header of [packetbb]. This allows a receiving node to determine a
	determine a single time-value if either it knows its distance from		single time-value if either it knows its hop count from the
	the originator node, or the Time TLV specifies a single time-value.		originator node, or the Time TLV specifies a single time-value.
	This document also specifies two message TLV types, which use the TLV		This document also specifies two message TLV types, which use the TLV
	structure proposed. These TLV types are INTERVAL_TIME and		structure proposed. These TLV types are INTERVAL_TIME and
	VALIDITY_TIME, specifying respectively the maximum time before		VALIDITY_TIME, specifying respectively the maximum time before
	another message of the same type as this message from the same		another message of the same type as this message from the same
	originator should be received, and the duration for which the		originator should be received, and the duration for which the
	information in this message is valid after receipt. Note that, if		information in this message is valid after receipt. Note that, if
	both are present, then the latter will usually be greater than the		both are present, then the latter will usually be greater than the
	former in order to allow for possible message loss.		former in order to allow for possible message loss.
	This document also specifies two address block TLV types, which use		This document also specifies two address block TLV types, which use
	the TLV structure proposed. These TLV types are INTERVAL_TIME and		the TLV structure proposed. These TLV types are INTERVAL_TIME and
	VALIDITY_TIME, defined equivalently to the two message TLVs with the		VALIDITY_TIME, defined equivalently to the two message TLVs with the
	same names.		same names.
			1.1. Motivation and Rationale
			The TLV mechanism as specified in [packetbb] allows associating a
			"value" to either a packet, a message or to addresses. The data
			structure for doing so - the TLV - is identical in each of the three
			cases, however the TLV's position in a received packet allows
			determining if that TLV is a "packet TLV" (it appears in the packet
			header, before any messages), a "message TLV" (it appears in the TLV
			block immediately following a message header) or an "address block
			TLV" (it appears in the TLV block immediately following an address
			block).
			While TLVs may be structurally identical, that which they express may
			be different. This is determined from the kind (packet, message or
			address block) and type of the TLV. For example one TLV might
			associate a lifetime to an address, another a content sequence number
			to a message, and another a cryptographic signature to a packet. For
			this reason, [packetbb] specifies separate registries for packet,
			message and address block TLV types, and does not specify any
			structure in the TLV value field.
			The TLVs defined in this document express, essentially, that "this
			information will be refreshed within X seconds" and that "this
			information is valid for X seconds after being received", each
			allowing the "X seconds" to be specified as a function of the number
			of hops from the originator of the information. This document
			specifies a general format allowing expressing and encoding this as
			the value field of a TLV. This representation uses a compact (8 bit)
			representation of time, as message size is an issue in many MANETs,
			and the offered precision and range is appropriate for MANET routing
			protocols.
			A TLV of this format may be used for packets, messages or addresses.
			For example, a proactive MANET routing protocol periodically
			reporting link state information could include a TLV of this format
			as a message TLV. This may indicate a different periodicity in
			different scopes (possibly frequently up to a few hops, less
			frequently beyond that) because some messages may be sent with
			limited scope, as specified in [packetbb]. A reactive MANET routing
			protocol could include a TLV of this format as an address block TLV
			for reporting the lifetime of routes to individual addresses.
			In addition to defining the general format as outlined above, this
			document requests IANA assignments for INTERVAL_TIME and
			VALIDITY_TIME TLVs. These IANA assignments are requested in this
			document in order to avoid interdependencies between otherwise
			unrelated MANET protocols and in order to not exhaust the TLV type
			spaces by having different protocols request types for essentially
			identical data structures. Only message and address block TLVs are
			requested, as these are those for which a need has been demonstrated.
	2. Terminology		2. Terminology
	The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The keywords "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 [2].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	Additionally, this document uses terminology from [1], and introduces		Additionally, this document uses terminology from [packetbb], and
	the following terminology:		introduces the following terminology:
	Distance - the distance from the message originator to the message		hop count - the number of hops from the message originator to the
	recipient. If the distance is equated to the messages hop count,		message recipient. This is defined to equal the <hop-count> field
	then this may be indicated using the <hop-count> field in the full		in the <msg-header> element defined in [packetbb], if present,
	message header defined in [1], after being incremented on		after it is incremented on reception. If the <hop-count> field is
	reception.		not present, or in a packet TLV, then hop count is defined to
			equal 255.
	Time-value - a time, measured in seconds.		time-value - a time, measured in seconds.
	Time-code - an 8 bit field, representing a time-value.		time-code - an 8 bit field, representing a time-value.
	3. Applicability Statement		3. Applicability Statement
	The TLV described in this document is applicable whenever a single		The TLV structure described in this document is applicable whenever a
	time-value, or a time-value that varies with distance from the		single time-value, or a time-value that varies with the number of
	originator of a message, is required in a protocol using the		hops from the originator of a message, is required in a protocol
	generalized MANET packet/message format [1].		using the generalized MANET packet/message format [packetbb].
	Examples of time-values that may be included in a protocol message		Examples of time-values that may be included in a protocol message
	are:		are:
	o The maximum time interval until the next message of the same type		o The maximum time interval until the next message of the same type
	is to be generated by the message's originator node.		is to be generated by the message's originator node.
	o The validity time of the information with which the time-value is		o The validity time of the information with which the time-value is
	associated.		associated.
	Either of these may vary with the distance between the originating		Either of these may vary with the hop count between the originating
	and receiving nodes, e.g. if messages of the same type are sent with		and receiving nodes, e.g. if messages of the same type are sent with
	different hop limits as defined in [1].		different hop limits as defined in [packetbb].
	Parts of this document have been generalized from material in the		Parts of this document have been generalized from material in the
	proactive MANET routing protocol OLSR (The Optimized Link State		proactive MANET routing protocol OLSR (The Optimized Link State
	Routing Protocol) [4].		Routing Protocol) [RFC3626].
	4. Protocol Overview and Functioning		4. Protocol Overview and Functioning
	This document does not specify a protocol nor does it mandate		This document does not specify a protocol nor does it mandate
	specific node or protocol behavior. Rather, it outlines mechanisms		specific node or protocol behavior. Rather, it outlines mechanisms
	for encoding time-values using the TLV mechanism of [1].		for encoding time-values using the TLV mechanism of [packetbb].
	5. Representing Time		5. Representing Time
	This document specifies a TLV structure in which time-values are each		This document specifies a TLV structure in which time-values are each
	represented in an 8 bit time-code, one or more of which may be used		represented in an 8 bit time-code, one or more of which may be used
	in a TLV's <value> field. Of these 8 bits, the least significant 3		in a TLV's <value> field. Of these 8 bits, the least significant 3
	bits represent the mantissa (a), and the most significant 5 bits		bits represent the mantissa (a), and the most significant 5 bits
	represent the exponent (b), so that:		represent the exponent (b), so that:
	o time-value = (1 + a/8) * 2^b * C		o time-value = (1 + a/8) * 2^b * C
	o time-code = 8 * b + a		o time-code = 8 * b + a
			All nodes in the MANET MUST use the same value of the constant C,
	All nodes in the network MUST use the same value of the constant C,
	which will be specified in seconds, hence so will be all time-values.		which will be specified in seconds, hence so will be all time-values.
	C MUST be greater than 0 seconds. Note that ascending values of the		C MUST be greater than 0 seconds. Note that ascending values of the
	time-code represent ascending time-values, time-values may thus be		time-code represent ascending time-values, time-values may thus be
	compared by comparison of time-codes.		compared by comparison of time-codes.
	An algorithm for computing the time-code representing the smallest		An algorithm for computing the time-code representing the smallest
	representable time-value not less than the time-value t is:		representable time-value not less than the time-value t is:
	1. find the largest integer b such that t/C >= 2^b;		1. find the largest integer b such that t/C >= 2^b;
	skipping to change at page 8, line 7		skipping to change at page 6, line 37
	second, then this is about 45 days.		second, then this is about 45 days.
	A protocol using this time representation MUST define the value of C.		A protocol using this time representation MUST define the value of C.
	A protocol using this specification MAY specify that the all bits		A protocol using this specification MAY specify that the all bits
	zero time-value (0) represents a time-value of zero and/or that the		zero time-value (0) represents a time-value of zero and/or that the
	all bits one time-value (255) represents an indefinitely large time-		all bits one time-value (255) represents an indefinitely large time-
	value.		value.
	6. General Time TLV Structure		6. General Time TLV Structure
	A Time TLV may be a packet, message or address block TLV. If it is a		The following data structure allows the representation of a single
	packet or message TLV then it must be a single value TLV as defined		time-value, or of a default time-value plus pairs of (time-values,
	in [1]. If it is an address block TLV then it may be single value or		hop counts) for when hop count dependent time-values are required.
	multivalue TLV. Note that even a single value Time TLV may contain a		The time-values are represented as time-codes as defined in
	multiple octet <value> field.		Section 5. This <time-data> data structure is specified, using the
			regular expression syntax of [packetbb], by:
			<time-data> = (<time-code><hop count>)*<time-code>
			where:
			<time-code> is an 8 bit unsigned integer field containing a time-
			code as defined in Section 5.
			<hop count> is an 8 bit unsigned integer field specifying a hop
			count from the message originator.
			A <time-data> structure thus consists of an odd number of octets;
			with a repetition factor of n for the (time, hop count) pairs in the
			regular expression syntax, it contains 2n+1 octets. On reception, n
			is determined from the length.
			A <time-data> field may be thus represented by:
			<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default>
			<d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence,
			with <d_n> < 255. Then, at the receiving node's hop count from the
			originator node, the time-value indicated is that represented by the
			time-code:
			o <t_1>, if n > 0 and hop count <= <d_1>;
			o <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such
			that 1 <= i < n;
			o <t_default> otherwise, i.e. if n == 0 or hop count > <d_n>.
			If included in a message without a <hop-count> field in its message
			header, or in a packet TLV, then the form of this data structure with
			a single time-code in <time-data> (i.e. n == 0) SHOULD be used.
			6.1. Single-value Time TLVs
	The purpose of a single value Time TLV is to allow a single time-		The purpose of a single value Time TLV is to allow a single time-
	value to be determined by a node receiving an entity containing the		value to be determined by a node receiving an entity containing the
	Time TLV, based on its distance from the entity's originator. The		Time TLV, based on its hop count from the entity's originator. The
	Time TLV may contain information that allows that time-value to be a		Time TLV may contain information that allows that time-value to be a
	function of distance, and thus different receiving nodes may		function of the hop count, and thus different receiving nodes may
	determine different time-values. If a receiving node will not be		determine different time-values.
	able to determine its distance from the originating node, then the
	form of this Time TLV with a single time-code in a <value> field (or
	single value subfield) SHOULD be used.
	The <value> field of a single value Time TLV is specified, using the		A single-value Time TLV may be a packet TLVs, a message TLV or an
	regular expression syntax of [1], by:		address block TLV.
	<value> = {<time><distance>}*<time>		A Time TLV which has the tismultivalue flag cleared ('0') in its
			<tlv-flags> field, as defined in [packetbb], contains a single <time-
			data>, as defined above, in its <value> field. For such a Time TLV:
	where:		o The <length> field in the TLV MUST contain the value 2n+1, with n
			being the number of (time-value, hop count) pairs in the Time TLV.
	<time> is an 8 bit field containing a time-code as defined in		o The number of (time-value, hop count) pairs MUST be identified by
	Section 5.		inspecting the <length> field in the TLV. The number of such
			pairs, n, is:
	<distance> is an 8 bit field specifying a distance from the message		* n = (<length> - 1) / 2
	originator.
	A single value <value> field thus consists of an odd number of		This MUST be an integer value.
	octets; with a repetition factor of n for the (time, distance) pairs
	in the regular expression syntax it contains 2n+1 octets, thus the
	<length> field of a single value Time TLV, which MUST always be
	present, is given by:
	o <length> = 2n+1		6.2. Multi-value Time TLVs
	A single value <value> field may be thus represented by:		The purpose of a multi-value Time TLV is to associate a set of <time-
			data> structures to an identically sized set of addresses, as
			described in [packetbb]. For each of these <time-data> structures, a
			single time-value can be determined by a node receiving an entity
			containing the Time TLV, based on its hop count from the entity's
			originator. The Time TLV may contain information that allows that
			time-value to be a function of the hop count, and thus different
			receiving nodes may determine different time-values.
	<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default>		Multi-value Time TLVs MUST be address block TLVs. A multi-value Time
			TLV MUST NOT be a packet or message TLV.
	<d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence.		A Time TLV which has the tismultivalue flag set ('1') in its <tlv-
	Then, at the receiving node's distance from the originator node, the		flags> field, as defined in [packetbb], contains a sequence of <time-
	time-value indicated is that represented by the time-code:		data> structures, as defined above, in its <value> field. For such a
			Time TLV:
	o <t_1>, if n > 0 and distance <= <d_1>;		o The <length> field in the TLV MUST contain the value m * (2n+1),
			with n being the number of (time-value, hop count) pairs in the
			Time TLV, and m being number-values as defined in [packetbb].
	o <t_i+1>, if n > 1 and <d_i> < distance <= <d_i+1> for some i such		o The number of <time-data> structures included in the <value> field
	that 1 <= i < n;		is equal to number-values as defined in [packetbb].
	o <t_default> otherwise, i.e. if n == 0 or distance > <d_n>.		o The number of (time-value, hop count) pairs in each <time-data>
			structure MUST be the same, and MUST be identified by inspecting
			the <length> field in the TLV and using number-values as defined
			in [packetbb]. The number of such pairs in each <time-data>
			structure, n, is:
	In a multivalue Time TLV, each single value subfield of the		* n = ((<length> / number-values) - 1) / 2
	multivalue Time TLV is defined as above. Note that [1] requires that
	each single value subfield has the same length (i.e. the same value		This MUST be an integer value. The lists of hop count values MAY
	of n) but they need not use the same values of <d_1> to <d_n>.		be different.
	7. Message TLVs		7. Message TLVs
	Two message TLVs are defined, for signaling message validity time		Two message TLVs are defined, for signaling message interval
	(VALIDITY_TIME) and message interval (INTERVAL_TIME).		(INTERVAL_TIME) and message validity time (VALIDITY_TIME).
	7.1. VALIDITY_TIME TLV		7.1. INTERVAL_TIME TLV
			An INTERVAL_TIME TLV is a message TLV that defines the maximum time
			before another message of the same type as this message from the same
			originator should be received. This interval time MAY be specified
			to depend on the hop count from the originator. (This is appropriate
			if messages are sent with different hop limits, so that receiving
			nodes at greater hop counts have an increased interval time.)
			A message MUST NOT include more than one INTERVAL_TIME TLV.
			An INTERVAL_TIME TLV is an example of a Time TLV specified as in
			Section 5.
			7.2. VALIDITY_TIME TLV
	A VALIDITY_TIME TLV is a message TLV that defines the validity time		A VALIDITY_TIME TLV is a message TLV that defines the validity time
	of the information carried in the message in which the TLV is		of the information carried in the message in which the TLV is
	contained. After this time the receiving node MUST consider the		contained. After this time the receiving node MUST consider the
	message content to no longer be valid (unless repeated in a later		message content to no longer be valid (unless repeated in a later
	message). The validity time of a message MAY be specified to depend		message). The validity time of a message MAY be specified to depend
	on the distance from its originator. (This is appropriate if		on the hop count from its originator. (This is appropriate if
	messages are sent with different hop limits, so that receiving nodes		messages are sent with different hop limits, so that receiving nodes
	at greater distances receive information less frequently and must		at greater hop counts receive information less frequently and must
	treat is as valid for longer.)		treat is as valid for longer.)
	A message MUST NOT include more than one VALIDITY_TIME TLV.		A message MUST NOT include more than one VALIDITY_TIME TLV.
	A VALIDITY_TIME TLV is an example of a Time TLV specified as in		A VALIDITY_TIME TLV is an example of a Time TLV specified as in
	Section 5.		Section 5.
	7.2. INTERVAL_TIME TLV		8. Address Block TLVs
	An INTERVAL_TIME TLV is a message TLV that defines the maximum time		Two address block TLVs are defined, for signaling address
	before another message of the same type as this message from the same		advertisement interval (INTERVAL_TIME) and address validity time
	originator should be received. This interval time MAY be specified		(VALIDITY_TIME).
	to depend on the distance from the originator. (This is appropriate
	if messages are sent with different hop limits, so that receiving
	nodes at greater distances have an increased interval time.)
	A message MUST NOT include more than one INTERVAL_TIME TLV.		8.1. INTERVAL_TIME TLV
	An INTERVAL_TIME TLV is an example of a Time TLV specified as in		An INTERVAL_TIME TLV is an address block TLV that defines the maximum
	Section 5.		time before this address from the same originator should be received
			again. This interval time MAY be specified to depend on the hop
			count from the originator. (This is appropriate if addresses are
			contained in messages sent with different hop limits, so that
			receiving nodes at greater hop counts have an increased interval
			time.)
	8. Address Block TLVs		A protocol using this TLV and the similarly named message TLV MUST
			specify how to interpret the case when both are present (typically
			that the former over-rides the latter for those addresses which are
			covered by the former).
	Two address block TLVs are defined, for signaling address validity		An INTERVAL_TIME TLV is an example of a Time TLV specified as in
	time (VALIDITY_TIME) and address advertisement interval		Section 5.
	(INTERVAL_TIME).
	8.1. VALIDITY_TIME TLV		8.2. VALIDITY_TIME TLV
	A VALIDITY_TIME TLV is an address block TLV that defines the validity		A VALIDITY_TIME TLV is an address block TLV that defines the validity
	time of the addresses to which the TLV is associated. After this		time of the addresses to which the TLV is associated. After this
	time the receiving node MUST consider the addresses to no longer be		time the receiving node MUST consider the addresses to no longer be
	valid (unless these are repeated in a later message). The validity		valid (unless these are repeated in a later message). The validity
	time of an address MAY be specified to depend on the distance from		time of an address MAY be specified to depend on the hop count from
	its originator. (This is appropriate if addresses are contained in		its originator. (This is appropriate if addresses are contained in
	messages sent with different hop limits, so that receiving nodes at		messages sent with different hop limits, so that receiving nodes at
	greater distances receive information less frequently and must treat		greater hop counts receive information less frequently and must treat
	is as valid for longer.)		is as valid for longer.)
	A protocol using this TLV and the similarly named message TLV MUST		A protocol using this TLV and the similarly named message TLV MUST
	specify how to interpret the case when both are present (typically		specify how to interpret the case when both are present (typically
	that the former over-rides the latter for those addresses which are		that the former over-rides the latter for those addresses which are
	covered by the former).		covered by the former).
	A VALIDITY_TIME TLV is an example of a Time TLV specified as in		A VALIDITY_TIME TLV is an example of a Time TLV specified as in
	Section 5.		Section 5.
	8.2. INTERVAL_TIME TLV
	An INTERVAL_TIME TLV is an address block TLV that defines the maximum
	time before this address from the same originator should be received.
	This interval time MAY be specified to depend on the distance from
	the originator. (This is appropriate if addresses are contained in
	messages sent with different hop limits, so that receiving nodes at
	greater distances have an increased interval time.)
	A protocol using this TLV and the similarly named message TLV MUST
	specify how to interpret the case when both are present (typically
	that the former over-rides the latter for those addresses which are
	covered by the former).
	An INTERVAL_TIME TLV is an example of a Time TLV specified as in
	Section 5.
	9. IANA Considerations		9. IANA Considerations
	This specification defines two message TLV types, which must be		This specification defines two message TLV types, which must be
	allocated from the "Assigned Message TLV Types" repository of [1] as		allocated from the "Assigned Message TLV Types" repository of
	specified in Table 1 and two address block TLV types, which must be		[packetbb] as specified in Table 1 and two address block TLV types,
	allocated from the "Assigned Address Block TLV Types" repository of		which must be allocated from the "Assigned Address Block TLV Types"
	[1] as specified in Table 2.		repository of [packetbb] as specified in Table 2.
	IANA is requested to assign the same numerical value to the message		IANA is requested to assign the same numerical value to the message
	TLV and address block TLV types with the same mnemonic.		TLV and address block TLV types with the same name.
	9.1. Message TLV Types		9.1. Expert Review: Evaluation Guidelines
			For the registries for TLV type extensions where an Expert Review is
			required, the designated expert SHOULD take the same general
			recommendations into consideration as are specified by [packetbb].
			9.2. Message TLV Types
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	| Name | Type | Type | Description |		| Name | Type | Type | Description |
	| | | Extension | |		| | | Extension | |
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	| VALIDITY_TIME | TBD1 | 0 | The time from receipt of the |		| INTERVAL_TIME | TBD1 | 0 | The maximum time before |
	| | | | message during which the |
	| | | | information contained in the |
	| | | | message is to be considered |
	| | | | valid |
	| | | | |
	| | | 1-255 | RESERVED |
	| | | | |
	| INTERVAL_TIME | TBD2 | 0 | The maximum time before |
	| | | | another message of the same |		| | | | another message of the same |
	| | | | type as this message from the |		| | | | type as this message from the |
	| | | | same originator should be |		| | | | same originator should be |
	| | | | received |		| | | | received |
	| | | | |		| | | 1-223 | Expert Review |
	| | | 1-255 | RESERVED |		| | | 224-255 | Experimental Use |
			| VALIDITY_TIME | TBD2 | 0 | The time from receipt of the |
			| | | | message during which the |
			| | | | information contained in the |
			| | | | message is to be considered |
			| | | | valid |
			| | | 1-223 | Expert Review |
			| | | 224-255 | Experimental Use |
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	Table 1		Table 1
	Type extensions indicated as RESERVED may be allocated by standards		9.3. Address Block TLV Types
	action, as specified in [3].
	9.2. Address Block TLV Types
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	| Name | Type | Type | Description |		| Name | Type | Type | Description |
	| | | extension | |		| | | extension | |
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	| VALIDITY_TIME | TBD1 | 0 | The time from receipt of the |		| INTERVAL_TIME | TBD1 | 0 | The maximum time before |
	| | | | address during which the |
	| | | | information regarding this |
	| | | | address is to be considered |
	| | | | valid |
	| | | | |
	| | | 1-255 | RESERVED |
	| | | | |
	| INTERVAL_TIME | TBD2 | 0 | The maximum time before |
	| | | | another message of the same |		| | | | another message of the same |
	| | | | type as this message from the |		| | | | type as this message from the |
	| | | | same originator and containing |		| | | | same originator and containing |
	| | | | this address should be |		| | | | this address should be |
	| | | | received |		| | | | received |
	| | | | |		| | | 1-223 | Expert Review |
	| | | 1-255 | RESERVED |		| | | 224-255 | Experimental Use |
			| VALIDITY_TIME | TBD2 | 0 | The time from receipt of the |
			| | | | address during which the |
			| | | | information regarding this |
			| | | | address is to be considered |
			| | | | valid |
			| | | 1-223 | Expert Review |
			| | | 224-255 | Experimental Use |
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	Table 2		Table 2
	Type extensions indicated as RESERVED may be allocated by standards
	action, as specified in [3].
	10. Security Considerations		10. Security Considerations
	This document does not specify any security considerations.		This document does not specify any security considerations.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	MANET Packet/Message Format", Work In		Requirement Levels", RFC 2119, BCP 14, March 1997.
	Progress draft-ietf-manet-packetbb-11.txt, November 2007.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, BCP 14, March 1997.
	[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA		[packetbb] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
	Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.		"Generalized MANET Packet/Message Format",
			draft-ietf-manet-packetbb-13.txt (work in progress),
			June 2008.
	11.2. Informative References		11.2. Informative References
	[4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing		[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
	Protocol", RFC 3626, October 2003.		Routing Protocol", RFC 3626, October 2003.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The authors would like to thank Brian Adamson and Justin Dean (both		The authors would like to thank Brian Adamson and Justin Dean (both
	NRL) for their contributions, and Alan Cullen (BAE Systems) for his		NRL) and Ian Chakeres (Motorola) for their contributions, and Alan
	careful review of this specification.		Cullen (BAE Systems) for his careful review of this specification.
	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/
	Christopher Dearlove		Christopher Dearlove
	BAE Systems Advanced Technology Centre		BAE Systems Advanced Technology Centre
	Phone: +44 1245 242194		Phone: +44 1245 242194
	Email: chris.dearlove@baesystems.com		EMail: chris.dearlove@baesystems.com
	URI: http://www.baesystems.com/		URI: http://www.baesystems.com/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	skipping to change at page 18, line 44		skipping to change at line 582
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 69 change blocks.
	185 lines changed or deleted		281 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/