idnits 2.17.1 draft-ietf-manet-timetlv-01.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 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 388. 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 (June 29, 2007) is 6140 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-07 -- 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: December 31, 2007 BAE Systems Advanced Technology 6 Centre 7 June 29, 2007 9 Representing multi-value time in MANETs 10 draft-ietf-manet-timetlv-01 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 December 31, 2007. 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 TLVs for representing 46 validity and interval times for MANET routing protocols. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 53 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 54 5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 7 55 6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 8 56 7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 7.1. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 58 7.2. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 61 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 63 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 66 Intellectual Property and Copyright Statements . . . . . . . . . . 16 68 1. Introduction 70 The generalized packet/message format [1] specifies a signaling 71 format which MANET routing protocols can employ for exchanging 72 protocol information. This format presents the ability to express 73 and associate attributes to packets, messages or addresses, by way of 74 a general TLV (type-length-value) mechanism. 76 This document specifies a general Time TLV structure, which can be 77 used by any MANET routing protocol that needs to express either 78 single time-values or a set of time-values with each time-value 79 associated with a range of distances. Distances may be equated to 80 hop count, as provided by [1]. This allows a receiving node to 81 determine a single time-value if either it knows its distance from 82 the originator node, or the Time TLV specifies a single time-value. 84 This document also specifies two message TLV types, which use the TLV 85 structure proposed. These TLV types are INTERVAL_TIME and 86 VALIDITY_TIME, specifying respectively the maximum time before 87 another message of the same type as this message from the same 88 originator should be received, and the duration for which the 89 information in this message is valid after receipt. Note that, if 90 both are present, then the latter will usually be greater than the 91 former in order to allow for possible message loss. 93 2. Terminology 95 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC2119 [2]. 99 Additionally, this document uses terminology from [1], and introduces 100 the following terminology: 102 Distance - the distance from the message originator to the message 103 recipient. If the distance is equated to the messages hop count, 104 then this may be indicated using the field in the full 105 message header defined in [1], after being incremented on 106 reception. 108 Time-value - a time, measured in seconds. 110 Time-code - an 8 bit field, representing a time-value. 112 3. Applicability Statement 114 The TLV described in this document is applicable whenever a single 115 time-value, or a time-value that varies with distance from the 116 originator of a message, is required in a protocol using the 117 generalized MANET packet/message format [1]. 119 Examples of time-values that may be included in a protocol message 120 are: 122 o The maximum time interval until the next message of the same type 123 is to be generated by the message's originator node. 125 o The validity time of the information with which the time-value is 126 associated. 128 Either of these may vary with the distance between the originating 129 and receiving nodes, e.g. if messages of the same type are sent with 130 different hop limits as defined in [1]. 132 Parts of this document have been generalized from material in the 133 proactive MANET routing protocol OLSR (The Optimized Link State 134 Routing Protocol) [4]. 136 4. Protocol Overview and Functioning 138 This document does not specify a protocol nor does it mandate 139 specific node or protocol behavior. Rather, it outlines mechanisms 140 for encoding time-values using the TLV mechanism of [1]. 142 5. Representing Time 144 This document specifies a TLV structure in which time-values are each 145 represented in an 8 bit time-code, one or more of which may be used 146 in a TLV's field. Of these 8 bits, the least significant 147 four bits represent the mantissa (a), and the most significant four 148 bits represent the exponent (b), so that: 150 o time-value = (1 + a/16) * 2^b * C 152 o time-code = 16 * b + a 154 All nodes in the network MUST use the same value of the constant C, 155 which will be specified in seconds, hence so will be all time-values. 156 C MUST be greater than 0 seconds. Note that ascending values of the 157 time-code represent ascending time-values, time-values may thus be 158 compared by comparison of time-codes. 160 An algorithm for computing the time-code representing the smallest 161 representable time-value not less than the time-value t is: 163 1. find the largest integer b such that t/C >= 2^b; 165 2. set a = 16 * (t / (C * 2^b) - 1), rounded up to the nearest 166 integer; 168 3. if a == 16 then set b = b + 1 and set a = 0; 170 4. if a and b are in the range 0 and 15 then the required time-value 171 can be represented by the time-code 16 * b + a, otherwise it can 172 not. 174 The minimum time-value that can be represented in this manner is C. 175 The maximum time-value that can be represented in this manner is 176 63488 * C. 178 6. General Time TLV Structure 180 A Time TLV may be a packet, message or address block TLV. If it is a 181 packet or message TLV then it must be a single value TLV as defined 182 in [1]. If it is an address block TLV then it may be single value or 183 multivalue TLV. The specific Time TLVs specified in this document, 184 in Section 7 are message, and hence single value, TLVs. Note that 185 even a single value Time TLV may contain a multiple octet 186 field. 188 The purpose of a single value Time TLV is to allow a single time- 189 value to be determined by a node receiving an entity containing the 190 Time TLV, based on its distance from the entity's originator. The 191 Time TLV may contain information that allows that time-value to be a 192 function of distance, and thus different receiving nodes may 193 determine different time-values. If a receiving node will not be 194 able to determine its distance from the originating node, then the 195 form of this Time TLV with a single time-code in a field (or 196 single value subfield) SHOULD be used. 198 The field of a single value Time TLV is specified, using the 199 regular expression syntax of [1], by: 201 = {