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/