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/