Mobile Ad hoc Networking (MANET) T. Clausen
Internet-Draft LIX, Ecole Polytechnique, France
Intended status: Standards Track C. Dearlove
Expires: October 22, 2007 BAE Systems Advanced Technology
Centre
April 20, 2007
Representing multi-value time in MANETs
draft-ietf-manet-timetlv-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Clausen & Dearlove Expires October 22, 2007 [Page 1]
Internet-Draft Time TLV April 2007
Abstract
This document describes a general and flexible TLV (type-length-value
structure) for representing time using the generalized MANET packet/
message format. It defines two message TLVs for representing
validity and interval times for MANET routing protocols.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6
5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 7
6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 8
7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
7.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Clausen & Dearlove Expires October 22, 2007 [Page 2]
Internet-Draft Time TLV April 2007
1. Introduction
The generalized packet/message format [1] specifies a signaling
format which MANET routing protocols can employ for exchanging
protocol information. This format presents the ability to express
and associate attributes to packets, messages or addresses, by way of
a general TLV (type-length-value) mechanism.
This document specifies a general Time TLV structure, which can be
used by any MANET routing protocol that needs to express either
single time-values or a set of time-values with each time-value
associated with a range of distances. Distances may be equated to
hop count, as provided by [1]. This allows a receiving node to
determine a single time-value if either it knows its distance from
the originator node, or the Time TLV specifies a single time-value.
This document also specifies two message TLV types, which use the TLV
structure proposed. These TLV types are INTERVAL_TIME and
VALIDITY_TIME, specifying respectively the maximum time before
another message of the same type as this message from the same
originator should be received, and the duration for which the
information in this message is valid after receipt. Note that, if
both are present, then the latter will usually be greater than the
former in order to allow for possible message loss.
Clausen & Dearlove Expires October 22, 2007 [Page 3]
Internet-Draft Time TLV April 2007
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [2].
Additionally, this document uses terminology from [1], and introduces
the following terminology:
Distance - the distance from the message originator to the message
recipient. If the distance is equated to the messages hop count,
then this may be indicated using the <hop-count> field in the full
message header defined in [1], after being incremented on
reception.
Time-value - a time, measured in seconds.
Time-code - an 8 bit field, representing a time-value.
Clausen & Dearlove Expires October 22, 2007 [Page 4]
Internet-Draft Time TLV April 2007
3. Applicability Statement
The TLV described in this document is applicable whenever a single
time-value, or a time-value that varies with distance from the
originator of a message, is required in a protocol using the
generalized MANET packet/message format [1].
Examples of time-values that may be included in a protocol message
are:
o The maximum time interval until the next message of the same type
is to be generated by the message's originator node.
o The validity time of the information with which the time-value is
associated.
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
different hop limits as defined in [1].
Parts of this document have been generalized from material in the
proactive MANET routing protocol OLSR (The Optimized Link State
Routing Protocol) [3].
Clausen & Dearlove Expires October 22, 2007 [Page 5]
Internet-Draft Time TLV April 2007
4. Protocol Overview and Functioning
This document does not specify a protocol nor does it mandate
specific node or protocol behavior. Rather, it outlines mechanisms
for encoding time-values using the TLV mechanism of [1].
Clausen & Dearlove Expires October 22, 2007 [Page 6]
Internet-Draft Time TLV April 2007
5. Representing Time
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
in a TLV's <value> field. Of these 8 bits, the least significant
four bits represent the mantissa (a), and the most significant four
bits represent the exponent (b), so that:
o time-value = (1 + a/16) * 2^b * C
o time-code = 16 * b + a
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.
C MUST be greater than 0 seconds. Note that ascending values of the
time-code represent ascending time-values, time-values may thus be
compared by comparison of time-codes.
An algorithm for computing the time-code representing the smallest
representable time-value not less than the time-value t is:
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
integer;
3. if a == 16 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
can be represented by the time-code 16 * b + a, otherwise it can
not.
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
63488 * C.
Clausen & Dearlove Expires October 22, 2007 [Page 7]
Internet-Draft Time TLV April 2007
6. General Time TLV Structure
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
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,
in Section 7 are message, and hence single value, TLVs. Note that
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-
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 may contain information that allows that time-value to be a
function of distance, and thus different receiving nodes may
determine different time-values. If a receiving node will not be
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
regular expression syntax of [1], by:
<value> = {<time><distance>}*<time>
where:
<time> is an 8 bit field containing a time-code as defined in
Section 5.
<distance> is an 8 bit field specifying a distance from the message
originator.
A single value <value> field thus consists of an odd number of
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
A single value <value> 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.
Then, at the receiving node's distance from the originator node, the
time-value indicated is that represented by the time-code:
Clausen & Dearlove Expires October 22, 2007 [Page 8]
Internet-Draft Time TLV April 2007
o <t_1>, if n > 0 and distance <= <d_1>;
o <t_i+1>, if n > 1 and <d_i> < distance <= <d_i+1> for some i such
that 1 <= i < n;
o <t_default> otherwise, i.e. if n == 0 or distance > <d_n>.
In a multivalue Time TLV, each single value subfield of the
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
of n) but they need not use the same values of <d_1> to <d_n>.
Clausen & Dearlove Expires October 22, 2007 [Page 9]
Internet-Draft Time TLV April 2007
7. Message TLVs
Two message TLVs are defined, for signaling message validity time
(VALIDITY_TIME) and message interval (INTERVAL_TIME).
7.1. VALIDITY_TIME TLV
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
contained. After this time the receiving node MUST consider the
message content to no longer be valid (unless repeated in a later
message). The validity time of a message MAY be specified to depend
on the distance from its originator. (This is appropriate if
messages are 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 VALIDITY_TIME TLV is an example of a Time TLV specified as in
Section 5.
7.2. 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 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.)
An INTERVAL_TIME TLV is an example of a Time TLV specified as in
Section 5.
Clausen & Dearlove Expires October 22, 2007 [Page 10]
Internet-Draft Time TLV April 2007
8. IANA Considerations
This specification defines two message TLV types, which must be
allocated from the "Assigned Message TLV Types" repository of [1].
+--------------------+-------+--------------------------------------+
| Mnemonic | Value | Description |
+--------------------+-------+--------------------------------------+
| VALIDITY_TIME | TBD | The time from receipt of the message |
| | | during which the information |
| | | contained in the message is to be |
| | | considered valid |
| | | |
| INTERVAL_TIME | TBD | The maximum time before another |
| | | message of the same type as this |
| | | message from the same originator |
| | | should be received |
+--------------------+-------+--------------------------------------+
Table 1
Clausen & Dearlove Expires October 22, 2007 [Page 11]
Internet-Draft Time TLV April 2007
9. Security Considerations
This document does not specify any security considerations.
Clausen & Dearlove Expires October 22, 2007 [Page 12]
Internet-Draft Time TLV April 2007
10. References
10.1. Normative References
[1] Clausen, T., Dean, J., Dearlove, C., and C. Adjih, "Generalized
MANET Packet/Message Format", Work In
Progress draft-ietf-manet-packetbb-04.txt, January 2007.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
10.2. Informative References
[3] Clausen, T. and P. Jacquet, "The Optimized Link State Routing
Protocol", RFC 3626, October 2003.
Clausen & Dearlove Expires October 22, 2007 [Page 13]
Internet-Draft Time TLV April 2007
Appendix A. Acknowledgements
The authors would like to thank Brian Adamson and Justin Dean (both
NRL) for their contributions, and Alan Cullen (BAE Systems) for his
careful review of this specification.
Clausen & Dearlove Expires October 22, 2007 [Page 14]
Internet-Draft Time TLV April 2007
Authors' Addresses
Thomas Heide Clausen
LIX, Ecole Polytechnique, France
Phone: +33 6 6058 9349
Email: T.Clausen@computer.org
URI: http://www.ThomasClausen.org/
Christopher M. Dearlove
BAE Systems Advanced Technology Centre
Phone: +44 1245 242194
Email: chris.dearlove@baesystems.com
URI: http://www.baesystems.com/
Clausen & Dearlove Expires October 22, 2007 [Page 15]
Internet-Draft Time TLV April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Clausen & Dearlove Expires October 22, 2007 [Page 16]
