draft-ietf-manet-timetlv-07.txt		draft-ietf-manet-timetlv-08.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: March 20, 2009 BAE Systems Advanced Technology		Expires: March 30, 2009 BAE Systems Advanced Technology
	Centre		Centre
	September 16, 2008		September 26, 2008
	Representing multi-value time in MANETs		Representing multi-value time in MANETs
	draft-ietf-manet-timetlv-07		draft-ietf-manet-timetlv-08
	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 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 March 20, 2009.		This Internet-Draft will expire on March 30, 2009.
	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-values, such as an interval or a
	message format. It defines two message and two address block TLVs		duration, using the generalized MANET packet/message format. It
	for representing validity and interval times for MANET routing		defines two message and two address block TLVs for representing
	protocols.		validity and interval times for MANET routing protocols.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3		1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5		3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5		4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
	5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 5		5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6
	6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 6		6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7
	6.1. Single-value Time TLVs . . . . . . . . . . . . . . . . . . 7		6.1. Single-value Time TLVs . . . . . . . . . . . . . . . . . . 8
	6.2. Multi-value Time TLVs . . . . . . . . . . . . . . . . . . 8		6.2. Multi-value Time TLVs . . . . . . . . . . . . . . . . . . 9
	7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 9		7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
	7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 9		7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
	8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 9		8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 9		8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
	8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10		8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 10		9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11
	9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 11		9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12
	9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 11		9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 12		10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	11.2. Informative References . . . . . . . . . . . . . . . . . . 12		11.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The generalized packet/message format [packetbb] specifies a		The generalized packet/message format [packetbb] specifies a
	signaling format which MANET routing protocols can employ for		signaling format which MANET routing protocols can employ for
	exchanging protocol information. This format presents the ability to		exchanging protocol information. This format presents the ability to
	express and associate attributes to packets, messages or addresses,		express and associate attributes to packets, messages or addresses,
	by way of 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 hop counts, as provided by the message		associated with a range of hop counts, as provided by the message
	header of [packetbb]. This allows a receiving node to determine a		header of [packetbb]. This allows a receiving node to determine a
	single time-value if either it knows its hop count from the		single time-value if either it knows its hop count from the
	originator node, or the Time TLV specifies a single time-value.		originator node, or the Time TLV specifies a single time-value.
			A time-value is, in this context, not an "absolute point in time",
			but rather an interval or a duration. An instance of a Time TLV can,
			therefore, express an interval or a duration such as "10 seconds".
	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		1.1. Motivation and Rationale
			The Time TLV structure, specified in this document, is intended to be
			used as a component in a MANET routing protocol, e.g. to indicate the
			expected spacing between successive transmissions of a given message
			type, by including a Time TLV in transmitted messages.
			Some MANET routing protocols may employ very short spacing for some
			messages and very long spacing for others, or may change the message
			transmission rate according to observed behavior. For example, if a
			network is observed at some point in time to exhibit a highly dynamic
			topology, a very short (sub-second) message spacing could be
			appropriate, whereas if the network later is observed to stabilize,
			multi-hour message spacing may become appropriate. Different MANET
			routing protocols and different deployments of MANET routing
			protocols may have different granularity requirement and bounds on
			shortest and longest spacing between successive message
			transmissions.
			In addition, MANET routing protocol deployments typically use
			bandwidth limited wireless network interfaces, and therefore prefer
			to trade off computational complexity for a saving in the number of
			bits transmitted. This is practical in this case, because the
			intended usages of Time TLVs, including the specified examples of
			message interval time and information validity time, do not require
			high precision values of time.
			The Time TLV structure, specified in this document, caters to these
			characteristics by:
			o encoding time-values, such as an interval or a duration, in an 8
			bit field; while
			o allowing these time-values to range from "very small" (e.g. 1/1024
			second) to "very long" (e.g. 45 days); and
			o allowing a MANET routing protocol, or a deployment, to parametrize
			this (e.g. to attain finer granularity at the expense of a lower
			upper bound) through a single parameter, C.
			The parameter C must be the same for all MANET routers in the same
			deployment.
	The TLV mechanism as specified in [packetbb] allows associating a		The TLV mechanism as specified in [packetbb] allows associating a
	"value" to either a packet, a message or to addresses. The data		"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		structure for doing so - the TLV - is identical in each of the three
	cases, however the TLV's position in a received packet allows		cases, however the TLV's position in a received packet allows
	determining if that TLV is a "packet TLV" (it appears in the packet		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		header, before any messages), a "message TLV" (it appears in the TLV
	block immediately following a message header) or an "address block		block immediately following a message header) or an "address block
	TLV" (it appears in the TLV block immediately following an address		TLV" (it appears in the TLV block immediately following an address
	block).		block).
	skipping to change at page 6, line 44		skipping to change at page 7, line 43
	6. General Time TLV Structure		6. General Time TLV Structure
	The following data structure allows the representation of a single		The following data structure allows the representation of a single
	time-value, or of a default time-value plus pairs of (time-values,		time-value, or of a default time-value plus pairs of (time-values,
	hop counts) for when hop count dependent time-values are required.		hop counts) for when hop count dependent time-values are required.
	The time-values are represented as time-codes as defined in		The time-values are represented as time-codes as defined in
	Section 5. This <time-data> data structure is specified, using the		Section 5. This <time-data> data structure is specified, using the
	regular expression syntax of [packetbb], by:		regular expression syntax of [packetbb], by:
	<time-data> = (<time-code><hop count>)*<time-code>		<time-data> = (<time-code><hop-count>)*<time-code>
	where:		where:
	<time-code> is an 8 bit unsigned integer field containing a time-		<time-code> is an 8 bit unsigned integer field containing a time-
	code as defined in Section 5.		code as defined in Section 5.
	<hop count> is an 8 bit unsigned integer field specifying a hop		<hop-count> is an 8 bit unsigned integer field specifying a hop
	count from the message originator.		count from the message originator.
	A <time-data> structure thus consists of an odd number of octets;		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		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		regular expression syntax, it contains 2n+1 octets. On reception, n
	is determined from the length.		is determined from the length.
	A <time-data> field may be thus represented by:		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>		<t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default>
	skipping to change at page 12, line 34		skipping to change at page 13, line 34
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[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",		"Generalized MANET Packet/Message Format",
	draft-ietf-manet-packetbb-15.txt (work in progress),		draft-ietf-manet-packetbb-16.txt (work in progress),
	September 2008.		September 2008.
	11.2. Informative References		11.2. Informative References
	[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State		[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
	Routing 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
End of changes. 11 change blocks.
	33 lines changed or deleted		78 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/