draft-ietf-manet-timetlv-00.txt		draft-ietf-manet-timetlv-01.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: October 22, 2007 BAE Systems Advanced Technology		Expires: December 31, 2007 BAE Systems Advanced Technology
	Centre		Centre
	April 20, 2007		June 29, 2007
	Representing multi-value time in MANETs		Representing multi-value time in MANETs
	draft-ietf-manet-timetlv-00		draft-ietf-manet-timetlv-01
	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 October 22, 2007.		This Internet-Draft will expire on December 31, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		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 TLVs for representing		message format. It defines two message TLVs for representing
	skipping to change at page 5, line 27		skipping to change at page 5, line 27
	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 distance 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 [1].
	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) [3].		Routing Protocol) [4].
	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 [1].
	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
	skipping to change at page 8, line 9		skipping to change at page 8, line 9
	not.		not.
	The minimum time-value that can be represented in this manner is C.		The minimum time-value that can be represented in this manner is C.
	The maximum time-value that can be represented in this manner is		The maximum time-value that can be represented in this manner is
	63488 * C.		63488 * C.
	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		A Time TLV may be a packet, message or address block TLV. If it is a
	packet or message TLV then it must be a single value TLV as defined		packet or message TLV then it must be a single value TLV as defined
	in [1]; if it is an address block TLV then it may be single value or		in [1]. If it is an address block TLV then it may be single value or
	multivalue TLV. The specific Time TLVs specified in this document,		multivalue TLV. The specific Time TLVs specified in this document,
	in Section 7 are message, and hence single value, TLVs. Note that		in Section 7 are message, and hence single value, TLVs. Note that
	even a single value Time TLV may contain a multiple octet <value>		even a single value Time TLV may contain a multiple octet <value>
	field.		field.
	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 distance 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 distance, and thus different receiving nodes may
	skipping to change at page 10, line 12		skipping to change at page 10, line 12
	each single value subfield has the same length (i.e. the same value		each single value subfield has the same length (i.e. the same value
	of n) but they need not use the same values of <d_1> to <d_n>.		of n) but they need not use the same values of <d_1> to <d_n>.
	7. Message TLVs		7. Message TLVs
	Two message TLVs are defined, for signaling message validity time		Two message TLVs are defined, for signaling message validity time
	(VALIDITY_TIME) and message interval (INTERVAL_TIME).		(VALIDITY_TIME) and message interval (INTERVAL_TIME).
	7.1. VALIDITY_TIME TLV		7.1. 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 distance 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 distances 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 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		7.2. INTERVAL_TIME TLV
	An INTERVAL_TIME TLV is a message TLV that defines the maximum time		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		before another message of the same type as this message from the same
	originator should be received. This interval time MAY be specified		originator should be received. This interval time MAY be specified
	to depend on the distance from the originator. (This is appropriate		to depend on the distance from the originator. (This is appropriate
	if messages are sent with different hop limits, so that receiving		if messages are sent with different hop limits, so that receiving
	nodes at greater distances have an increased interval time.)		nodes at greater distances 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		An INTERVAL_TIME TLV is an example of a Time TLV specified as in
	Section 5.		Section 5.
	8. IANA Considerations		8. 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].		allocated from the "Assigned Message TLV Types" repository of [1] as
			specified in Table 1.
	+--------------------+-------+--------------------------------------+		+---------------+------+---------+----------------------------------+
	| Mnemonic | Value | Description |		| Name | Type | Subtype | Description |
	+--------------------+-------+--------------------------------------+		+---------------+------+---------+----------------------------------+
	| VALIDITY_TIME | TBD | The time from receipt of the message |		| VALIDITY_TIME | TBD | 0 | The time from receipt of the |
	| | | during which the information |		| | | | message during which the |
	| | | contained in the message is to be |		| | | | information contained in the |
	| | | considered valid |		| | | | message is to be considered |
	| | | |		| | | | valid |
	| INTERVAL_TIME | TBD | The maximum time before another |		| | | | |
	| | | message of the same type as this |		| | | 1-255 | RESERVED |
	| | | message from the same originator |		| | | | |
	| | | should be received |		| INTERVAL_TIME | TBD | 0 | The maximum time before another |
	+--------------------+-------+--------------------------------------+		| | | | message of the same type as this |
			| | | | message from the same originator |
			| | | | should be received |
			| | | | |
			| | | 1-255 | RESERVED |
			+---------------+------+---------+----------------------------------+
	Table 1		Table 1
			Subtypes indicated as RESERVED may be allocated by standards action,
			as specified in [3].
	9. Security Considerations		9. Security Considerations
	This document does not specify any security considerations.		This document does not specify any security considerations.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized		[1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized
	MANET Packet/Message Format", Work In		MANET Packet/Message Format", Work In
	Progress draft-ietf-manet-packetbb-04.txt, January 2007.		Progress draft-ietf-manet-packetbb-07.txt, June 2007.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", RFC 2119, BCP 14, March 1997.		Levels", RFC 2119, BCP 14, March 1997.
			[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
			Considerations Section in RFCs", October 1998.
	10.2. Informative References		10.2. Informative References
	[3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing		[4] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
	Protocol", RFC 3626, October 2003.		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) for their contributions, and Alan Cullen (BAE Systems) for his
	careful review of this specification.		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 M. 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 (2007).
End of changes. 17 change blocks.
	25 lines changed or deleted		41 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/