--- 1/draft-ietf-manet-timetlv-01.txt 2007-08-28 22:12:14.000000000 +0200 +++ 2/draft-ietf-manet-timetlv-02.txt 2007-08-28 22:12:14.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: December 31, 2007 BAE Systems Advanced Technology +Expires: February 25, 2008 BAE Systems Advanced Technology Centre - June 29, 2007 + August 24, 2007 Representing multi-value time in MANETs - draft-ietf-manet-timetlv-01 + draft-ietf-manet-timetlv-02 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,52 +25,58 @@ 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 December 31, 2007. + This Internet-Draft will expire on February 25, 2008. 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 - validity and interval times for MANET routing protocols. + message format. It defines two message and two address block 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 + 8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11 + 8.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 + 8.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 + 9.1. Message TLV tyepes . . . . . . . . . . . . . . . . . . . . 12 + 9.2. Address Block TLV tyepes . . . . . . . . . . . . . . . . . 13 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 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 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 @@ -83,20 +89,25 @@ 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. + 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 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 @@ -136,61 +147,66 @@ 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 represented in an 8 bit time-code, one or more of which may be used - in a TLV's 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: + in a TLV's field. Of these 8 bits, the least significant 3 + bits represent the mantissa (a), and the most significant 5 bits + 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, 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 + 2. set a = 8 * (t / (C * 2^b) - 1), rounded up to the nearest 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 - can be represented by the time-code 16 * b + a, otherwise it can + 4. if 0 <= a <= 7, and 0 lt;= b <= 31, then the required time-value + can be represented by the time-code 8 * 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. + The maximum time-value that can be represented in this manner is 15 * + 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 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 - field. + multivalue TLV. 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 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 field (or single value subfield) SHOULD be used. @@ -265,25 +281,75 @@ 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 +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 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 | +---------------+------+---------+----------------------------------+ | VALIDITY_TIME | TBD | 0 | The time from receipt of the | | | | | message during which the | | | | | information contained in the | | | | | message is to be considered | | | | | valid | | | | | | @@ -295,39 +361,66 @@ | | | | 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 +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. -10. References +11. References -10.1. Normative References +11.1. Normative References [1] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized 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 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 +11.2. Informative References [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.