idnits 2.17.1 draft-ietf-manet-timetlv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 481. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 24, 2007) is 6087 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-17) exists of draft-ietf-manet-packetbb-08 -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) T. Clausen 3 Internet-Draft LIX, Ecole Polytechnique, France 4 Intended status: Standards Track C. Dearlove 5 Expires: February 25, 2008 BAE Systems Advanced Technology 6 Centre 7 August 24, 2007 9 Representing multi-value time in MANETs 10 draft-ietf-manet-timetlv-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 25, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes a general and flexible TLV (type-length-value 44 structure) for representing time using the generalized MANET packet/ 45 message format. It defines two message and two address block TLVs 46 for representing validity and interval times for MANET routing 47 protocols. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 54 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 55 5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 7 56 6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 8 57 7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 7.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 59 7.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 60 8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11 61 8.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 62 8.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 9.1. Message TLV tyepes . . . . . . . . . . . . . . . . . . . . 12 65 9.2. Address Block TLV tyepes . . . . . . . . . . . . . . . . . 13 66 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 69 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 70 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . . . . 18 74 1. Introduction 76 The generalized packet/message format [1] specifies a signaling 77 format which MANET routing protocols can employ for exchanging 78 protocol information. This format presents the ability to express 79 and associate attributes to packets, messages or addresses, by way of 80 a general TLV (type-length-value) mechanism. 82 This document specifies a general Time TLV structure, which can be 83 used by any MANET routing protocol that needs to express either 84 single time-values or a set of time-values with each time-value 85 associated with a range of distances. Distances may be equated to 86 hop count, as provided by [1]. This allows a receiving node to 87 determine a single time-value if either it knows its distance from 88 the originator node, or the Time TLV specifies a single time-value. 90 This document also specifies two message TLV types, which use the TLV 91 structure proposed. These TLV types are INTERVAL_TIME and 92 VALIDITY_TIME, specifying respectively the maximum time before 93 another message of the same type as this message from the same 94 originator should be received, and the duration for which the 95 information in this message is valid after receipt. Note that, if 96 both are present, then the latter will usually be greater than the 97 former in order to allow for possible message loss. 99 This document also specifies two address block TLV types, which use 100 the TLV structure proposed. These TLV types are INTERVAL_TIME and 101 VALIDITY_TIME, defined equivalently to the two message TLVs with the 102 same names. 104 2. Terminology 106 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [2]. 110 Additionally, this document uses terminology from [1], and introduces 111 the following terminology: 113 Distance - the distance from the message originator to the message 114 recipient. If the distance is equated to the messages hop count, 115 then this may be indicated using the field in the full 116 message header defined in [1], after being incremented on 117 reception. 119 Time-value - a time, measured in seconds. 121 Time-code - an 8 bit field, representing a time-value. 123 3. Applicability Statement 125 The TLV described in this document is applicable whenever a single 126 time-value, or a time-value that varies with distance from the 127 originator of a message, is required in a protocol using the 128 generalized MANET packet/message format [1]. 130 Examples of time-values that may be included in a protocol message 131 are: 133 o The maximum time interval until the next message of the same type 134 is to be generated by the message's originator node. 136 o The validity time of the information with which the time-value is 137 associated. 139 Either of these may vary with the distance between the originating 140 and receiving nodes, e.g. if messages of the same type are sent with 141 different hop limits as defined in [1]. 143 Parts of this document have been generalized from material in the 144 proactive MANET routing protocol OLSR (The Optimized Link State 145 Routing Protocol) [4]. 147 4. Protocol Overview and Functioning 149 This document does not specify a protocol nor does it mandate 150 specific node or protocol behavior. Rather, it outlines mechanisms 151 for encoding time-values using the TLV mechanism of [1]. 153 5. Representing Time 155 This document specifies a TLV structure in which time-values are each 156 represented in an 8 bit time-code, one or more of which may be used 157 in a TLV's field. Of these 8 bits, the least significant 3 158 bits represent the mantissa (a), and the most significant 5 bits 159 represent the exponent (b), so that: 161 o time-value = (1 + a/8) * 2^b * C 163 o time-code = 8 * b + a 165 All nodes in the network MUST use the same value of the constant C, 166 which will be specified in seconds, hence so will be all time-values. 167 C MUST be greater than 0 seconds. Note that ascending values of the 168 time-code represent ascending time-values, time-values may thus be 169 compared by comparison of time-codes. 171 An algorithm for computing the time-code representing the smallest 172 representable time-value not less than the time-value t is: 174 1. find the largest integer b such that t/C >= 2^b; 176 2. set a = 8 * (t / (C * 2^b) - 1), rounded up to the nearest 177 integer; 179 3. if a == 8 then set b = b + 1 and set a = 0; 181 4. if 0 <= a <= 7, and 0 lt;= b <= 31, then the required time-value 182 can be represented by the time-code 8 * b + a, otherwise it can 183 not. 185 The minimum time-value that can be represented in this manner is C. 186 The maximum time-value that can be represented in this manner is 15 * 187 2^28 * C, or about 4.0 * 10^9 * C. If, for example, C = 1/1024 188 second, then this is about 45 days. 190 A protocol using this time representation MUST define the value of C. 191 A protocol using this specification MAY specify that the all bits 192 zero time-value (0) represents a time-value of zero and/or that the 193 all bits one time-value (255) represents an indefinitely large time- 194 value. 196 6. General Time TLV Structure 198 A Time TLV may be a packet, message or address block TLV. If it is a 199 packet or message TLV then it must be a single value TLV as defined 200 in [1]. If it is an address block TLV then it may be single value or 201 multivalue TLV. Note that even a single value Time TLV may contain a 202 multiple octet field. 204 The purpose of a single value Time TLV is to allow a single time- 205 value to be determined by a node receiving an entity containing the 206 Time TLV, based on its distance from the entity's originator. The 207 Time TLV may contain information that allows that time-value to be a 208 function of distance, and thus different receiving nodes may 209 determine different time-values. If a receiving node will not be 210 able to determine its distance from the originating node, then the 211 form of this Time TLV with a single time-code in a field (or 212 single value subfield) SHOULD be used. 214 The field of a single value Time TLV is specified, using the 215 regular expression syntax of [1], by: 217 = {