draft-ietf-manet-timetlv-01.txt		draft-ietf-manet-timetlv-02.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 31, 2007 BAE Systems Advanced Technology		Expires: February 25, 2008 BAE Systems Advanced Technology
	Centre		Centre
	June 29, 2007		August 24, 2007
	Representing multi-value time in MANETs		Representing multi-value time in MANETs
	draft-ietf-manet-timetlv-01		draft-ietf-manet-timetlv-02
	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 December 31, 2007.		This Internet-Draft will expire on February 25, 2008.
	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 and two address block TLVs
	validity and interval times for MANET routing protocols.		for representing validity and interval times for MANET routing
			protocols.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 6
	5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 7		5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 7
	6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 8		6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 8
	7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10		7.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
	7.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10		7.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		8.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . . 13		9.1. Message TLV tyepes . . . . . . . . . . . . . . . . . . . . 12
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14		9.2. Address Block TLV tyepes . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15		10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
			11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
			11.2. Informative References . . . . . . . . . . . . . . . . . . 15
			Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The generalized packet/message format [1] specifies a signaling		The generalized packet/message format [1] specifies a signaling
	format which MANET routing protocols can employ for exchanging		format which MANET routing protocols can employ for exchanging
	protocol information. This format presents the ability to express		protocol information. This format presents the ability to express
	and associate attributes to packets, messages or addresses, by way of		and associate attributes to packets, messages or addresses, by way of
	a general TLV (type-length-value) mechanism.		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
	skipping to change at page 4, line 5		skipping to change at page 3, line 30
	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
			the TLV structure proposed. These TLV types are INTERVAL_TIME and
			VALIDITY_TIME, defined equivalently to the two message TLVs with the
			same names.
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [2].		document are to be interpreted as described in RFC2119 [2].
	Additionally, this document uses terminology from [1], and introduces		Additionally, this document uses terminology from [1], and introduces
	the following terminology:		the following terminology:
	Distance - the distance from the message originator to the message		Distance - the distance from the message originator to the message
	skipping to change at page 7, line 9		skipping to change at page 7, line 9
	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
	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		in a TLV's <value> field. Of these 8 bits, the least significant 3
	four bits represent the mantissa (a), and the most significant four		bits represent the mantissa (a), and the most significant 5 bits
	bits represent the exponent (b), so that:		represent the exponent (b), so that:
	o time-value = (1 + a/16) * 2^b * C		o time-value = (1 + a/8) * 2^b * C
	o time-code = 16 * b + a		o time-code = 8 * b + a
	All nodes in the network 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;
	2. set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest		2. set a = 8 * (t / (C * 2^b) - 1), rounded up to the nearest
	integer;		integer;
	3. if a == 16 then set b = b + 1 and set a = 0;		3. if a == 8 then set b = b + 1 and set a = 0;
	4. if a and b are in the range 0 and 15 then the required time-value		4. if 0 <= a <= 7, and 0 lt;= b <= 31, then the required time-value
	can be represented by the time-code 16 * b + a, otherwise it can		can be represented by the time-code 8 * b + a, otherwise it can
	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 15 *
	63488 * C.		2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024
			second, then this is about 45 days.
			A protocol using this time representation MUST define the value of C.
			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
			all bits one time-value (255) represents an indefinitely large time-
			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		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. Note that even a single value Time TLV may contain a
	in Section 7 are message, and hence single value, TLVs. Note that		multiple octet <value> field.
	even a single value Time TLV may contain a multiple octet <value>
	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
	determine different time-values. If a receiving node will not be		determine different time-values. If a receiving node will not be
	able to determine its distance from the originating node, then the		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		form of this Time TLV with a single time-code in a <value> field (or
	single value subfield) SHOULD be used.		single value subfield) SHOULD be used.
	skipping to change at page 11, line 5		skipping to change at page 11, line 5
	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.		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. Address Block TLVs
			Two address block TLVs are defined, for signaling address validity
			time (VALIDITY_TIME) and address advertisement interval
			(INTERVAL_TIME).
			8.1. VALIDITY_TIME TLV
			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 the receiving node MUST consider the addresses to no longer be
			valid (unless these are repeated in a later message). The validity
			time of an address MAY be specified to depend on the distance from
			its originator. (This is appropriate if addresses are contained in
			messages sent with different hop limits, so that receiving nodes at
			greater distances receive information less frequently and must treat
			is as valid for longer.)
			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).
			A VALIDITY_TIME TLV is an example of a Time TLV specified as in
			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
	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 [1] as
	specified in Table 1.		specified in Table 1 and two address block TLV types, which must be
			allocated from the "Assigned Address Block TLV Types" repository of
			[1] as specified in Table 2.
			IANA is requested to assign the same nummerical value to the message
			TLV and address block TLV types with the same mnemonic.
			9.1. Message TLV tyepes
	+---------------+------+---------+----------------------------------+		+---------------+------+---------+----------------------------------+
	| Name | Type | Subtype | Description |		| Name | Type | Subtype | Description |
	+---------------+------+---------+----------------------------------+		+---------------+------+---------+----------------------------------+
	| VALIDITY_TIME | TBD | 0 | The time from receipt of the |		| VALIDITY_TIME | TBD | 0 | The time from receipt of the |
	| | | | message during which the |		| | | | message during which the |
	| | | | information contained in the |		| | | | information contained in the |
	| | | | message is to be considered |		| | | | message is to be considered |
	| | | | valid |		| | | | valid |
	| | | | |		| | | | |
	skipping to change at page 12, line 5		skipping to change at page 13, line 5
	| | | | should be received |		| | | | should be received |
	| | | | |		| | | | |
	| | | 1-255 | RESERVED |		| | | 1-255 | RESERVED |
	+---------------+------+---------+----------------------------------+		+---------------+------+---------+----------------------------------+
	Table 1		Table 1
	Subtypes indicated as RESERVED may be allocated by standards action,		Subtypes indicated as RESERVED may be allocated by standards action,
	as specified in [3].		as specified in [3].
	9. Security Considerations		9.2. Address Block TLV tyepes
			+---------------+------+---------+----------------------------------+
			| Name | Type | Subtype | Description |
			+---------------+------+---------+----------------------------------+
			| VALIDITY_TIME | TBD | 0 | The time from receipt of the |
			| | | | address during which the |
			| | | | information regarding this |
			| | | | address is to be considered |
			| | | | valid |
			| | | | |
			| | | 1-255 | RESERVED |
			| | | | |
			| INTERVAL_TIME | TBD | 0 | The maximum time before another |
			| | | | message of the same type as this |
			| | | | message from the same originator |
			| | | | and containing this address |
			| | | | should be received |
			| | | | |
			| | | 1-255 | RESERVED |
			+---------------+------+---------+----------------------------------+
			Table 2
			Subtypes indicated as RESERVED may be allocated by standards action,
			as specified in [3].
			10. Security Considerations
	This document does not specify any security considerations.		This document does not specify any security considerations.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[1] Clausen, T., Dearlove, C., Dean, J., 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-07.txt, June 2007.		Progress draft-ietf-manet-packetbb-08.txt, July 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		[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", October 1998.		Considerations Section in RFCs", October 1998.
	10.2. Informative References		11.2. Informative References
	[4] 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.
End of changes. 22 change blocks.
	36 lines changed or deleted		129 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/