draft-ietf-manet-timetlv-05.txt		draft-ietf-manet-timetlv-06.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: January 11, 2009 BAE Systems Advanced Technology		Expires: February 2, 2009 BAE Systems Advanced Technology
	Centre		Centre
	July 10, 2008		August 1, 2008
	Representing multi-value time in MANETs		Representing multi-value time in MANETs
	draft-ietf-manet-timetlv-05		draft-ietf-manet-timetlv-06
	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 January 11, 2009.		This Internet-Draft will expire on February 2, 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 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
	skipping to change at page 4, line 48		skipping to change at page 4, line 48
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	Additionally, this document uses terminology from [packetbb], and		Additionally, this document uses terminology from [packetbb], and
	introduces the following terminology:		introduces the following terminology:
	hop count - the number of hops from the message originator to the		hop count - the number of hops from the message originator to the
	message recipient. This is defined to equal the <hop-count> field		message recipient. This is defined to equal the <msg-hop-count>
	in the <msg-header> element defined in [packetbb], if present,		field in the <msg-header> element defined in [packetbb], if
	after it is incremented on reception. If the <hop-count> field is		present, after it is incremented on reception. If the <msg-hop-
	not present, or in a packet TLV, then hop count is defined to		count> field is not present, or in a packet TLV, then hop count is
	equal 255.		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 structure described in this document is applicable whenever a		The TLV structure described in this document is applicable whenever a
	single time-value, or a time-value that varies with the number of		single time-value, or a time-value that varies with the number of
	hops from the originator of a message, is required in a protocol		hops from the originator of a message, is required in a protocol
	skipping to change at page 7, line 29		skipping to change at page 7, line 29
	originator node, the time-value indicated is that represented by the		originator node, the time-value indicated is that represented by the
	time-code:		time-code:
	o <t_1>, if n > 0 and hop count <= <d_1>;		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		o <t_i+1>, if n > 1 and <d_i> < hop count <= <d_i+1> for some i such
	that 1 <= i < n;		that 1 <= i < n;
	o <t_default> otherwise, i.e. if n == 0 or hop count > <d_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		If included in a message without a <msg-hop-count> field in its
	header, or in a packet TLV, then the form of this data structure with		message header, or in a packet TLV, then the form of this data
	a single time-code in <time-data> (i.e. n == 0) SHOULD be used.		structure with a single time-code in <time-data> (i.e. n == 0) SHOULD
			be used.
	6.1. Single-value Time TLVs		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 hop count 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 the hop count, and thus different receiving nodes may		function of the hop count, and thus different receiving nodes may
	determine different time-values.		determine different time-values.
	skipping to change at page 12, line 7		skipping to change at page 12, line 7
	| | | | address is to be considered |		| | | | address is to be considered |
	| | | | valid |		| | | | valid |
	| | | 1-223 | Expert Review |		| | | 1-223 | Expert Review |
	| | | 224-255 | Experimental Use |		| | | 224-255 | Experimental Use |
	+---------------+------+-----------+--------------------------------+		+---------------+------+-----------+--------------------------------+
	Table 2		Table 2
	10. Security Considerations		10. Security Considerations
	This document does not specify any security considerations.		This document specifies how to add data structures (TLVs) which
			provide timing information to packets and messages specified using
			[packetbb]. In particular, information validity durations and
			reporting intervals may be added.
			The general security threats that apply are those general to
			[packetbb] and described therein, problems of integrity and
			confidentiality. With regard to the former, modification of a time
			TLV can cause information to have an invalid validity time, or
			expected interval time. This may cause incorrect protocol
			performance. Modification or addition of timed information can add
			to a protocol's workload (especially if a short validity time is
			specified) and storage requirements (especially if a long validity
			time is specified).
			To counter these threats, the security suggestions in [packetbb], for
			the use of authentication and encryption, are appropriate.
	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-13.txt (work in progress),		draft-ietf-manet-packetbb-14.txt (work in progress),
	June 2008.		August 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
	NRL) and Ian Chakeres (Motorola) for their contributions, and Alan		NRL) and Ian Chakeres (Motorola) for their contributions, and Alan
End of changes. 8 change blocks.
	15 lines changed or deleted		32 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/