Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs)
Extracted elements (20)
Hop-count-dependent time values are provided because some MANET protocols send messages with limited scope using different hop limits; nodes farther from the originator need longer validity times because they receive updates less frequently. A single TLV can express this hop-count gradient compactly.
INTERVAL_TIME and VALIDITY_TIME IANA assignments are defined in this document (rather than individually by each MANET protocol) to avoid interdependencies between unrelated MANET protocols and to prevent exhausting TLV Type spaces with duplicate assignments for structurally identical data.
The 8-bit time encoding was chosen because MANET routing protocols use bandwidth-limited wireless interfaces and prefer to trade computational complexity for fewer transmitted bits. High-precision time values are unnecessary for the intended use cases (message interval and validity time), while the encoding still spans from sub-second to multi-day values.
A protocol using both an INTERVAL_TIME or VALIDITY_TIME Address Block TLV and the same-named Message TLV MUST specify how to interpret the case when both are present — typically the Address Block TLV overrides the Message TLV for the addresses it covers.
A message MUST NOT include more than one INTERVAL_TIME TLV.
After the time indicated by a VALIDITY_TIME TLV, the receiving node MUST consider the message content (or associated addresses) to no longer be valid unless repeated in a later message. A message MUST NOT include more than one VALIDITY_TIME TLV.
All nodes in the MANET MUST use the same value of the constant C (specified in seconds), and C MUST be greater than 0 seconds. A protocol using this time representation MUST define the value of C.
For a multi-value Time TLV, the <length> field MUST contain the value m*(2n+1), where m is number-values per RFC 5444 and n is the number of (time-value, hop-count) pairs per <time-data> structure. n := ((<length> / number-values) - 1) / 2 MUST be an integer.
For a single-value Time TLV, the <length> field MUST contain the value 2n+1, where n is the number of (time-value, hop-count) pairs. The number of pairs n MUST be determined by inspecting the <length> field as n := (<length> - 1) / 2, and this MUST be an integer.
If a Time TLV is included in a message without a <msg-hop-count> field in its Message Header, or in a Packet TLV, the single time-code form of <time-data> (n=0) SHOULD be used.
Multi-value Time TLVs MUST be Address Block TLVs. A multi-value Time TLV MUST NOT be a Packet TLV or Message TLV.
A multi-value Time TLV (tismultivalue flag set) contains a sequence of <time-data> structures in its value field, one per address in the associated Address Block. Each <time-data> structure must contain the same number of (time-value, hop-count) pairs.
A single-value Time TLV (tismultivalue flag cleared) contains one <time-data> structure in its value field, allowing a single time-value that may vary by hop count. It may appear as a Packet TLV, Message TLV, or Address Block TLV.
The INTERVAL_TIME Message TLV defines the maximum time before another message of the same type from the same originator should be received. The interval time MAY be hop-count-dependent, which is appropriate when messages are sent with different hop limits.
The VALIDITY_TIME Message TLV defines the duration for which information in the message is valid after receipt. Its value MAY vary with hop count, which is appropriate because nodes farther from the originator receive updates less frequently and must treat them as valid for longer.
IANA assigned two Address Block TLV Types in the RFC 5444 'Assigned Address Block TLV Types' registry: INTERVAL_TIME (Type=0, Extension=0) and VALIDITY_TIME (Type=1, Extension=0), with the same numerical values as the corresponding Message TLV Types.
IANA assigned two Message TLV Types in the RFC 5444 'Assigned Message TLV Types' registry: INTERVAL_TIME (Type=0, Extension=0) and VALIDITY_TIME (Type=1, Extension=0). Extensions 1-223 require Expert Review; 224-255 are for Experimental Use.
Modification of a Time TLV can cause information to carry an invalid validity or interval time, leading to incorrect protocol performance. Maliciously setting a short validity time inflates protocol workload; a long validity time inflates storage requirements. Authentication and encryption as recommended by RFC 5444 are the appropriate countermeasures.
A time-value is encoded in an 8-bit time-code where the least-significant 3 bits are the mantissa (a) and the most-significant 5 bits are the exponent (b), yielding: time-value = (1 + a/8) * 2^b * C, and time-code = 8*b + a. Ascending time-codes represent ascending time-values, enabling direct comparison.
The <time-data> structure is encoded as (<time-code><hop-count>)*<time-code>, consisting of an odd number of octets (2n+1 for n hop-count/time-value pairs plus a default time-code). The hop-count thresholds <d_1>...<d_n> MUST be strictly increasing with <d_n> < 255.