--- 1/draft-ietf-manet-timetlv-00.txt 2007-07-03 21:12:09.000000000 +0200 +++ 2/draft-ietf-manet-timetlv-01.txt 2007-07-03 21:12:09.000000000 +0200 @@ -1,20 +1,20 @@ 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 +Expires: December 31, 2007 BAE Systems Advanced Technology Centre - April 20, 2007 + June 29, 2007 Representing multi-value time in MANETs - draft-ietf-manet-timetlv-00 + draft-ietf-manet-timetlv-01 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 @@ -25,21 +25,21 @@ 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. + This Internet-Draft will expire on December 31, 2007. Copyright Notice Copyright (C) The IETF Trust (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 @@ -124,21 +124,21 @@ 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]. + Routing Protocol) [4]. 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]. 5. Representing Time This document specifies a TLV structure in which time-values are each @@ -172,21 +172,21 @@ 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. 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 + 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 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 @@ -236,102 +236,118 @@ each single value subfield has the same length (i.e. the same value of n) but they need not use the same values of to . 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 + 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 message MUST NOT include more than one VALIDITY_TIME TLV. + 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.) + 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 Section 5. 8. IANA Considerations 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 | - +--------------------+-------+--------------------------------------+ - | 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 | - +--------------------+-------+--------------------------------------+ + +---------------+------+---------+----------------------------------+ + | Name | Type | Subtype | Description | + +---------------+------+---------+----------------------------------+ + | VALIDITY_TIME | TBD | 0 | The time from receipt of the | + | | | | message during which the | + | | | | information contained in the | + | | | | message 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 | + | | | | should be received | + | | | | | + | | | 1-255 | RESERVED | + +---------------+------+---------+----------------------------------+ Table 1 + Subtypes indicated as RESERVED may be allocated by standards action, + as specified in [3]. + 9. Security Considerations This document does not specify any security considerations. 10. 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 - 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 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 - [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. 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. 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 + Christopher Dearlove BAE Systems Advanced Technology Centre Phone: +44 1245 242194 Email: chris.dearlove@baesystems.com URI: http://www.baesystems.com/ Full Copyright Statement Copyright (C) The IETF Trust (2007).