Network Working Group T. Clausen Request for Comments: 5497 LIX, Ecole Polytechnique Category: Standards Track C. Dearlove BAE Systems ATC March 2009 Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
AbstractThis document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address Block TLVs for representing validity and interval times for MANET routing protocols.
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation and Rationale . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 5. Representing Time . . . . . . . . . . . . . . . . . . . . . . 6 6. General Time TLV Structure . . . . . . . . . . . . . . . . . . 7 6.1. Single-Value Time TLVs . . . . . . . . . . . . . . . . . . 8 6.2. Multi-Value Time TLVs . . . . . . . . . . . . . . . . . . 9 7. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 7.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 8. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 10 8.1. INTERVAL_TIME TLV . . . . . . . . . . . . . . . . . . . . 10 8.2. VALIDITY_TIME TLV . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 11 9.2. Message TLV Types . . . . . . . . . . . . . . . . . . . . 12 9.3. Address Block TLV Types . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
RFC5444] specifies a signaling format that 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 used by any MANET routing protocol that needs to express either single time-values or a set of time-values with each time-value associated with a range of hop counts, as provided by the Message Header of [RFC5444]. This allows a receiving node to determine a single time-value if either it knows its hop count from the originator node or the Time TLV specifies a single time-value. A time-value is, in this context, not an "absolute point in time", but rather an interval or a duration. An instance of a Time TLV can, therefore, express an interval or a duration such as "10 seconds". 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.
routing protocols and different deployments of MANET routing protocols may have different granularity requirements and bounds on shortest and longest spacing between successive message transmissions. In addition, MANET routing protocol deployments typically use bandwidth-limited wireless network interfaces, and therefore prefer to trade off computational complexity for a saving in the number of bits transmitted. This is practical in this case, because the intended usages of Time TLVs, including the specified examples of message interval time and information validity time, do not require high-precision values of time. The Time TLV structure, specified in this document, caters to these characteristics by: o encoding time-values, such as an interval or a duration, in an 8-bit field; while o allowing these time-values to range from "very small" (e.g., 1/1024 second) to "very long" (e.g., 45 days); and o allowing a MANET routing protocol, or a deployment, to parameterize this (e.g., to attain finer granularity at the expense of a lower upper bound) through a single parameter, C. The parameter C must be the same for all MANET routers in the same deployment. The TLV mechanism as specified in [RFC5444] allows associating a "value" to either a packet, a message, or to addresses. The data structure for doing so -- the TLV -- is identical in each of the three cases; however, the TLV's position in a received packet allows determining if that TLV is a "Packet TLV" (it appears in the Packet Header, before any messages), a "Message TLV" (it appears in the TLV Block immediately following a Message Header), or an "Address Block TLV" (it appears in the TLV Block immediately following an Address Block). While TLVs may be structurally identical, that which they express may be different. This is determined from the kind (packet, message, or Address Block) and type of the TLV. For example, one TLV might associate a lifetime to an address, another a content sequence number to a message, and another a cryptographic signature to a packet. For this reason, [RFC5444] specifies separate registries for Packet TLV Types, Message TLV Types, and Address Block TLV Types, and it does not specify any structure in the TLV Value field.
The TLVs defined in this document express, essentially, that "this information will be refreshed within X seconds" and that "this information is valid for X seconds after being received", each allowing the "X seconds" to be specified as a function of the number of hops from the originator of the information. This document specifies a general format allowing expressing and encoding this as the value field of a TLV. This representation uses a compact (8-bit) representation of time, as message size is an issue in many MANETs, and the offered precision and range is appropriate for MANET routing protocols. A TLV of this format may be used for packets, messages, or addresses. For example, a proactive MANET routing protocol periodically reporting link-state information could include a TLV of this format as a Message TLV. This may indicate a different periodicity in different scopes (possibly frequently up to a few hops, less frequently beyond that) because some messages may be sent with limited scope, as specified in [RFC5444]. A reactive MANET routing protocol could include a TLV of this format as an Address Block TLV for reporting the lifetime of routes to individual addresses. In addition to defining the general format as outlined above, this document requests IANA assignments for INTERVAL_TIME and VALIDITY_TIME TLVs. These IANA assignments are requested in this document in order to avoid interdependencies between otherwise unrelated MANET protocols and in order to not exhaust the TLV Type spaces by having different protocols request types for essentially identical data structures. Only Message TLVs and Address Block TLVs are requested, as these are those for which a need has been demonstrated. RFC2119]. Additionally, this document uses terminology from [RFC5444], and introduces the following terminology: hop count - the number of hops from the message originator to the message recipient. This is defined to equal the <msg-hop-count> field in the <msg-header> element defined in [RFC5444], if present, after it is incremented on reception. If the <msg-hop- count> field is not present, or in a Packet TLV, then hop count is defined to equal 255.
time-value - a time, measured in seconds. time-code - an 8-bit field, representing a time-value. RFC5444]. Examples of time-values that may be included in a protocol message are: o The maximum time interval until the next message of the same type is to be generated by the message's originator node. o The validity time of the information with which the time-value is associated. Either of these may vary with the hop count between the originating and receiving nodes, e.g., if messages of the same type are sent with different hop limits as defined in [RFC5444]. Parts of this document have been generalized from material in the proactive MANET routing protocol OLSR (Optimized Link State Routing Protocol) [RFC3626]. RFC5444].
All nodes in the MANET 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 := 8 * (t / (C * 2^b) - 1), rounded up to the nearest integer; 3. if a = 8, then set b := b + 1 and set a := 0; 4. if 0 <= a <= 7, and 0 <= b <= 31, then the required time-value can be represented by the time-code 8 * b + a, otherwise it cannot. 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 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. Section 5. This <time-data> data structure is specified, using the regular expression syntax of [RFC5444], by: <time-data> = (<time-code><hop-count>)*<time-code> where: <time-code> is an 8-bit unsigned integer field containing a time- code as defined in Section 5.
<hop-count> is an 8-bit unsigned integer field specifying a hop count from the message originator. A <time-data> structure thus consists of an odd number of octets; with a repetition factor of n for the (time, hop count) pairs in the regular expression syntax, it contains 2n+1 octets. On reception, n is determined from the length. A <time-data> field may be thus represented by: <t_1><d_1><t_2><d_2> ... <t_i><d_i> ... <t_n><d_n><t_default> <d_1>, ... <d_n>, if present, MUST be a strictly increasing sequence, with <d_n> < 255. Then, at the receiving node's hop count from the originator node, the time-value indicated is that represented by the time-code: 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 that 1 <= i < n; o <t_default> otherwise, i.e. if n = 0 or hop count > <d_n>. If included in a message without a <msg-hop-count> field in its Message Header, or in a Packet TLV, then the form of this data structure with a single time-code in <time-data> (i.e., n = 0) SHOULD be used. RFC5444], contains a single <time-data>, as defined above, in its <value> field. For such a Time TLV: o The <length> field in the TLV MUST contain the value 2n+1, with n being the number of (time-value, hop count) pairs in the Time TLV.
o The number of (time-value, hop count) pairs MUST be identified by inspecting the <length> field in the TLV. The number of such pairs, n, is: * n := (<length> - 1) / 2 This MUST be an integer value. RFC5444]. For each of these <time-data> structures, a single time-value can 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 may contain information that allows that time-value to be a function of the hop count, and thus different receiving nodes may determine different time-values. Multi-value Time TLVs MUST be Address Block TLVs. A multi-value Time TLV MUST NOT be a Packet TLV or Message TLV. A Time TLV that has the tismultivalue flag set ('1') in its <tlv- flags> field, as defined in [RFC5444], contains a sequence of <time- data> structures, as defined above, in its <value> field. For such a Time TLV: o The <length> field in the TLV MUST contain the value m * (2n+1), with n being the number of (time-value, hop count) pairs in the Time TLV, and m being number-values as defined in [RFC5444]. o The number of <time-data> structures included in the <value> field is equal to number-values as defined in [RFC5444]. o The number of (time-value, hop count) pairs in each <time-data> structure MUST be the same, and MUST be identified by inspecting the <length> field in the TLV and using number-values as defined in [RFC5444]. The number of such pairs in each <time-data> structure, n, is: * n := ((<length> / number-values) - 1) / 2 This MUST be an integer value. The lists of hop count values MAY be different.
contained in messages sent with different hop limits so that receiving nodes at greater hop counts have an increased interval time.) A protocol using this TLV and the same named Message TLV MUST specify how to interpret the case when both are present (typically, that the former overrides the latter for those addresses that are covered by the former). An INTERVAL_TIME TLV is an example of a Time TLV specified as in Section 5. Section 5. RFC5444] as specified in Table 1, and two Address Block TLV Types, which have been allocated from the "Assigned Address Block TLV Types" repository of [RFC5444] as specified in Table 2. IANA has assigned the same numerical value to the Message TLV Type and Address Block TLV Type with the same name. RFC5444].
+---------------+------+-----------+--------------------------------+ | Name | Type | Type | Description | | | | Extension | | +---------------+------+-----------+--------------------------------+ | INTERVAL_TIME | 0 | 0 | The maximum time before | | | | | another message of the same | | | | | type as this message from the | | | | | same originator should be | | | | | received | | Unassigned | 0 | 1-223 | Expert Review | | | | 224-255 | Experimental Use | | VALIDITY_TIME | 1 | 0 | The time from receipt of the | | | | | message during which the | | | | | information contained in the | | | | | message is to be considered | | | | | valid | | Unassigned | 1 | 1-223 | Expert Review | | | | 224-255 | Experimental Use | +---------------+------+-----------+--------------------------------+ Table 1 +---------------+------+-----------+--------------------------------+ | Name | Type | Type | Description | | | | extension | | +---------------+------+-----------+--------------------------------+ | INTERVAL_TIME | 0 | 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 | | Unassigned | 0 | 1-223 | Expert Review | | | | 224-255 | Experimental Use | | VALIDITY_TIME | 1 | 0 | The time from receipt of the | | | | | address during which the | | | | | information regarding this | | | | | address is to be considered | | | | | valid | | Unassigned | 0 | 1-223 | Expert Review | | | | 224-255 | Experimental Use | +---------------+------+-----------+--------------------------------+ Table 2
RFC5444]. In particular, information validity durations and reporting intervals may be added. The general security threats that apply are those general to [RFC5444] 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 [RFC5444], for the use of authentication and encryption, are appropriate. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, February 2009. [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State Routing Protocol", RFC 3626, October 2003.
http://www.ThomasClausen.org/ Christopher Dearlove BAE Systems Advanced Technology Centre Phone: +44 1245 242194 EMail: firstname.lastname@example.org URI: http://www.baesystems.com/